Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Evolving Designs
As you are probably aware, big designs that try to support all the potential kinds of variation a system might one day need to handle are the most effective way to ensure that a system will not be able to respond when a real need emerges. Working against a limited architecture and making changes as events develop allows systems to stay light and flexible.
A beneficial side-effect of starting with the value stream and working your way in is that it naturally confines the scope of a proposed architecture. Instead of prescribing an architecture that will supposedly one-day stand the test of time, you grow a system that is constantly responding to changing needs.
Imagine that an insurance company has successfully implemented and deployed the architecture depicted in Figure 5 from a previous section. This allowed them to move a certain percentage of their claims off of paper and into a fully-automated system. That transition yielded numerous benefits including a reduction in operating costs for applicable claims.
In fact, it’s been so successful that the company wants to expand the scope of the system to include investigations of claims that involve water damage. In this little universe, most of the water damage claims are easily expedited, notwithstanding the effort of investigating the damage itself. Of those that cannot be expedited, 99% are rejected as under the purview of flood insurance. So there’s a lot of low-hanging fruit to be had as a result of supporting these kinds of claims.
With a small, lightweight system such as the one produced by value-stream-oriented architecture, adaptation is inexpensive. You start by defining the new value stream you want to target. You’ll deal with claims that can be validated as non-flood-related to start (Figure 6).
)
As you can see, parts of the value stream for which there is already have been muted. Though this is not always the case, this time it is safe to “zoom in” on the new steps while modifying the architecture. In evaluating the new needs, it can be determined that there probably isn’t a reason for the existing infrastructure to change very much (Figure 7).
)
The resulting architecture will just barely be able to support the old value stream and the new one. Assuming that each system is developed, those few existing subsystems that have to chanoge can be extended without a “ripple effect” tearing through your system.
Each new value stream you support enriches the architecture of your system without placing the undue burden traditionally associated with a Big Design Up-Front.