What About Completeness?
A common objection is “But this way we never get a complete depiction of our architecture.” It is true. The focus of this way of doing things is on creating many true-but-incomplete assertions rather than a single complete-but-false one.
Of course, for your architecture documentation to stay true, you will have to maintain it. A property associated with value-stream-oriented architecture is that a single component or application may show up in several documents, each presumably focusing on a particular value stream.
For instance, imagine that for some (possibly magical) reason, you must get rid of Expedite Claim Service. While it’s not pleasant or particularly engaging, you could go back through all your architecture diagrams, find the ones that reference that subsystem, and make sure that your proposed change does not adversely affect them.
That may not even be a cost of doing things this way; it might be a benefit. After all, if you are going to change the interface of (for example) a service, wouldn’t you want to know about all the customer processes that might be affected? What better way to find out than by being forced to update the document for each one?