Presumptive architectures
People used to say that nobody ever got fired for buying IBM. IBM mainframe systems dominated the market and the assumption was that choosing an IBM system was reasonable. Today, many domains have a software architecture that dominates the same way that IBM mainframes once did. These are presumptive architectures.
A presumptive architecture is a software architecture (or a family of architectures) that is dominant in a particular domain. Rather than justifying their choice to use it, developers in that domain may have to justify a choice that differs from the presumptive architecture. Incurious developers may not even seriously consider other architectures or have the misapprehension that all software should conform to the presumptive architecture. Presumptive architectures are similar to *_reference architectures_*. A reference architecture is a specification that describes an architectural solution to a problem. You can find reference architectures for high-reliability embedded systems or for using a particular vendor’s technology to build web-based systems. A publisher of a reference architecture may hope that it becomes a presumptive architecture, but that may not have happened, or may never happen. That is, a reference architecture may be aspirational standard, while a presumptive architecture is a de facto standard.
Presumptive architectures succeed because the architecture is a good match for the common risks in the domain. For example, Information Technology (IT) systems often face concurrent access to shared data, shifting business rules, and long-lived data. A tiered system is a good match for those problems. One tier handles the user interface, another handles the business processing logic, and another stores data to a transactional (and often relational) database.
Another example of a presumptive architecture is the use of cooperating processes in an operating system, which is a long-running system that must gracefully recover from faults occurring in its software. Operating systems differ in many ways, but almost all of them are constructed with a kernel and a set of cooperating systems processes. By running tasks in separate processes, faults in an individual task can be isolated and the task can be restarted, preserving overall system functionality.
I have introduced the term presumptive architecture because it would be a mistake to ignore these 800-pound gorillas and instead believe that all developers will start with first principles on their software architecture. IT developers who use the presumptive N-tier architecture will almost always do fine. In fact, their real architectural decisions may only be which COTS (Commercial Off-The-Shelf) software will be used on each tier, for example which brand of relational database or web application server to use.
