Imagine a training provider whose booking and course teams each expect the other to arrange an alternative when a course is cancelled. The architect must clarify the service promise, ownership and shared information.
Compare what each approach helps you decide and retain for the next change.
In this example, a capability is the ability to resolve a cancelled booking. A value stream describes the stages through which the learner receives an acceptable resolution. A process describes the activities, decisions and handovers used to provide it.
Contributions
| Approach | Contribution to business architecture | Question to ask when applying it |
|---|---|---|
| TOGAF business architecture guidance | The Open Group’s guide index includes capabilities, value streams, business models, organisation and information. Its Architecture Development Method places business architecture within a wider architecture process. | Which business decisions need that wider process, and which can be resolved locally? Select the relevant guidance without assuming every deliverable is needed. Sources: guide index, method and modelling roles. |
| BIZBOK | The public introduction to the Business Architecture Guild’s body of knowledge identifies capabilities, value streams, information and organisation as business architecture domains. | Does the description connect those views, or provide isolated diagrams? The public version 11.0 introduction is the reference used here; this is not a review of the full guide. |
| Zachman Framework | A classification structure for enterprise descriptions: questions such as what, how and who, considered at different levels of abstraction. | Which important description or relationship is missing? Classification alone does not decide the order of work or how often to revisit it. The author’s definition explicitly separates the framework from a methodology. |
| Architecture Portal’s proposed comparison model | Proposes questions connecting business purpose, records kept between changes, delivery decisions and lessons from running the service. Readers would use them to compare recurring decisions, speed and quality. | What persists between changes, who can accept a change, and what triggers a wider review? This model is in development; its usefulness and the work it requires need testing through application. |
These sources have different purposes. A body of knowledge helps describe the business; a classification framework checks coverage; a development method organises decisions and work. To use them together, show how their concepts and responsibilities correspond.
Business views
The training teams also need a shared record of the resolution the learner accepted and the person responsible for arranging it. That connects the process to the information and ownership needed to make it work.
These are working distinctions for this fictional example. Compare them with the definitions in the approach you use. A useful record should show their relationships, rather than repeat the same account under several headings.
Diagramming is a separate choice. ArchiMate can express architecture relationships; Business Process Model and Notation (BPMN) can express a business process. Choose the detail your reader needs to make the decision. Neither notation determines how the architecture work proceeds.
Methodology configuration
Map the terms and steps in this comparison to your own methodology or framework. Your method may describe service users as actors, for example, or organise decisions into different stages and reviews. Check what each term includes and how the work fits together. Categories can be combined, split or renamed to suit that structure.
The mapping helps relate advice about interactions and trade-offs to your own work. See Methodology configuration for an introduction to tailoring.
Change and continuity
The provider could first agree responsibilities across the whole booking service, then improve individual handovers. It could instead begin with cancellations, learn from use and extend the scope later. These are just illustrative choices.
The wider initial scope may make dependencies easier to plan, while delaying feedback from use. The smaller scope may produce feedback earlier, while requiring more coordination as shared responsibilities emerge. Test these possibilities in the setting where the work will be used.
For either arrangement, record four things:
- The business decision and outcome the architecture must help achieve.
- The accepted definitions, relationships and decisions that persist into the next delivery or review cycle.
- Who can change them, and what finding requires a wider business decision.
- How you will judge the result: time to a useful decision, review effort and rework, alongside the service’s ease of development, support and change.
Use the comparison to identify a missing decision, relationship or handover. Choose a checklist or template that helps close that gap. The Open Group’s template catalogue is one source to inspect. Judge a completed record by how it helps the next decision or handover.
Continue with cycles and decisions, or see these questions applied in the worked example.