The following quotes have all been taken from The Wayback Machine as David’s post has been removed multiple times from various of his blogs and it’s just easier.
So the architect’s job, and one that does get overlooked from time to time, is to go through the system design from many different perspectives and check that everything is still as good as you think it will be from different viewpoints. Remember that everyone else is busy beavering away on their various ‘next level up or down’ so you had better keep your head above the gopher hole.
[…]
…architects can sometimes be like old army generals at a war college, in that they keep trying to fight the last war even if the battlefield has changed.
The rather tired but still relevant analogy is how an airline pilot does things different from a software architect. The two pilots sit at the front and ticks off a series of mundane sounding items (Flaps 10% – Check, APU standby – Check, Nice Hat at Rakish Angle – Check etc) even though they do this every single day of their lives, while an architect would happily do all this from memory even though they do it every 2 years. The difference isn’t in the brain power of the pilot vs the architect, it’s in the relevance importance of forgetting something. A slow web page hasn’t ever killed 200 people, just annoyed them.
[…]
…nearly always by making an ‘embedding’ decision you are actually changing the systems requirements in a way that might not be obvious at the time. If you don’t have the mandate to make that sort of compromise then the inflexibility of a buy decision can be painful. You can get a lot out of buying components or frameworks but you must quickly shift into the attitude of knowing where the sweet spots are – in other words, ‘Stay On The Path’. There comes a time where you stretch the original metaphor so far with what you bought that you just need to hold you hands up and say ‘enough’. It seems to be a harder decision to drop a bought subsystem or framework that it is to first adopt one.
[…]
For the rest of us that don’t actually day-to-day need to use the systems we develop then need to form some sort of relationship with people that do. I don’t have a table of stats to show you but I personally have a deep feeling that software projects fail in two main ways:
(a). The system doesn’t work that well.
(b). The system works well but doesn’t do what you need it to do.
By and large it’s mainly always (b) in that it missed the need of what is actually useful. But it seems that we as an industry seem to concentrate our collective brain power on solving (a) much more though. The Agile approaches seems to at least attempt swing the game back into admitting that we can’t really go that long before doing the wrong thing, but in my limited experience, it often seems to just accept that this developer-domain gap exists as an unavoidable ‘tax’ to be amortatized over a short set of more rapid releases.
You can go either way with trying to understand the domain problems as a software architecture. You can choose to fully surround yourself with them in an attempt to understand them more, or you can trying to step right back and just call them ‘Widgets’. The danger with not getting involved with the business requirements is that it is tragically easy just to hear what you think are justifications for the architecture you have in mind. This problem is also compounding with the fact that if it takes 6 months to gather the requirements then they are probably not going to be correct in six months time. Requirements are a 4-dimensional problem.
The first part of my tip for the software architecture in terms of the requirements is to at least spend as much time listening to the users as you do your implementation team. Also try to actively look for aspects of the system you know are difficult to implement and go around with active questioning on those early on.
[…]
David himself has complained that he sounds dated, that most of these points have been better made elsewhere, etc., yet each time I read the piece I find new value in it.
More readings on Architecture.
sdmouton dot wordpress 