Cube and Matrix

Our Cube is inspired by the “SunTone AM Cube” ¹, which in turn is based on the “layers” & “multi-tier” architecture patterns.

The architecture of a software solution is laid out using this cube concept, so that:

1. Components can be physically & logically grouped (or separated) based on primary responsibility (ex: UI rendering vs. business service enabling), thus fostering decomposition, decoupling, flexibility, etc.
2. The execution stack is also layered as a series of abstractions (ex: an app server can run on different operating systems, the OS can run on different hardware), thus allowing better portability, flexibility, scalability, etc.
3. System qualities (ex: security, performance, flexibility, availability, etc.) are treated as cross cutting concerns that need to be considered for all layers at all infrastructure levels (ex: securing a web service as well as the underlying server on which it runs)

The Matrix is simply an alternate representation of the cube that highlights the two facets of “solution layers” and “execution stack”. It is used as a starting point to specify the solution architecture. As seen in the “Architecture Specification Process” diagram, step1 is to document the business services needed (top row, third column). Step 2 is to document the artifacts to the right and left of this cell, thus specifying all the components of the software solution (top row, all columns). Step 3 is to document the rest of the rows that make up the execution stack on which the software solution will run. Architectural decisions regarding systemic quality requirements, KPI targets, risks to mitigate, patterns to employ, etc. can be made against each cell. All of this, in totality, makes up the architecture specification.

A sample matrix is provided below purely for illustration purposes. Note that an Architecture specification builds on this matrix with views (structure, behavior, deployment, etc.), patterns & strategies to achieve systemic qualities, etc.