By Ahmad Al Shami | Strategy, Enterprise Architecture & Transformation
Delivering a project and delivering a strategic outcome are different achievements. Business architecture helps leaders connect the two: from the reason for change, through the capabilities and initiatives required, to evidence that the change has created value.
Consider an organization that launches a customer portal, introduces an AI assistant and replaces a scheduling application. Each initiative can meet its own delivery commitments while customers still experience fragmented service. The missing connection may be shared information, an unresolved policy conflict or a handoff that nobody owns.
The leadership question is therefore broader than whether projects are on schedule: does the portfolio of change form a credible path to the intended business outcome?
A framework for connecting direction to delivery
The BIZBOK® Guide, Version 15.0, introduces a Strategy Execution Framework in Figure 1.5. It connects five stages: establishing business strategy, assessing business impact, architecting the business solution, establishing initiative plans and deploying the solution. Business architecture supports the path alongside other disciplines; it does not replace strategy leadership, portfolio management or delivery teams. [1, pp. 9–11]
The practical interpretation below explains how leaders can use those stages. The questions, example and recommended controls are my own application of the framework.
Define the outcome and why it matters.
Identify what must change across the business.
Choose a coherent business solution.
Sequence and fund accountable changes.
Deploy, adopt, measure and adapt.
1. Establish business strategy: make the intended change explicit
Begin with the business motivation, stakeholders and outcomes. “Become digital” is a direction; it is not yet a sufficient basis for an investment decision. Leaders need to explain what should improve, for whom, under which constraints and over what period.
For an illustrative tenant-service transformation, the ambition might be more reliable resolution of maintenance problems. The objectives could address repeat faults, unresolved cases and communication quality. The team would establish baselines and agree targets before promising benefits.
A useful leadership decision is to approve a concise outcome statement, an accountable business owner and the evidence that would demonstrate improvement. Conflicting objectives—such as faster service and tighter spending controls—should be visible at this stage.
2. Assess business impact: follow the outcome across boundaries
Next, examine which capabilities, value streams, information, business units, products and stakeholders are affected. The BIZBOK introduction describes capabilities, value streams, information and organization as the foundational business architecture domains. Their relationships provide a shared basis for examining change across organizational boundaries. [1, pp. 2–4]
In the tenant-service example, the impact reaches beyond the service desk. Maintenance coordination depends on asset history, supplier availability, purchasing authority and reliable completion evidence. A faster intake channel will have limited value if those dependencies remain unresolved.
My recommendation is to create a focused impact view linking each objective to the value-delivery stages and capabilities it depends on. Use it to identify overlapping investments, missing dependencies and decisions requiring more than one department.
3. Architect the business solution: design the change before choosing the projects
A business solution describes how the organization should work to achieve the outcome. It includes the future arrangement of responsibilities, information, policies and service delivery—not only the technology to be purchased.
For tenant service, the team might compare options for coordinated case ownership, access to maintenance history, supplier dispatch and verification of resolution. Process, information, application and technology specialists can then develop the relevant detail together.
If AI is appropriate, identify its bounded contribution. An assistant could summarize authorized records or propose next steps. Qualified people still perform diagnosis and physical repair; designated approvers retain authority for spending exceptions. Those are proposed design choices, not assumptions that autonomy will improve the service.
Evaluate alternatives against business value, feasibility, cost, risk and adoption demands. The strongest option may combine policy changes, improved data, redesigned work and selective automation.
4. Establish initiative plans: fund the changes the design actually requires
Translate the chosen solution into initiatives with explicit scope, dependencies, owners and acceptance criteria. The BIZBOK introduction emphasizes defining initiatives through relevant business architecture scope, connecting them to the objectives and solution they support. [1, p. 11]
In our example, a credible sequence could start with case-history quality and ownership, then introduce coordinated dispatch, followed by bounded AI assistance once permissions and reliable information are in place. This is an illustrative dependency sequence, not a universal implementation order.
Each initiative should answer four questions: which outcome does it support; what business change will it deliver; what must be available first; and who will accept and operate the result?
Portfolio governance can then make informed trade-offs. A shared capability should not receive contradictory changes from separate projects, and an initiative should not claim benefits that depend on unfunded work elsewhere.
5. Deploy the solution: confirm adoption and business value
Go-live confirms that a solution has been released. It does not, by itself, confirm successful strategy execution. The framework’s final stage includes deployment and success evaluation. It is recurring and adaptable rather than a one-time linear exercise. [1, pp. 10–11]
For the tenant-service example, assess whether people use the new arrangement, whether handoffs work and whether problems are being resolved more reliably. Review reopened cases, repeat faults, resolution evidence, full service costs and employee workload alongside delivery milestones.
If the pilot produces faster responses but more unresolved work, revisit the design. If a capability dependency has been underestimated, adjust the sequence. If the strategy itself changes, reconsider which initiatives still warrant investment.
Maintain traceability without creating unnecessary bureaucracy
My recommended management view is a small set of linked decisions:
Strategic objective → stakeholder value → affected capabilities and information → chosen business solution → funded initiatives → operational measures.
This is an explanatory traceability chain, not a prescribed BIZBOK metamodel. Its purpose is to make investment logic inspectable. Leaders should be able to move from an initiative back to its strategic rationale, and from an objective forward to the changes and evidence supporting it.
Business architecture supplies the shared structure and vocabulary. Operational, financial and performance systems supply actual results. The BIZBOK introduction distinguishes architectural transparency from financial analytics; a repository connection cannot substitute for measured benefits. [1, p. 5]
Make accountability part of the framework
A practical governance arrangement should assign clear responsibilities: leadership sets direction and resolves strategic trade-offs; the business outcome owner accepts responsibility for value; business architects make impacts and relationships visible; portfolio leaders sequence and fund change; delivery teams implement; and operational teams own sustainable adoption.
These are recommended responsibilities for adapting the framework. The supplied introduction references Appendix B.1 for detailed roles and deliverables, but that appendix is not included in the document reviewed. They should not be presented as its official role definitions.
Start with one strategic objective
Choose an important objective and examine its existing initiatives. Identify the affected capabilities and value delivery, test the proposed solution, expose missing dependencies and agree the measures that will confirm success.
The framework becomes useful when it changes an investment or delivery decision: an initiative is reshaped, a dependency is funded, ownership is clarified or an unsupported benefit is challenged. That is how business architecture contributes to strategy execution.
Explore the Domain Reimagination reference journey and Modelling Studio for supporting examples, or discuss a strategy-to-execution workshop.
Source and perspective
[1] Business Architecture Guild®, A Guide to the Business Architecture Body of Knowledge® (BIZBOK® Guide), Version 15.0 (2026), Part 1: Introduction; especially pp. 2–5 and 9–11, Figure 1.5. Based on the introduction supplied for this article. The complete guide and Appendix B.1 were not reviewed.
Independent commentary by Ahmad Al Shami. BIZBOK® and Business Architecture Guild® are trademarks of their respective owner. The example, explanatory visual and implementation recommendations are original interpretations; no Guild endorsement or client performance claim is implied.