What does the term "micro-architecture" mean to you? You probably have heard it somewhere. But, its meaning can vary depending on the domain/context most relevant to you: hardware or software (in broad terms). Micro-Architecture is not a new term. In the area of microprocessor design, the term micro-architecture has been used for a long time to describe processor design. A web search for micro-architecture yields almost all references to microprocessor design. There is even an IEEE committee on micro-architecture.
So, here is one definition of the term from Wikipedia:
Microarchitecture consists of a set of microprocessor design techniques used to implement the instruction set (including microcode, pipelining, cache systems, etc.).
And, here is another from The Anatomy of a High Performance Microprocessor:A Systems Perspective by Bruce Shriver and Bennett Smith:
Microarchitecture is the term used to describe the resources and methods used to achieve architecture specification. The term typically includes the way in which these resources are organized as well as the design techniques used in the processor to reach the target cost and performance goals. The microarchitecture essentially forms a specification for the logical implementation.
What I want to talk about is the usage of the term micro-architecture in software architecture. Here is one such perspective titled Micro-Architecture of Software Components (circa 1995), which tries to connect micro (object/component) level concerns to macro (application) level concerns. But that paper while filled with good intentions, I get lost quickly because I find it too confusing to link the two levels of abstraction. I feel the difference in abstraction levels make it hard to link those two levels. But, most references to micro-architecture take this approach to connect the high-level software architecture with low-level coding/implementation. Here is another paper with an interesting title One Architecture Does Not Fit All: Micro-Architecture Is As Important As Macro-Architecture. In this paper, micro-architecture is treated as software component engineering focussed on composition, compatibility and interoperability of componenets. And this too quickly gets into a discussion of low-level component design issues.
In the micro-architecture definition by Shriver & Smith above, if we replace "processor" with "system", the definition becomes pretty generic and can apply for hardware or software or anything in between. That leads to our definition of the same term as applied in software architecture.
Now I want to discuss how we started using the term in the area of enterprise software architecture. In the second edition of Core J2EE Patterns, we said this about micro-architecture:
We define micro-architecture as a set of patterns used together to realize parts of a system or subsystem. We view a micro-architecture as a building block for piecing together well-known, cohesive portions of an overall architecture. A micro-architecture is used to solve a coarser-grained, higher-level problem that cannot be solved by a single pattern. Thus, a micro-architecture represents a higher level of abstraction than the individual patterns.
Our
goal was, and still is, to document reusable combinations of patterns, where
each combination (micro-Architecture) solves a problem that is too large for
any one pattern to solve.
In the diagram I have attempted to show the conceptual decomposition of a overall Architecture into micro-Architectures, patterns, components and their relationships. However, there are some missing parts that I should mention that are not shown in the diagram. It is not always possible to describe an architecture entirely as a set of micro-Architectures. Partly because much work needs to be done in the area of documenting reusable micro-Architectures. The missing parts are contextual in nature and are gaps in the architecture that are not addressed by micro-Architectures alone. These gaps (which I tentatively want to call bridges & connectors) are filled by individual patterns and/or custom implementations to make the architecture complete. Thus you can view an overall architecture as a union of these 2 sets:
Architecture = {µArch1, µArch2, ... , µArchN} + {bridges & connectors}
Next, I will try to describe more about the relationship between µ-Architectures, Patterns, and Frameworks.
What do you think?
Architecture Pattern Software Design
