TL;DR
Business principles, goals, drivers, and constraints provide the business context for architecture work. In Phase A, they are reviewed for clarity and correctness before detailed architecture design begins.
Why It Matters
Architecture work does not happen in a vacuum.
Business principles, goals, and drivers describe what the organization values, what it is trying to achieve, and what is pushing change. Business constraints describe the real limits the architecture project must respect.
These items may sit outside the architecture discipline itself, but they strongly shape how the architecture is developed in practice.
What Gets Reviewed
In Phase A, confirm that the business context is current and clear:
- Business principles: durable business rules or ways of working
- Business goals: desired business outcomes
- Business drivers: reasons or pressures behind change
- Business constraints: limits such as budget, policy, regulation, time, or organizational capacity
The structure can vary a lot by organization. Some organizations document goals and drivers in detail; others focus more heavily on principles.
TOGAF provides a template-style way to capture this as a statement of business principles, business goals, and business drivers.
Where It Comes From
A statement of business principles, business goals, and business drivers is usually defined elsewhere in the enterprise before the architecture project begins.
In ADM terms:
flowchart LR ORG["Enterprise context"] --> PRE["Preliminary Phase<br/>Restate principles, goals, drivers"] PRE --> A["Phase A<br/>Review and confirm"] A --> B["Phase B<br/>Design Business Architecture"] B --> CD["Phases C and D<br/>Validate Data, Application, Technology choices"]
The Preliminary Phase restates these items as part of setting up the architecture capability. Phase A reviews them again for the specific architecture engagement.
If They Are Unclear
If the principles, goals, or drivers are unclear, do not treat them as assumptions.
Go back to the originators of the Statement of Architecture Work, clarify the items with them, and secure their endorsement before continuing.
How Later Phases Use It
The confirmed business context becomes a reference point for later architecture decisions:
- Phase B uses it to design a Business Architecture that supports the business direction.
- Phases C and D use it to select and validate relevant data, application, and technology architecture resources.
Exam note
- Phase A reviews business principles, goals, drivers, and constraints.
- These items provide business context for the Architecture Vision.
- They are usually defined before the architecture project, restated in Preliminary, and reviewed again in Phase A.
- If unclear, clarify them with the originators of the Statement of Architecture Work and secure endorsement.