TL;DR
Phase B develops the Business Architecture first because data, application, and technology architectures must support the business. The practical approach is to reuse what already exists, fill missing business architecture content, confirm business value, and create a clear basis for Phases C and D.
Why Business Architecture comes first
Business Architecture is the first domain architecture activity in the ADM cycle.
It comes before data, application, and technology architecture because those later architectures exist to enable business outcomes.
Phase B should make clear:
- what business value the architecture supports
- how the target business direction links to business drivers, goals, and requirements
- why the architecture effort is worth the investment
- what data, application, and technology architecture must support next
Two starting situations
| Situation | What to do |
|---|---|
| Parts of the Business Architecture already exist | Verify and update the documented business strategy, business plans, and existing business architecture descriptions. Bridge high-level drivers, strategy, and goals to the specific business requirements relevant to this architecture effort. |
| Little or no Business Architecture exists | Research, verify, and gain buy-in for the key business objectives and processes that the architecture must support. Develop the missing business architecture descriptions and models. |
In both cases, Business Scenarios can help reveal the key business requirements and the implied technical requirements for IT architecture.
Practical flow
flowchart TD A["Use Phase A outputs"] --> B{"Business Architecture already exists?"} B -->|"Yes"| C["Verify and update existing strategy, plans, and views"] B -->|"No"| D["Research objectives and processes; gain buy-in"] C --> E["Bridge drivers and goals to business requirements"] D --> E E --> F["Use Business Scenarios where helpful"] F --> G["Reuse repository assets and reference models"] G --> H["Model capabilities, value streams, organization, and processes"] H --> I["Business Architecture supports Phases C and D"]
Reuse before creating
Reuse saves time and keeps the architecture consistent with the rest of the enterprise.
Look for:
- existing Architecture Definition Documents
- high-level architecture descriptions from Architecture Vision
- enterprise-specific business architecture views
- industry reference models
- applicable standards
- reusable building blocks
The Architecture Repository should be the first place to check before creating new content.
Check whether the business view is changing
Ask whether the fundamental view of the business is changing.
If it is not changing, use existing views to determine:
- project scope
- priorities
- relationships to the rest of the enterprise
- dependencies on other architecture work
If the needed architecture descriptions are not available, develop them. Gather enough information to create the business architecture models needed for the architecture effort.
Models to use
Useful Business Architecture models include:
- business capability maps
- value stream models
- organization maps
- business process models
- industry-specific modeling techniques
- Unified Modeling Language (UML), where appropriate
For the broader Business Architecture context, see Architecture Domains.
Exam note
- Business Architecture is the prerequisite for data, application, and technology architecture.
- Phase B links business drivers, strategy, goals, and requirements to a target Business Architecture.
- Reuse existing architecture material where possible.
- If Business Architecture is missing, develop the required descriptions and models.
- Business Scenarios can clarify business requirements and implied technical requirements.
- Architecture Repository assets help save time, improve consistency, and reuse best practices.