The Irresponsible Architect

I was once told that we; as architects, should always do "the right thing"! What is "right" is of course debatable and since you can take many different viewpoints - financial (the cheapest), time (the quickest), security (the most secure), etc. - you can often have the argument with yourself quite successfully without  worrying about other peoples opinions.

But as architects it is often up to us to weigh the balance of concerns and seek a compromise which provides a reasonable solution from all viewpoints. Harder than it sounds, but that is what I choose to interpret as "the right thing".

There may still be many competing solution options which appear viable but some of those are false. Demons placed in front of you to tempt you into taking that first - and fatal - bite of the apple... The reason? Incorrectly ascribed responsibilities.

It is often easy to say "I need to do a lookup here" or "I need to parse this bit of data there" and it's often quick (and cheap) to JFDI and stick some dirty piece of code in where it shouldn't be. The code becomes more complicated than it need be as responsibilities become distributed throughout  and maintenance becomes harder and more costly as the days and years tick by. Finally you'll want to pour petrol over the machine and let the damn thing burn.

The same applies from an infrastructure perspective. Using a database server as a file-server because, well, it's accessible or using your backup  procedures as an archive because they're kind of similar(!?) is wrong. Tomorrow someone will move the database and it'll break, or your requirements for archiving will change and your backup solution will no longer be appropriate. Burn baby burn...

So before we sign off on the solution we have to ask "are the responsibilities of each component (logical and physical) well defined and reasonable?",  "are the dependencies and relationships to other components a natural (necessary) consequence of those responsibilities?" and "if I were to rip this component out and replace it with something else... would I rather immolate myself?".  If you answer "yes" to any of those then it's probably not "right". Probably.. not always. Sometimes you've just got to JFDI, sometimes you don't care about tomorrow (throwaway code, temporary tin etc.) and sometimes, just sometimes, you'll be wrong when you thought you were right (we're all fallible... right?). Once you have a clear view of the components and their responsibilities, then you can worry about the precise implementation details...

And finally, if a higher authority overrules you then so long as you've explained the rationale, issues and implications clearly, it's not your fault and you can sleep (or try to) with a clear conscience. Hey, you could be wrong!

So as a big fan of  keeping lists, for each component we need to define its:

• Responsibilities


• Rationale


• Issues and implications


• Dependencies and relationships to other components


• Implementation