Continuing my recent musings about what defines an architect, I came across this great post from Jon Boxall, a fellow Conchangite (or is it Conchangian?). It's a bit tongue-in-cheek, but his one-line summary is "a software architect is the bloke that has to worry about the non-functionals". Succint and quite accurate.
Interestingly, it's not dissimilar to a definition from Agile Architect: "the architect is responsible for defining and maintaining the structure of the solution, and ensuring that it will meet the requirements". The main difference is that this definition attaches more responsibility to the architect, in that they are supposed to "ensure" the requirements are met. Personally I'm not convinced that this responsibility belongs solely to the architect - if a developer has written a module and it has passed system test, why should a failure to meet requirements rest with the architect?
One definition of the term structure is "something arranged in a definite pattern of organisation". I think that this fits in nicely with the first part of the Agile Architect definition and Jon Boxall's thoughts - an architect is responsible for organising the parts of a solution into patterns so that the non-functional requirements are satisfied.
And I can't finish this post, without mentioning Patterns (capital P) without which an architect isn't really an architect. They are a catalogue of recurring patterns which crop up time and time again and which are really useful. There are software design patterns, as first written about by The Gang of Four (various code implementations exist, e.g. this one in C#), and there are enterprise architecture patterns (as conceived by Martin Fowler, MSDN and The Open Group). Although I'm a great believer in software design patterns, I'm afraid I remain to be convinced about the wider enterprise patterns. This isn't helped by the wide variety of uses of the term pattern - from the "mind-numbingly simple" Identity Pattern (which I think is actually too simple to be called a pattern) to the Load-balanced Cluster Pattern (which relates to physical infrastructure) to the Deployment Plan (which sounds to me more like a ... urm ... plan than a pattern).
I was in a sprint review meeting today and I had a slot to present the architecture which I'd designed on a new project. The CEO was in the presentation and as soon as the title page came up, he immediately asked to skip my section since he felt he wouldn't understand it and he would rely on our expertise.
Now I'm not taking that personally as an inditement of my presenting skills ... [;)]
But it occurred to me that he has a point, and a very good one at that. Business people generally aren't interested in the implementation of technology, except that it must work and allow them to carry out the work of the business. If the architect does his work properly then the delivered project will smoothly enable the business and the business people will not give him a second thought. On the other hand, if the architect doesn't do a good job then he will get noticed for all the wrong reasons.
Now in certain management theories, factors which can cause dissatisfaction are called hygiene factors and they are presented as separate to factors which can cause satisfaction (these are called motivators in the theory). It occurs to me that an architect is, generally, a hygiene factor in that they can bring about dissatisfaction to business users. The only potential satisfaction which an architect can bring about is if the project is well delivered - but that's probably what the business users are expecting anyway (or at least hoping for).
I guess a corollary of this is that an architect shouldn't expect much positive feedback from business users. The delivery team clearly can expect this because they are clearly adding value, but the primary aim of the architecture and the architect is to not get in the way.