Day 2 of JAOO 2008 was all about architecture for me, agile architecture, architecture reviews, requirements gathering, architecture testing, and finally lessons learned in architecture, Be sure to catch my summary of JAOO 2008 Day 1 if you missed it.
Frank Buschmann from Siemens in Germany was track host and also the first speaker of the day. I caught a couple of talks with Frank last year and it’s apparent that he knows his stuff. While hugely important the architecture talks tend to be quite difficult to follow because the very nature of the topic is fluffy.
Most of the talk was pretty run of the mill in terms of how to conduct an architecture review. I’ve never formally conducted such a review but we do do them at regular intervals at Vertica just not in any sort of structured manner. We do them when they make sense and they usually consist of peer reviews and initial design sessions.
Most interesting to me were a couple of techniques which Frank brought to light to do á formal architecture review. It’s not something you do every day and it’s certainly not something which requires a lot of structure.
My key take away from the talk is the fact that preparation for an architecture review is essential. Basically you need to sit down and try and figure out what you or the client expect from the review as the goal will impact the process of doing the review. This highlights why we can get away we can get away with very informal reviews because our goal is usually to verify that the selected architecture.
Now the situation changes rapidly when we’re conducting architecture reviews for other companies. Here the objective is to both verify architecture but more importantly to figure out what went wrong after the fact when a new system doesn’t satisfy non-functional requirements, lacks adaption in their internal dev organization, lacks maintainability, or something else altogether.
So I took away the fact that I need to be a lot more conscious about what the client expects to get out of a review and I must admit that I’ve taken a lot of satisfaction from going in and pointing out all the deficiencies in existing systems without giving thought to the fact that more often than not systems due have something good to bring to the table in spite of its deficiencies, perceived or otherwise.
Next up a talk which I didn’t really know what to expect from. The talk though turned out to be one of my favorites at this year’s JAOO due to the fact that it was very different from what I’ve seen at any other conference and it covered a topic, the importance of which I can’t stress enough, Communication.
Chris Rupp from Sophist at which she is the CEO and business analyst. Before I get started with my summary I must mention the fact that she spoke flawless English; a feat I’ve rarely seen performed by a German person. No hint of accent, nothing, just perfect English.
The meat of the talk was all about understanding what your client is telling you and more importantly filling in the blanks. The premise of the talk was basically something that we’ve know collectively in the software business for a while: The client doesn’t know what he/she wants. She had a twist on this though that I couldn’t agree with more which went along the lines that we can’t expect the client to know what they want. Building software is a complex task and it’s our responsibility as a community to help our clients to figure out what they want.
Chris touched on quite a number of different techniques with which we can employ to fill in the blanks. I was very pleased with the fact that she decided to focus on just a single technique called Neuro Linguistic Programming (NLP). My very limited understanding of NLP is that it’s basically the theory of the programming language of the human mind. What I took away from the talk is that NLP might be the key to picking up subtle nuances in the conversations I have with clients. Is a sentence phrased imprecisely? Maybe the client doesn’t really know what the details should be in that particular case. Is the client using very general terms to describe a feature? That could mean that we’re lacking some details, maybe we shouldn’t really allow everybody to update everything.
As I stated my understanding of NLP is very limited at this point but I definitely see a lot of potential here so I went ahead and suggested they we get some books on the subject so we can investigate further. I’m hooked at this point no doubt about it.
James Coplien did a talk on what I thought would be pretty standard only-design-and-build-the-architecture-you-need-right-now kind of talks. Indeed he started out like that but he quickly went on to blowing our collective minds with proposing a new style of architecture where we separate the What and the Why more clearly. Now I won’t state that I understood half of what he was saying but I got the general drift and I definitely need to look into this some more.
If I were to compare it with something I know from the domain driven design world I’d compare it with the Specification pattern on steroids but I feel that it’s a poor comparison as his ideas describe the overall solution architecture where the Specification pattern is just small bits of pieces of any given solution.
To better understand the concepts I need to see a lot more source code :) You can download the pre-draft book which James is writing on the subject I think you’ll enjoy the new ideas a great deal.
Software Architecture and Testing
…. zzZZZzz…. nuff said.
Top Ten Software Architecture Mistakes
Needless to say I was not in the most energetic of moods having sat throught the snooze fest which was the previous talk. The guy in front of me must have agreed as he actually nodded of there for a while during the testing talk. It was actually pretty entertaining watching him do battle with very heavy eye lids, the mightiest of foes :)
At least Eoin Woods (cool name or what?) took up the challenge and turned the whole mess around at the next talk in which he discussed his list of top ten architecture mistakes. Being in the last slot of the day is no easy task but he manged to get the entire room going, lots of laughs, lots of good stories, and lots of good information.
His talk basically served to highlight some of the mistakes that we’ve all made and continue to make from time to time. I believe that talks like this are invaluable as they serve to keep us mindful of at least some of the pitfalls of software architecture.
I liked that fact that this talk contained nothing but concrete examples and real world tips and tricks which we could take home with us and use. My favorite take away is to always have a plan B. I think most good architects subconsciously have these hanging around but I like the idea of having plan B be very explicit. It helps the the team if and when to enact it.
Just formulating plan B and sticking it into a document to me is hugely valuable; it gives you pause and helps you think through plan A and ultimately helps build trust as the customer ultimately gets a better solution and should, God forbid, plan A turn out to be a dud we’ve got something to fall back on. Having plan B be visible leaves more wiggle room for the client and I firmly believe that it helps build trust.
Continue to JAOO 2008 Day 3…