Key takeaways
- Four domains: Business, Data, Application, Technology.
- Data and Application form the Information Systems Architectures of Phase C.
- Other domains combine views of the four base domains.
- Contextual = why, conceptual = what, logical = how, physical = with what.
- Levels span all domains and open up comparable alternatives.
Four domains, and composite domains
TOGAF supports four domains, accepted as closely related subsets of an overall Enterprise Architecture. In the ADM, Data and Application are developed together in Phase C under the name Information Systems Architectures, while Business belongs to Phase B and Technology to Phase D.
Other domains, such as Information Architecture, Risk and Security Architectures, or Digital Architecture, are built by combining appropriate views of the four base domains. They have no phase of their own.
- Business: strategy, capabilities, governance, organization, and key business processes
- Data: structure of logical and physical data assets and data management resources
- Application: a plan of the applications to deploy, their interactions, and their links to business processes
- Technology: digital architecture and software and hardware infrastructure capabilities (cloud, IoT, networks, middleware)
Abstraction: split to solve
Architecture abstraction is a technique that splits a problem into smaller ones that are simpler to model and therefore to solve. The levels are layered: work moves from high-level models to increasingly detailed ones, and each level spans all four domains.
Each level answers a fundamental question. These questions have no link to their use in the Zachman framework.
- Contextual, why? environment, scope, and motivation (goals, drivers, objectives)
- Conceptual, what? decomposed requirements and service models describing desired behavior
- Logical, how? components grouping the services, independent of implementation
- Physical, with what? physical components that realize the logical components
Reading the grid
Crossing domains and levels avoids two common confusions. The first is to think ‘physical’ means ‘technical’: every domain, including Business and Data, can be described at the physical level. The second is to jump from needs expressed as services straight to a product, skipping a vendor-independent logical structure.
At the logical and physical levels, several alternatives exist: services can be grouped into components in various ways depending on the chosen principles and criteria, then realized by different physical components. Abstraction makes these alternatives comparable before choosing. The conceptual level is also sometimes called service or behavior abstraction.
TERMS TO KNOW
The terms, in context.
- Architecture abstraction
- A technique that splits a problem into sub-problems that are simpler to model.
- Conceptual level
- The ‘what’ level, modeled with services; also called service or behavior abstraction.
- Logical level
- The ‘how’ level: implementation-independent components.
- Physical level
- The ‘with what’ level: real components that realize logical ones.
- Information Systems Architectures
- The name of Phase C, covering Data and Application Architecture.