Skip to main content

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



Popular posts from this blog

An Observation

Much has changed in the past few years, hell, much has changed in the past few weeks, but that’s another story... and I’ve found a little time on my hands in which to tidy things up. The world of non-functionals has never been so important and yet remains irritatingly ignored by so many - in particular by product owners who seem to think NFRs are nothing more than a tech concern. So if your fancy new product collapses when you get get too many users, is that ok? It’s fair that the engineering team should be asking “how many users are we going to get?”,   or “how many failures can we tolerate?” but the only person who can really answer those questions is the product owner.   The dumb answer to these sort of question is “lots!”, or “none!” because at that point you’ve given carte-blanche to the engineering team to over engineer... and that most likely means it’ll take a hell of a lot longer to deliver and/or cost a hell of a lot more to run. The dumb answer is also “only a couple” and “

Inter-microservice Integrity

A central issue in a microservices environment is how to maintain transactional integrity between services. The scenario is fairly simple. Service A performs some operation which persists data and at the same time raises an event or notifies service B of this action. There's a couple of failure scenarios that raise a problem. Firstly, service B could be unavailable. Does service A rollback or unpick the transaction? What if it's already been committed in A? Do you notify the service consumer of a failure and trigger what could be a cascading failure across the entire service network? Or do you accept long term inconsistency between A & B? Secondly, if service B is available but you don't commit in service A before raising the event then you've told B about something that's not committed... What happens if you then try to commit in A and find you can't? Do you now need to have compensating transactions to tell service B "oops, ignore that previous messag

Equifax Data Breach Due to Failure to Install Patches

"the Equifax data compromise was due to their failure to install the security updates provided in a timely manner." Source: MEDIA ALERT: The Apache Software Foundation Confirms Equifax Data Breach Due to Failure to Install Patches Provided for Apache® Struts™ Exploit : The Apache Software Foundation Blog As simple as that apparently. Keep up to date with patching.