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
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.
subscribe via RSS