Architecture vs Model

One of the biggest problems with business software is that architecture gets promoted more than the domain model. Further, most domain models are ordinary, and could be implemented by school students for a lot less cost than the 7-9 figures often spent. Yet, often the software architecture supporting a model—almost certainly anemic—is generally over engineered. A common brag goes something like: “the architecture can process 10,000,000+ messages per second!” But the architects fail to qualify that with:  “even if we will only ever need throughput of 1,000-10,000 messages per second.” So there you have it. The business pays for what it needs but gets everything other than what it needs. This is often because there is little to challenge developers to seek beyond the ordinary business solutions. Thus, typical software developers find architectural patterns and implementations more challenging and fulfilling. Even so, such patterns tend to be general and can be used on nearly every project. After implementing the same ones a few times, the luster wears off and greater challenges with newer mechanisms are sought. And the business still gets too little of what it needs. It might seem that better management is needed, or architectural governance, to prevent such forays into nebulous non-functional requirements, structure, components, and techniques. Yet, that’s not necessarily what is needed. Instead, it’s possible to make the domain models across a software system far more challenging and attractive than general-purpose architecture. To make domain models interesting—no, fascinating—to explore: challenge teams to pursue business innovation through experimentation and discovery-based learning. Failing experimentations are not complete failures, because the learning has the aim of leading to success. Think of your team of business experts and developers as driving innovation within a “sphere of knowledge,” their domain.

Think of it. While software architecture, and nonessential architecture at that, tends to be general purpose and recurring across many domains, if pursued with breakthrough intent, innovations that drive business competitive advantage can prove to be unique, one of a kind. That is very, very attractive. To innovate with domain models requires business experts and developers to explore and discover one-of-a-kind core competencies together. It might sound like a cliche, but there truly are known-knowns, known-unknowns, and unknown-unknowns. All three levels must be addressed, and can lead to breakthrough innovations. Essential to such an effort requires asking a few questions many times. Here is the first set of questions that can be used, and in no particular order:

• Why?
• Always?
• Why not?
• Are you certain?
• Immediately?

This forces business experts and developers to reach not only a shared understanding, but to discover new and more advanced understandings. At this point the model probably reflects the ordinary, or possibly a bit better, although it probably seems much better than the anemic models from previous projects. Still you have without a doubt not yet learned enough. Likely at best the result reflects addressing known-knowns and clarity around previously known-unknowns. So there’s probably still a considerable number of unknowns, whether you recognize them or not. To drive further, consider these concerns. Users can have problems that they won’t report because they can’t imagine something better. To prevent these situations in the first place, the team must challenge their knowledge and refuse to accept the ordinary. Here is the second set of questions to be asked to discover the corner cases:

• If we were to think one or two steps further, what would we learn?
• What could go wrong here based on the current model?
• Could the user get stuck on a problem from which it’s hard to recover?
• Could the model help by making solutions obvious?

Usually discovering the corner cases reveals opportunities to make the software far superior in ways that were previously unidentified. Even so, you will probably miss some breakthrough insights. At that point you must interview a range of users to find out what is difficult for them to do. Observation can also teach you a lot. If you see the software being used in unexpected ways, it almost certainly shouts out missing workflows and broader business processes. Note these and address them as first priority. Don’t “pre-tect” users from “wrong” decisions, because their current decision could be correct event though an earlier decision now conflicts. There’s a business process lurking. Such situations must be imagined or detected, explored, experimented within, and continually rediscovered through deep learning. When enough knowledge is gained to understand the problem and solution, be sure to show a spectrum of data and an array of options to help users reach smart resolutions quickly. Use tools that accelerate experiments and discovery and make it cheap and painless to toss out the inferior in exchange for best. Such tools are not commodities, but the exception. Note the comment by Andreas Grimm on this topic when it was presented on LinkedIn:

Yes, true. On the other hand, we might resist the urge to settle and try to take the original model on a breakthrough journey. It seems possible with refactoring, but conflicting concepts soon walk you off a cliff. If only we could reduce reimplementation to minutes rather than days, weeks, or months. Exactly! And that describes the tools in which we’ve invested heavily. XOOM delivers fully tested, bug-free, working domain models, reinforced by a compressed architecture that is responsive, scalable, resilient, and fully executable immediately. You focus on the delivery of innovative domain models that reflect true business solutions to complex business problems, and you get the leading edge architectures and architecture mechanisms that support Event-Driven and Reactive microservices and well-modularized monoliths.