Creating a Matrix from Domains

In Lesson 8, the BIT cube organized architectural artifacts across three dimensions: layer, scale, and view. In Lesson 9, the IT Architecture Scale provided the scale axis — seven levels from Global & Partner Ecosystem Architecture to Code & Infrastructure Build-Time Level. This lesson completes the transformation: when the BIT cube is unfolded, the result is a two-dimensional matrix. The rows of that matrix are the architectural domains. The columns are the IT scale levels. Each cell in the matrix represents a specific set of architectural deliverables — the concrete artifacts that an architect produces at the intersection of a domain and a scale level.

This is a deliverables matrix — not a responsibility matrix (RACI), not a requirements traceability matrix, but a structured catalog of what gets produced at each combination of architectural scope and domain focus. It is the tool that makes architecture manageable: instead of facing an undifferentiated mass of decisions, the architect navigates a structured grid where every cell has a defined scope, a defined audience, and a defined set of outputs.

Domains are the specific focus areas of architectural decision-making. The original framework identified five domains that partition the architectural problem space:

1. Business — the organization's processes, organizational structure, and geographic distribution of operations. The business domain defines what the system must support in terms of the organization's actual work.
2. Application — the major systems implementing business functionality. The application domain defines the software landscape that executes business processes.
3. Information — the data the organization cares about: who owns it, where it lives, how it flows between systems, and how it must be protected. The information domain is the connective tissue between business processes and the technical systems that support them.
4. Technical — the hardware, network, and operating system standards, and how they are managed. The technical domain defines the infrastructure within which everything else runs.
5. e-Architecture Feedback — the iterative signal from the architecture process itself, capturing lessons learned and informing subsequent architectural decisions.

Modern e-business practice has expanded this original five-domain framework. The Technical domain has been disaggregated into four more precise concerns: Technology (platform and stack selection), Integration (API strategy and inter-system communication), Security (identity, access, encryption, and compliance), and Operations (monitoring, disaster recovery, and deployment automation). Two additional domains have been added explicitly: Data (managing data assets, privacy compliance, and analytics) and User Experience (responsive design, accessibility, personalization, and performance). The resulting eight-domain framework maps directly onto the five BIT layers used in the deliverables matrix — the finer-grained modern domains are represented within the Business Architecture, Information Architecture, Application Architecture, Technical Application Services, and Technical Infrastructure rows.

Each domain can be viewed from each perspective on the IT Architecture Scale, yielding a building block. A building block is the unit of architectural work at a specific intersection — the set of decisions, artifacts, and deliverables that an architect produces when addressing a specific domain at a specific scale level. Building blocks are linked together: a solution architecture is constructed by defining a path through the matrix, selecting the intersections that are relevant to the engagement and producing the artifacts that belong there.

The deliverables matrix below is the unfolded BIT cube from Lesson 8. It has five rows — one for each BIT architecture layer — and seven columns — one for each IT scale level from Lesson 9. The "Point Solution" column corresponds to the Application Level Architecture in the IT Architecture Scale. Reading across a row shows how a single domain's deliverables change in scope and specificity as the scale narrows from global to build. Reading down a column shows how all five domains contribute deliverables at a single scale level — the full set of artifacts required at that level of architectural resolution.

The path an architect traces through this matrix for a specific engagement is the solution architecture. Not every cell is relevant to every project. The architect selects the intersections that matter for the problem at hand, produces the corresponding artifacts, and leaves a visible trail that documents the reasoning behind each decision. This traceability — the ability to follow a decision from the global business driver that motivated it down to the build-level component that implements it — is what separates architecture from ad hoc system design.

The deliverables matrix is more than a catalog — it is a navigation tool. The architect does not produce every artifact in every cell for every engagement. Instead, the architect selects a path through the matrix that corresponds to the scope of the problem being solved. An engagement focused on partner ecosystem integration will trace a path through the Global column across multiple rows. An engagement focused on application modernization will trace a path down the Application Architecture row across several scale levels. The selected path defines what gets produced, who produces it, and who consumes it.

Building blocks are linked together along these paths. A business driver at the Global level — say, the need to open a new partner channel — generates an information architecture requirement at the Enterprise level (partner data standards), which generates an application architecture requirement at the Point Solution level (partner API specifications), which generates a technical infrastructure requirement at the Management level (API gateway configuration). The matrix makes this chain of dependencies traceable and explicit.

The matrix also documents the process of e-engineering new business solutions. Each artifact produced at an intersection is a visible record of a decision — what was decided, at what level of the architecture, in response to what domain concern. This traceability is what allows the architect to demonstrate that the solution meets the requirements it was designed to meet, and to identify where the design must change when requirements change.

Understanding complexity across a wide range of choices is the competitive edge of this architectural framework. An e-business environment generates countless possibilities and new variants continuously — new platforms, new integration patterns, new regulatory requirements, new partner relationships. The deliverables matrix provides the structure within which that complexity can be navigated without losing coherence. The building blocks of architecture module, which follows this one, introduces the specific concepts and approaches prescribed by this course for constructing solution architectures from these building blocks.