Partial architectures are dangerous

Once development work begins on a project, there is no such thing as a partially designed architecture - there are only partially complete architectures and these are dangerous.  Let me explain the distinction and why it's important.

Firstly, let me admit that an architecture can definitely be partially designed - but only while the architect is working on it.  This can happen on whiteboards, on paper, in Visio, in the Visual Studio class designer, in someone's head or in any number of other places.

Risks of a partially complete architecture
When development work begins, it will (hopefully) be in line with the current view of the architecture.  As soon as the first line of code is written, modifications to the architecture have to be called "changes" - there will (most likely) be changes required to the code to bring it in line with the new architecture.  And here's the key point - it's a new architecture.  It's not just the old architecture fleshed out a little bit.

Now you may think I'm splitting hairs here, but once development work begins it gets increasingly more expensive to change the architecture.  This exponential increase in cost generally continues as development progresses.  So revisions to the architecture can be costly.  And this means there's a temptation to cut corners, which would translate into the development team not changing the code to completely match the new architecture.  If this happens, you'll have a hybrid architecture which is neither the old one or the new one and heaven help you when you want to change the architecture yet again!

The other real risk of a partially complete architecture is that one of the developers may get to the "edge" of it and try to keep going.  In other words, they will encounter a problem, realise that it isn't handled within the current architecture and come up with their own point solution to it.  When a different developer hits the same problem, communication within the team may or may not be good enough for them to realise that it has already been solved.  If it isn't, then they will also come up with their own solution.

Am I being too precious?
Now I know that so far I sound quite precious about my architecture design, as if I don't want other people making decisions.  That isn't really the case.  I just want to be involved in the decision-making because it's my responsibility to try and ensure that all the decisions contribute to the bigger picture.  As David Armour writes, agile development teams can often just plough ahead delivering functionality without giving any thought to architecture.  This is the kind of project that I don't want to be involved in.

I'm also trying to mitigate the risks of a lack of development discipline (i.e. architectural changes not being completely worked through) and poor team communication (i.e. the team doesn't know that a particular problem has already been solved by someone).  Isn't it strange how these "soft" issues can have very direct impacts on our development processes?

Is there another way?
The other point I should make, is that some project teams take a different approach to this problem.  James Shore talks about Continuous Design and the mindset you need to operate in this way.  This approach sounds appealing to me, but still doesn't get around the fact that somebody has to have the bigger picture view, they have to know that it is accurate and they have to let it influence the decision-making process.

August 15 2006

An Architect as a creator of structure

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).

August 1 2006

An Architect as a hygiene factor

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.

Newer Posts Older Posts