By Scott Ambler, Consulting Methodologist, Ambysoft Inc.
In Agile Architecture for Software Development Teams – Being Agile I argued that an important aspect of the agile architecture mindset is to model just enough. This is a fundamental agile concept, to create artifacts, including models, that are sufficient given the context of your situation. In the Agile Modeling method we coined the term just barely good enough (JBGE) to describe this principle. If this term makes you uncomfortable you don’t need to worry, you’re not alone. This article explores common concerns that you may have.
Just Barely Good Enough Is Your Most Effective Architectural Modeling Strategy
For some reason people think that JBGE implies that the artifact isn’t very good, when in fact nothing could be further from the truth. When you stop and think about it, if an architecture model is JBGE then by definition it is at the most effective point that it could possibly be at. Figure 1 plots value vs effort for an artifact, showing that the point where an artifact is JBGE is the maximal point of a diminishing returns curve. Value refers to the net benefit (benefit – cost) of an artifact. The dashed line is at the point where the artifact is JBGE: anything to the left of the line implies that you still have work to do, anything to the right implies that you’ve done too much work.
Figure 1. Cost analysis of just barely good enough.
When you are working on an architecture model, and it isn’t yet sufficient, then you can still invest more effort in it and gain benefit from doing so (assuming of course you do work that brings the model closer to its intended purpose). However, if your architecture model is already JBGE (or better) then doing more work on it is clearly a waste: once your model fulfills its intended purpose then any more investment in it is simply busy work.
Yes, You May Still Over Model Your Architecture
Ideally your architecture model should be JBGE. Unfortunately, it isn’t an ideal world. There are three common reasons why you’ll likely overshoot the ideal:
- Accidental. You’ll put too much effort into the model, unintentionally overshooting the mark as you work on it. For example, do I really need the arrowhead on the rightmost end of the value curve in Figure 1? If not, then the diagram is more than just barely good enough.
- Purposeful. When you’re new to the concept of JBGE it’s a bit scary at first. It can be comforting to purposefully overshoot, to do more than is required, just in case you’ll need it later. However, the reality is that if later you do realize later that you need something more, or something else, you can likely model it at that time.
- Change. Sometimes you create an architecture model that is JBGE and then the situation changes and you discover that your model now contains extra material, out of date material, or is simply missing material.
Architects are only human, and they are not always going to do a perfect job. The secret is to learn how to detect when you’ve reached the point of something being just barely good enough and then to stop working on it. Easy to say, hard to do.
Just Barely Good Enough is Situational
The fundamental challenge with JBGE is that it is situational. For example, I often draw a diagram on a whiteboard to explore complex logic and then discard it once I’m done with it. In this case a whiteboard diagram is fine because it helps me to solve the issue which I’m thinking through with whomever I’m working. But, what if we’re in a situation where we’ll need to update this logic later AND will want to do it via the diagram instead of via source code? Clearly a hand-drawn sketch isn’t good enough in this case and we’ll want to create a detailed diagram using a sophisticated software-based tool (even if it’s just PowerPoint). We’d still create an agile model even though it is much more sophisticated than a sketch because JBGE reflects the needs of the situation.
To determine if an architecture model is JBGE you must actively work with the direct audience of that artifact. In the case of a business architecture model this would be both your business stakeholders and the implementation team(s) that are going to work with the model. Without knowing what the audience wants, you cannot realistically create something which is JBGE, putting you in a situation where you’re motivated to put far more effort into the artifact than you need to. This often proves to be wasted effort, because chances are very good that the model will fall prey to Agile Modeling’s they aren’t going to read it (TAGRI) principle. To ensure that you know what the audience of an architecture model wants, you need to ensure good communication with them and better yet strive for active stakeholder participation.
Just Barely Good Enough Doesn’t Imply Low Quality
Some people seem to think that models that are JBGE will be of low quality. The reality is that they are of sufficient quality for the job at hand. JBGE isn’t an excuse for doing a poor-quality job, rather it is a motivation to understand the context in which you work. This can be challenging because quality is in the eye of the beholder: the audience for an architecture model determines if it is sufficient, not the creators of it. If your stakeholders require an excellent, detailed model then it is JBGE when it reaches that point of being excellent and detailed.
Here’s an uncomfortable observation for traditionalists: When an artifact is more than JBGE then the extra information in that model proves to be technical debt. In other words, it lowers the quality of your work, not increases it.
Just Barely Good Enough Changes Over Time
An architecture model can move along this value curve in both directions throughout its lifecycle. Your needs may change, becoming either more complex or less so, and therefore you may choose to update your model(s) accordingly. If a model becomes less than good enough then you will need to consider updating it.
If an architecture model is more than good enough then you should rework it only if it is harming your efforts elsewhere. For example, a hand drawn diagram would have been sufficient for Figure 1 except that at the time that I drew it I didn’t have easy access to any writing materials (such as paper or a whiteboard) so I used Microsoft Visio instead. Later, when I did have access to such materials I didn’t bother to replace the diagram because that would have been useless busy work.
For a second example, let’s say I don’t like the current heading along the X axis and believe that Expenditure would be better. Would it be worth the effort of starting up Visio, reading in the file, updating it, generate the JPG, edit this article to rework the text to match the diagram, review the article to ensure that I got it right, do any necessary fixes, and then commit the changes to version control? Sounds like at least five to ten minutes of effort for almost no value. The current X axis heading isn’t “wrong enough” to warrant this investment (actually, I think the current heading makes sense). In fact, this sort of update would actually decrease the value of the diagram because the cost is greater than the benefit.
Just Barely Good Enough Comes Sooner Than You Think
Traditionalists seem to assume that significant investment in modeling, and corresponding specification, will continue to add value over time. Practice, however, shows that the value in modeling comes through improved communication and ability to think things through, and that this value peaks rather quickly. For example, for initial up-front modeling this typically occurs after several days or a couple of weeks (naturally for high-risk initiatives you may want to invest a bit more time with initial modeling). Even for enterprise architecture you still only want to invest a couple of weeks on initial modeling. For sprint/iteration modeling it’s even shorter, usually just a few hours, and for impromptu model storming on the order of minutes.
The fundamental challenge is that JBGE, like quality, is in the eye of the beholder. You know it when you see, there are no hard and fast rules. There are, however, known heuristics which we explore in the second article in this two-part series. Stay tuned.