TL;DR
In TOGAF practice and training, architecture abstraction is commonly explained with four levels — Contextual, Conceptual, Logical, and Physical — moving from high-level motivation to concrete implementation. They cut across all four domains (Business, Data, Application, Technology) and are distinct from the Architecture Landscape levels.
Why abstraction levels exist
Architecture problems are too large to solve in one go. Abstraction levels let you divide a problem area into smaller, layered slices that move from strategic intent to implementation detail.
Each level answers a different fundamental question about the architecture.
The 4 abstraction levels
| Level | Also known as | Key question | Focus |
|---|---|---|---|
| Contextual | Why level | Why is architecture work needed? | Enterprise environment, scope, goals, drivers, objectives |
| Conceptual | What level | What functionality and requirements must the architecture satisfy? | Requirements decomposition, desired behaviour, service models |
| Logical | How level | How should the architecture be structured? | Component organisation, structure — still implementation-independent |
| Physical | With-what level | With what assets will we implement the structure? | Concrete products, platforms, technologies, physical components |
flowchart TD CX["Contextual<br/>(Why)"] CO["Conceptual<br/>(What)"] LO["Logical<br/>(How)"] PH["Physical<br/>(With what)"] CX -->|"defines scope and goals for"| CO CO -->|"requirements guide"| LO LO -->|"structure realised by"| PH
1) Contextual level
The contextual level is about understanding why the enterprise is undertaking architecture work.
It captures:
- the environment in which the enterprise operates
- the scope of the architecture effort
- the motivation — goals, drivers, and strategic objectives
This level sets the foundation for all downstream architecture decisions.
2) Conceptual level
The conceptual level decomposes the requirements to understand what the architecture needs to deliver — without prescribing how it will be built.
It captures:
- functional and non-functional requirements
- desired behaviour and outcomes
- service models that represent what the architecture must do
Note
The conceptual level is sometimes called service abstraction or behaviour abstraction because it models desired behaviour through services rather than implementation components.
3) Logical level
The logical level identifies how the architecture can be organised and structured to achieve the services defined at the conceptual level.
It captures:
- the types of business, data, application, and technology components needed
- how components relate to each other
- structural patterns and groupings
The logical level remains implementation-independent — it defines the architecture shape without committing to specific vendors or products.
4) Physical level
The physical level determines with what concrete assets the logical components will be realised.
It captures:
- specific products, platforms, and technologies
- allocation of physical components to logical components
- deployment models and infrastructure choices
Note
There may be many valid ways to realise a logical architecture physically. Different combinations of physical components produce different solution alternatives, which are then evaluated based on principles, constraints, cost, and risk.
Abstraction levels cross all domains
The four abstraction levels are not limited to one domain. They apply across all four TOGAF domains:
| Domain | Contextual | Conceptual | Logical | Physical |
|---|---|---|---|---|
| Business | Why does the business need to change? | What capabilities and services are needed? | How are business functions organised? | What specific org units and processes are deployed? |
| Data | Why is data architecture needed? | What data entities and relationships exist? | How is data logically structured? | What databases and storage technologies are used? |
| Application | Why are application changes needed? | What application services are required? | How are applications structured and integrated? | What specific products and platforms are deployed? |
| Technology | Why is infrastructure change needed? | What technology services are required? | How is infrastructure logically organised? | What specific hardware, cloud, and network assets are used? |
Abstraction levels vs Architecture Landscape levels
These are two different concepts that work together:
| Concept | What it describes | Levels |
|---|---|---|
| Architecture Landscape levels | Scope and granularity of architecture work | Strategic, Segment, Capability |
| Abstraction levels | Perspective and depth of architecture description | Contextual, Conceptual, Logical, Physical |
The relationship: each Architecture Landscape level can be described at one or more abstraction levels.
For example, a Capability Architecture (narrow scope, high detail) can have:
- a logical description — implementation-independent structure
- a physical description — concrete products and deployment choices
This gives you two complementary architecture descriptions of the same capability at different abstraction depths.
flowchart LR subgraph Landscape ["Architecture Landscape"] direction TB S[Strategic] Seg[Segment] Cap[Capability] end subgraph Abstraction ["Abstraction Levels"] direction TB CX[Contextual] CO[Conceptual] LO[Logical] PH[Physical] end Cap ---|"can be described at"| LO Cap ---|"can be described at"| PH
Practical example: Cloud Migration
Contextual
Why: the enterprise needs to reduce infrastructure costs and improve scalability. Key driver is a 40% data centre cost increase over the next 3 years.
Conceptual
What: the architecture must provide compute, storage, and networking services with auto-scaling, high availability, and disaster recovery. These are defined as required service capabilities.
Logical
How: workloads are grouped into three tiers — web, application, and data. Each tier has defined interfaces, scaling rules, and security boundaries. No specific cloud provider chosen yet.
Physical
With what: AWS is selected. Web tier uses CloudFront + ALB, application tier uses ECS Fargate, data tier uses Aurora PostgreSQL + S3. Specific instance types, regions, and networking (VPC, subnets) are defined.
Exam note
- In TOGAF practice and training, architecture abstraction is commonly explained as four levels: Contextual (Why), Conceptual (What), Logical (How), Physical (With what).
- Abstraction levels move from high-level motivation to concrete implementation.
- They cross all four domains (Business, Data, Application, Technology).
- The Conceptual level is also known as service abstraction or behaviour abstraction.
- The Logical level is implementation-independent. The Physical level is implementation-specific.
- Do not confuse abstraction levels with Architecture Landscape levels (Strategic, Segment, Capability).
- Each Architecture Landscape level can be described at one or more abstraction levels.