When there is a defect or problem, we try to do some ‘root cause analysis’ work out where the defect or problem is stemming from and try to fix the cause (hopefully) and not the symptoms of the defect. The same can be done (but is often not) for improving the architecture, rather than just working out what how we want our architecture be and making changes to get there, sometimes its better to take a step back and think why did it get like this in the first place. More often than not, bad design and architecture is a symptom of misalignment of organisation structure against true business ‘propositions’ or ‘products’. Think Conway’s Law, i.e. “Any organisation that designs a system will inevitably produce a system design whose structure is a copy of the organisations communication structure.”

If there is a misalignment between the business propositions and the organisation structure then the delivery of an optimised, maintainable,performant, flexible, scalable system is more than likely done on a best endeavours basisrather than by design. This may be a sweeping statement, but think about it. More than likely there will still be a one or more architects of various specialities i.e. enterprise, software, database, solutions, etc.. however, these people willhave a vision that becomes very difficult to deliver. They end upadapting a vision on a project by project basis, they don’t have the time to build a Future State Vision foreach of the domains making up the system, there isn’t enough consistency in what is happening from a technical perspective for each slice of ‘Business proposition’. More than likely they will be creatinga vision of the horizontal slices which make up the system (UI, Service, Database).

One option is to have more architecture resource so that an architect for each speciality can have enough input and enough visibility of what is happening within a project to make sure that design and delivery isoptimal and adheres to a centralised vision. But really, the problem that we are actually trying to resolve is to make sure that there is a consistent vision on the design and architecture of systems and sub-systems which meets the business needs both from a functional and operational perspective (note I said operational not ‘non-functional’, I hate the term non-functional) and is unlikely to need major re-write later on.

If delivery teams are structured so that they can take real full ownership of well-defined business propositions/products/features/functions all the way through a delivery process then  each team becomes empowered to deliver more than just a project’s functional requirements. Theyhave the longevity to create and deliver solutions which, over time takes us closer toward a future state vision.

Fixing the technical problems with the architecture but not looking at the organisation will more than likely lead to a situation in the future where someone is ‘fixing’ what  we’ve just done. Before putting duck tape of the cracks, it’s important to at first appreciate that the problem was allowed to happen because teams were organised by role/function rather than business proposition and that this has led to a lack of vision, ownership, and inadequate communication between teams.