← Back to principles

Architecture

Business Driven Architecture

Statement

Business Driven Architecture

What this means in practice

Architecture decisions are anchored to business objectives, constraints, and value. Architects actively challenge and refine requirements to uncover the real problem being solved and ensure solutions deliver measurable outcomes. Technology choices are made deliberately, only where they create clear business value rather than optimising for technical novelty or convenience.

Why this matters

Business-driven architecture ensures that technical investment directly supports organisational goals and delivers return on investment. Without this focus, teams deliver what was asked for but not what was needed—solutions drift toward technical novelty or convenience, leading to poor ROI, misalignment, rework, and systems that fail to support business ambition.

Practices that meet this principle

  • Architecture proposals explicitly reference the business outcomes they support

  • Architects engage with business stakeholders to validate and refine requirements before committing to solutions

  • Technology selection criteria include business value, cost, and alignment—not just technical merit

  • Trade-off decisions are framed in terms of business impact, not solely technical preference

  • Architecture reviews assess whether solutions address the underlying business need

Validation

A project meets this principle when:

  • Architecture decisions can be traced to specific business objectives or outcomes

  • Technology choices are justified with clear business rationale

  • OR:

  • Solutions address the real business problem, not just the stated technical requirements

Scoring Guide

  • Score −1 — Disagreement / Rejected: The team acknowledges this principle is applicable but has explicitly decided not to follow it for this product. A rationale and decision record exist explaining why business-driven architecture is not adopted.

  • Score 0 — Not doing: Architecture decisions are made on technical preference alone. No connection between business objectives and technology choices. Requirements are taken at face value without challenge or refinement.

  • Score 1 — Planned: The team has committed work to adopt business-driven architecture. An owner and target date exist for introducing business rationale into architecture decisions. The plan is tracked.

  • Score 2 — Adopted for new work: All new architecture proposals explicitly reference business outcomes. Technology choices include business value and cost in the selection criteria. Requirements are challenged and refined with stakeholders before committing to solutions. Any exceptions are explicit and reviewed.

  • Score 3 — Enforced for new work + migration plan: Business-driven architecture is systematically enforced for all new work through process or tooling (e.g. architecture review checklists, proposal templates). A tracked migration plan exists to bring existing architecture decisions and legacy systems into alignment with business objectives.

  • Score 4 — Fully adhered: Architecture decisions across all work are traceable to specific business objectives. Proposals include measurable success criteria tied to business value. Trade-offs are consistently framed in business impact terms. Architecture reviews routinely assess whether solutions address the underlying business need. Legacy is largely compliant. Remaining gaps are minimal, known, and time-bound.