On Architecture: It Is What It Is Because It Was What It Was
- Measurable But Variable Forces
- The Harvest Continues
- Incremental Change
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
This article is provided courtesy of IEEE Software Magazine.
One of my working hypotheses in creating a software architecture handbook is that, for a given domain, only a small number of architectural patterns exists that delineate a suitable software-intensive solution. This is just a hypothesis—it would be premature for me to enumerate such patterns before cataloging the architectures of enough real systems, which is precisely the handbook's point—but it's a reasonable one. Every engineering problem has an associated solution space, and each specific solution in that space serves to balance the forces that weigh on that problem.
For all systems in the real world, the laws of physics circumscribe the set of all possible solutions. For example, the speed of light isn't just a good idea, it's the law; and the computability of NP-complete problems really does have theoretical limits. Business issues might further constrain the envelope of possible solutions: for instance, in designing a house, if my budget can only afford bricks, I'll have to forego quarried stone. Tangible forces (do I have a suitably skilled workforce to construct and then operate my system?) as well as more elusive factors (is my solution beautiful and resilient to change?) also restrict any solution space.
Measurable but variable forces
In every engineering domain, most forces are measurable and thus testable, although to varying degrees of fidelity. Furthermore, while a given force might have a specific value at any given moment, the more interesting and difficult forces will vary over time. For example, in architecting a building, you must form a solution that resolves the physical forces of tension and compression associated with both dead and live loads. In city planning, the inertia of existing structures, the patterns of historical and contemporary use, and the codification of these structures and patterns in zoning laws will constrain any solution. In architecting a software-intensive system, the attendant forces will be akin either to those of buildings (for point applications), cities (for systems comprising many such applications), or even nations (for systems of systems).
Consider a few examples. For discrete stochastic simulations, most solutions are architected around the use of an event queue. Many animation-rendering engines have pipeline architectures. Most business enterprise systems are essentially instances of message-passing architectures (for example, service-oriented architectures) augmented by mechanisms for persistent state (such as relational databases). Many command and control systems, which involve much more transient state, use a semantic network as the center of their static architecture and message-passing mechanisms as the center of their dynamic architecture. Speech recognition systems commonly use blackboard architectures.