I’ve lost count of the number of times I’ve seen systems architecture done badly. This is wearisome, and can be avoided.
Poor architecture tends to come either from inexperienced architects (too wedded to technology specifics, or too dependent on formal method) or from overly-experienced architects (stuck in a groove, or too independent of method).
In either situation, architects can easily lose track of the purpose of the work. That purpose is to efficiently enable the development of complex systems which meet a business need.
If a simple system is sufficient, then we’re unlikely to need a full and formal architecture. We should quickly be able to compare the likely features and serviceability characteristics of the system against the needs we’re trying to meet. But a complex system is different. Only with recourse to modelling can we adequately predict system behaviour.
But how much modelling is enough? This is where the whole thing becomes an art form, and where the right amount of experience makes all the difference. To help answer this question in a given situation, I often introduce the term “architectural significance”.
Something is “architecturally significant” if it has structural impact on the proposed solution. Sometimes that’s easy to spot, but seemingly small details can also carry this kind of significance – especially in a high-availability or high-security environment, where the nuances of a specific software behaviour might reduce reliability substantially, or present new attack risk.
So consider architectural significance when seeking to decide …
- How much detail must I get into, and why? (Depth)
- What set of systems must I understand? (Breadth)
- Must I model all of technology, data, applications, business processes, organisation etc.? (Let’s call this “Length” to complete the metaphor)
It’s worth thinking about your scope with respect to each of these dimensions before you embark upon any modelling work, and worth agreeing a position with stakeholders. As well as saving a great deal of time and money, senior managers tend to welcome this discussion as long as it’s rooted in purpose and practicality. It’s highly likely in almost any large organisation that IT architecture has become a little infamous for its lack of relevance and focus, and a move towards significance-based modelling is a refreshing change.
One last suggestion from me, then over to you for comment: Be cautious not to be overcautious! It’s easy to overestimate the amount of modelling you need, with a view to reducing risk as far as possible. But is it really healthy to spend an extra man-month modelling around a 1% probability risk which would cost 2 man years to fix if it happened to occur? No. It’s a false economy, and a disservice to your organisation. Counter-intuitive as it may seem, start Shallow, Narrow and Short … and get Deeper, Broader and Longer only if you need to.