(Editor’s note: Part 1 appeared here: https://www.architectureandgovernance.com/agile/how-much-architecture-modeling-should-you-do-just-enough-part-1/)
By Scott Ambler, Consulting Methodologist, Ambysoft Inc.
In “How Much Architecture Modeling Should You Do? Just Enough” we explored the concept that architecture models should be just barely good enough (JBGE) for the situation that you face. While this is very easy to say, how do you know when something is JBGE? The quick answer is “It depends.” That’s a great answer if you’re a consultant, but not so great if you’re a practitioner. In this article we explore how to determine whether an architecture model is JBGE.
Just Barely Good Enough is Context Dependent
There’s an old saying: Quality is in the eye of the beholder. It’s the exact same issue with sufficiency: JBGE is in the eye of the beholder. Or more accurately, JBGE is context dependent. Figure 1 overviews the factors that motivate you to invest more effort in an artifact and those that motivate you to invest less effort. The challenge is that these factors are all qualitative in nature.
Figure 1. The factors to determine when architecture models are JBGE.
When You Should Invest More Time Modeling Your Architecture
The factors that motivate investing greater effort into an artifact are:
- Complexity. The greater the complexity, either problem/domain complexity or solution complexity, the greater the chance that you will need to invest more effort in modeling and documentation. Investing more in any modeling effort enables you to understand the implications of the complexity that you face and may even provide insight to help you to reduce that complexity. Addressing complexity is a positive reason to invest more in an artifact.
- Risk. Similarly, the greater the risk you face, and risk is often closely tied to complexity, the greater the chance that you will need to invest more effort in modeling and documentation. Modeling sessions can help you to better understand the risks that you face, thereby enabling you to identify effective ways to address those risks. Addressing risk is a positive reason to invest more in an artifact.
- Regulatory compliance. Anyone working in regulatory environments will likely need to produce more documentation than teams that do not. Having said that, the way that you interpret regulations is important – someone with a bureaucratic bent will belief that more documentation is required than someone with a pragmatic bent. Be smart about this. Regulatory compliance is a positive reason to invest more in an artifact when the regulations have been interpreted in a pragmatic way, otherwise it is potentially a negative reason that is increasing the cost and risk to your organization due to the challenges associated with excessive documentation.
- Artifact culture. Some organizations have what is called an “artifact culture,” a belief that they require a significant amount of documentation to support their way of working (WoW). Sometimes this is justified, for example in a regulatory compliance environment where the regulations have been interpreted in a pragmatic manner. Very often an artifact culture is not justified, being based on fear. If your reasoning is effectively “We need to create this because we MIGHT need it rather than we WILL need it” then that reasoning is based on fear. One symptom that you suffer from artifact culture is prescriptions that a team must produce certain artifacts to pass milestone reviews or quality gates. Another symptom is the requirement to fill out detailed templates when creating an artifact. Artifact culture is a negative reason to invest more in an artifact, my recommendation is to do what you can to surface the costs and risks associated with this cultural factor and work towards evolving your culture away from this over time.
When You Should Invest Less Time Modeling Your Architecture
The factors that motivate investing less effort into an architecture model are:
- Skill and experience. The more skilled and experienced the user of a model is, the fewer details that they will require.
- Ease of change. The easier it is to evolve an architecture model, the less effort you need to put into it because you will be able to readily improve it when required.
- Access to stakeholders. The easier it is to access the stakeholders, or more accurately the people who know that the model should address, then the less effort you need to invest in getting it perfectly right. This is because you’ll be able to easily update the model when you discover you’ve run into an issue.
- Collaboration and communication. The more collaboration and communication that you have with the customers of an architecture model, the less information it will need to contain because you’ll be able to easily work through the missing details together.
- Likelihood of change. The more likely something is to change the less effort you want to invest in describing it in your architecture model. This is because the model will get out of date faster and to a greater extent the greater the pace of change.
The most effective architecture models are just barely good enough, or just sufficient if you will, for the situation that you face. The challenge is that the determination of JBGE is contextual in nature, requiring experienced judgement rather than precise rules. In short, it depends.