Architecture: work in progress
Business architecture
- Last reviewed
- 30 June 2026
- Owner
- Head of Architecture
Guidance on business architecture methods, including mapping, modelling and creating consistent capability models.
In DfE, business architects may may have different roles and responsibilities. Although their work may vary, it's useful to have agreed best practice that sets out how common business architecture activities should be carried out.
Accepted best practice gives business architects guidance on creating artefacts. It can help them start work more quickly by reducing the need to define an approach for each task. It can also support combining and comparing artefacts by providing a consistent approach where needed.
Many business architecture practices might be suggested or used in DfE. Whilst the practices offered below are considered sensible for DfE, none are mandated.
Business architects should refer to DfE's subject taxonomy (opens in new tab, DfE SharePoint users only) (link opens in new tab) and common definitions for terms and definitions, for descriptions of some of the ‘things’.
Mapping
Maps are high-level visual representations of the things being mapped.
As a minimum, mapping should:
- show the things being mapped
- show the relationships and flows between them
The purpose of mapping is to help people understand and communicate about the things being mapped.
The recommended basic mapping tool in DfE is Microsoft Visio. For more complex mapping exercises, use ArchiMate compatible tools, such as Archi.
Examples of things business architects typically map:
- value streams
- organisational structures
- stakeholder relationships.
Modelling
Models are detailed, structured representations of what is being modelled.
Modelling in the context of business architecture should focus on describing and simulating business activities, or ‘what’ an organisation does.
The purpose of modelling is to aid analysis of business activities to drive improved decision making.
The recommended basic modelling tools are Microsoft Visio or Excel. For more complex modelling exercises, use ArchiMate compatible tools such as Archi.
Examples of things business architects typically model:
- business capabilities
- processes
- information or intelligence (from data)
- operating models
- services
Capability modelling
As described in common definitions, capabilities are abstract concepts used to describe what we do.
To deliver most value in an organisation, capability models should be comparable and therefore need to be created in a consistent manner. This ensures clarity, reliability and usability for various stakeholders and across initiatives.
In DfE, capability models should follow the following guidance.
Categorisation
Capabilities should be categorised as strategic, core or enabling
Levelling
Capabilities should be levelled (decomposed), usually to 3 levels, with the following characteristics:
- level 1 - broad scope, stable and enduring, often cut across organisational groups, can be easily decomposed
- level 2 - operational focus, narrowing to actionable scope, relatively stable, direct ‘child’ of a level 1 capability
- level 3 - process or task focused, specific scope, subject to regular change, direct ‘child’ of a level 2 capability
A generic example of levelling is:
| Level 1 | Level 2 | Level 3 |
|---|---|---|
| Customer Relationship Management |
|
|
| Product Development |
|
|
| Supply Chain Management |
|
|
Scope
Avoid defining capabilities that are so broad they cover multiple unrelated areas or are too abstract to be useful. Broad capabilities often need too many levels of decomposition before they become practical.
For example, the following capabilities are too broad:
- delivering customer services
- managing financial operations
- developing products and services
Definition
Capabilities should be described to a level of detail that is easily understood and unambiguous, to ensure clarity, aid ease of use and avoid risk of duplication.