The two business-focused artefact types at the top of the Alignment Matrix are the hardest to develop, the most dependent on executive trust, and the last to mature in most organisations. They are also, ultimately, the ones that determine whether an EA practice is delivering genuine strategic value or merely providing technically competent delivery governance.
Business Factors and Business Visions are the strategic layer. They translate what an organisation is trying to do into what its IT capabilities need to become. Without them, the IT investment portfolio is driven by bottom-up demand — local business requests, urgent problems, technology replacements — rather than strategic intention. The portfolio may be well-managed. It is not necessarily well-directed.
Business Factors: operating rules for IT planning
The most important type is Principles — statements that actually shape decisions. The test: could this Principle be violated? If following it is always the obvious choice and no one would ever consider violating it, it contains no real decision and is worthless as a planning constraint.
“We support business agility” is not a Principle. “We prefer buying standard software over building custom, and any custom development requires explicit justification at Investment Forum level” is a Principle. The first could appear in any organisation’s documentation without meaning anything. The second will actually be argued about, and that argument is precisely what makes it valuable.
What makes a Principle operational is the Statement-Rationale-Implications structure:
Statement
What we do — a concrete, arguable position.
Rationale
Why we do it — the business or technical reasoning that makes the position defensible.
Implications
What this means for specific decisions. An architect reviewing a proposed IT Design reads the Implications and determines immediately whether the Design complies or deviates. That traceability connects strategic intent to delivery decisions.
Business Visions: directional plans
The Business Capability Model is the foundation — a structured map of what an organisation can do, not how it does it, not who does it, not what systems support it. Capabilities are stable: “claims processing”, “customer onboarding”, “product pricing” persist through organisational restructuring and system replacements. That stability makes them a reliable planning reference.
The Roadmap translates capability priorities into an IT investment sequence. A Roadmap entry is not a project plan — it is a direction commitment. “We will invest in improving our claims processing capability over the next 18 months” shapes the portfolio without constraining delivery.
The mechanism that matters: When a new initiative proposal arrives at the Investment Forum, the first question should be: where does it appear in the Roadmap, and which Business Capability does it strengthen? If it doesn’t appear in the Roadmap and doesn’t clearly strengthen a priority capability, it needs an explicit justification for why it should displace something that does. Business Factors and Business Visions are what make that question answerable.