- The Good Architect
- Enter Lean Principles
- What is a “Value Stream?”
- Tying Architecture to Value-Creating Steps
- Outside-In Design
- Evolving Designs
- What About Completeness?
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Tying Architecture to Value-Creating Steps
A common practice for software architects is to draw pretty pictures with boxes and lines that codify their vision of a system. I’m sure you’ve seen such a diagram. Maybe you even have produced a few.
Under a particular set of circumstances, this kind of planning can be useful and valuable. Those circumstances are as follows:
- The elements of a design must be traceable back to real value-creating steps, not cool technologies or outrageously-long-term goals.
- The plan must be recognized as a guess, not a commitment.
The second condition falls under the purview of agile software development. There are materials on that subject in copious supply, so I won’t address it here. This section focuses on satisfying the first requirement.
Consider the value stream shown in Figure 2 from the previous section. There are real steps that have to happen in there. They could be done with paper. They could be done with computers. They could be done by pressing the ends of broken reeds into unfired clay tablets.
For one reason or another, in this example, we think that the “computers” route is the right one. So it seems natural to design a system that directly supports the operations in the value stream we are targeting first (Figure 3).
)
A lot of organizations would be concerned by a design like that because it looks like it is purely focused on solving one and only one problem. It’s an understandable anxiety. You wouldn’t want to have to rewrite a feature again and again just because it is used in many different value streams.
A value-stream-oriented architecture can still result in well-defined, reusable subsystems. It just doesn’t start by considering those. Instead, the architect defines each layer of design in the context of the need demonstrated by a layer that is closer to the value-creating steps performed by his or her users.
Adding another layer might result in something like Figure 4.
)
Hopefully, at this point, you get the idea. To satisfy the rule of three, I’ll add another iteration, which might produce something like Figure 5.
)
){kind=link}
Note how, with each additional layer, the design looks a little more rational. At first, pieces that appeared to be disparate looked as if they didn’t facilitate a flow along the value stream. Likewise, seemingly insular applications appeared to invite duplication of work for any overlapping features.
However, when we added another layer, it became clear that those design elements merely set the context for the next layer. That layer, in turn, demonstrated how pieces from the above layer might interact.
After a few iterations, there is a clear picture of an architecture that can support the process you want to enable. A design like that is something to which a team can easily agree. In fact, a team can even be motivated to produce a high-level plan like this with the architect merely serving as a facilitator.
It’s also something that can be implemented pretty predictably. There aren’t a lot of new moving parts so there probably won’t be a lot of confusion about what goes where. There also aren’t a lot of detailed decisions being made so the team isn’t likely to be tripped up by a choice made too early.
Working this way allows you to leverage the power of outside-in design, the effectiveness of which has been demonstrated by numerous techniques in other areas of software development.