IT complexity is often described using metaphors such as “the big ball of mud” or the “software hairball syndrome” to illustrate a haphazardly structured software system. What intrigues me about these systems is their stubborn ability to morph into existence and their persistence. Almost all the companies that I’ve worked with over the years have at least one of these systems and many are several systems intertwined. And they are clearly problematic to maintain and change.
While searching for answers, four approaches repeatedly turned up in different disguises:
- Delegate – typically to the Enterprise Architecture team, so when it doesn’t work, we can blame them (win either way).
- Let’s move it to the cloud – it is same shape, so it should fit (Mud as a Service?).
- New tool – where is that mud removing feature?
- New method – the IT department is incompetent, so they’ll need a bit of extra help.
Leaving the tongue-in-cheek behind, all the approaches seemed to me like going on a diet. Sure, if there is a lot of complexity then we need to remove it. But diets are rarely much fun, which makes it hard to motivate people and easy to stop regardless of achievements. In fact they often make the problem worse, because they don’t stop you from regaining weight. Diets also don’t address the reason behind the excess weight – we need to look at our habits to find (one of) the reasons.
People don’t create complexity on purpose or out of incompetence. Complexity is rarely in people’s own interest. And if we were incompetent then large corporations shouldn’t be able to function; let alone reasonably well. So why do we end up with complexity despite our best efforts?
While I cannot claim to have the answer, I do think the problem is closely related to how an organisation makes design decisions.
Conway observed that the organisation’s communication structure is mirrored in its software systems. That is the organisation’s accumulative set of design decisions agreed through the organisation’s communication structure is what forms the systems. Software architecture is about guiding and constraining design decisions, which architects facilitate through the available communication structures.
But there is obviously more to it than just structure – what (the decision) we communicate are also important.
Tyree and Akerman’s article, “Architecture Decisions: Demystifying Architecture” (PDF) describes the elements (“what”) of an architectural decision well. Their definition stress the importance of capturing the decision context such as the associated requirements, constraints, related decisions, and rationale (labelled “context D” in below diagram); as well as the consequences (also referred to as implications). We tend to think of consequences as something relative localised, but architectural decisions often have a much wider impact in four different dimensions: project, system, domain, and enterprise. The same decision will have different consequences depending on its context (“C”):
- the project; the context for making and implementing decisions
- the system; that is the changed system or impacted another system change
- the domain; a horizontal aspect such as security, operations, or a single, enterprise wide business function
- the enterprise; the synergy of all domains
The third part is decision priority. Some decisions cannot be made before others, while others are closely interlinked. We structure decisions into decision dependency trees (explicitly or implicitly). In a pure architect only world, we’ll expand and prune the decision tree, as we work our way through it while carefully evaluating the available options. In reality, there are many influences on the decision priority including schedule, cost, available information and the organisation itself (labelled as context P).The above diagram seeks to illustrate the three parts: Priority, Decision, and Consequence with their respective contexts. For smaller teams, context C, D, and P are just “the context”, but this is rarely the case within larger organisations. What is the result of this less than perfect context overlap (between P, D, and C)?
Context Misalignment Creates Complexity
Most architects have experienced the scenario, where project schedule drives the decision priorities. This forces the need to take shortcuts through the decision tree, and we risk making less than ideal decisions, either because we don’t have time to find the required information or have insufficient time to perform proper analysis. Another key factor is the organisational structure itself. Bass and others found that projects run into problems, when the chosen architecture required subsequent communication needs which the organisation structure couldn’t support – the anti-pattern of Conway’s Law if you like. What’s interesting about Bass’ findings is that we give priority to decisions that we can solve with a given organisational structure. We do this rather than focus on changing the organisational structure to support the actual, required decision structure.
Making decisions without consideration for their multi-dimensional impacts will also cause problems. While we tend to blame the project manager for forcing us to consider the schedule, cost and available resources, architectural decisions made without appropriate consideration for all four dimensions also adds to the complexity – for example:
- A functional focus without a view to operational domain (project vs domain) will add to the system support and maintenance cost
- Accepting system capabilities without questioning the functionality integrity (system vs domain) will compromise domain level capabilities
- Driving a strong domain strategy risks compromising core systems and the enterprise itself (domain vs systems vs enterprise), and;
- Ivory tower syndrome (enterprise vs the rest)
While IT complexity might be one of those impossible problems to solve, I believe that it goes along way to simply acknowledge and attempt manage the decision context.