Overview
A central issue in Enterprise Architecture is Business-IT alignment: how to effectively match the Business, Application, and Technology layers. Chapter 10 describes the specific relationships the ArchiMate language offers to model these essential links. By connecting concepts across layers, architects can reveal how strategic goals translate into operational structures, making it easier to analyze dependencies, identify gaps, and guide enterprise-wide change. The chapter focuses on the alignment of core layers, the use of service-orientation to bridge domains, and the mechanism of derived relationships that allow for direct tracing between the highest and lowest levels of the architecture.
Introduction
The ArchiMate language uses a service-oriented approach to distinguish and relate the Business, Application, and Technology layers. The most important connection between these layers is the serving relationship, which illustrates how the services or interfaces of a lower layer provide functionality to elements in a higher layer. A second critical link is the realization relationship, where concrete elements in lower layers realize more abstract elements above them—for instance, an artifact in the Technology Layer realizing a data object in the Application Layer.
Layers are ordered to reflect these dependencies: Strategy → Motivation → Business → Application → Technology → Physical → Implementation. This structured hierarchy ensures that what is visible in the architecture is always grounded in the support of the layers below it. Furthermore, ArchiMate allows for indirect dependencies; through the derivation of relationships, an architect can trace how a technology object indirectly realizes a business object by following the chain of modeled relationships through the Application Layer. This capability is vital for impact analysis, as it allows stakeholders to see how a failure or change in technical infrastructure propagates upward to disrupt business processes.
Practical Examples of Cross-Layer Dependencies
- Data Traceability (Realization): A “Customer Database Table” (Technology Artifact) realizes a “Customer Data” (Application Data Object), which in turn realizes the “Customer Information” (Business Object) used by sales staff.
- System Support (Serving): An “Application Hosting” (Technology Service) serves a “Financial Application” (Application Component), which provides a “Billing Service” (Application Service) that serves the “Send Invoice” business process.
- Infrastructure-to-Application Mapping: A “Mainframe” node runs “DBMS” system software, which realizes a “Data Access Service” (Technology Service). This service is then used by (serves) multiple application components, such as a “Legal Aid Back-Office System”.
- Derived Relationship for Impact Analysis: If a “Financial Application” is assigned to a function that realizes a service serving an “Invoicing” business process, the AI can derive an indirect serving relationship directly from the application to the business process. This allows a business manager to see that if the application goes down, the invoicing process will be impacted, even if they do not understand the underlying technical functions.
- Interface Alignment: An “Accounting and Billing Interface” (Application Interface) is part of a broader Financial Application. This interface serves a specific “Business Role” (such as a Billing Clerk), providing them the access point needed to perform their duties in the Business Layer.
