There is a conversation that happens in architecture practices all over the world, and it goes something like this. A business unit puts forward a set of initiatives. Someone asks which ones to fund. The architects are not in the room. Someone opens a slide deck. The meeting devolves into opinion, politics, and whoever has the loudest voice and the biggest budget wins.
That conversation does not have to go that way. An architecture practice that does its job makes business case evaluation much easier.
The BTABoK gives architects two canvases that, when used together as a practitioner group, produce something genuinely useful: a structured, defensible picture of demand.
The Strategic (Architects) Roadmap Canvas
and the Business Case Canvas (NABC format)
are not management tools. They are working surfaces for architects (that is why we make them ugly :-)) . The purpose is not to produce documents for a steering committee. The purpose is for the architects in the room to build shared understanding of what is being asked for, what it will cost, what it is worth, and whether the portfolio of initiatives actually hangs together. It also forms the basis of WHAT THEY CAN DO WELL. Yes I mean a group of architects cannot be proactive at everything. This technique allows the architects to be realistic about where they can be proactive (innovation), and where they would just be checking other peoples homework (governance). These are extremely important outcomes of a relatively straightforward technique.
This is a group technique. It requires business architects, solution architects, and specialist technical architects in the same room working the same canvases at the same time.
I want to be very clear, if this is an EA activity or a management activity, it will not work well. The architecture practice needs visibility across value of initiatives and to be of one voice about what its priorities are. This is an excercise for the team not for management.
Start With the Business Case(s), Not the Roadmap
Most teams do this backwards. They build a roadmap first, a list of initiatives in time buckets, and then try to justify it after the fact. The business case becomes a retrospective exercise designed to get approval rather than to inform a decision.
The NABC Business Case Canvas forces a different discipline. Before any initiative touches the roadmap, it has to survive four questions.
Need. What is the actual driver? Not the technology problem, not the architecture debt, not the platform limitation. The need must trace to a business condition: a customer experience failing, a market opportunity being missed, a regulatory obligation approaching, a cost that is compressing margins. The need section of the canvas is where architects connect to OKRs. If the need cannot be articulated in terms of a business outcome, the initiative is not ready for the roadmap.
Approach. What is being proposed? The approach section describes the solution at sufficient resolution to evaluate it. This is where the solution architect’s contribution lives. What is the structural pattern? What changes, what does not change, what is the migration path? The approach must be specific enough that the next two sections can be calculated, not estimated by vibes.
Benefits and Value. What is the measured or expected outcome if the approach works? Benefits must be stated in two forms. Qualitative benefits name what changes: faster onboarding, reduced manual reconciliation, improved supply chain visibility. Quantitative benefits attach numbers: how many hours per week, at what fully loaded cost, over what period. The canvas has specific fields for both. The quantitative row feeds the ROI calculation directly. Architects who skip the quantitative work are not doing business cases, they are writing wish lists.
Costs. Total investment, broken down by type. The canvas distinguishes capital expenditure, operational expenditure, programme costs, and risk contingency. It also captures annual steady state cost, which is the number most business cases omit and most sponsors regret missing. The ROI section then does the arithmetic: gross benefit minus total cost over the payback horizon, net ROI, and sensitivity notes for the assumptions that matter most.
Considerations. Alternatives considered and rejected, with the rejection rationale. Risks with mitigation approaches. Links to Architecture Decision Records. This section is where intellectual honesty lives. An architect who fills out the Considerations zone seriously is an architect a sponsor can trust.
One business case per initiative, before that initiative moves onto the roadmap.
If your business architects are not a part of this, and I mean in the room fighting for value, then the practice is broken.
Then the Roadmap Does the Hard Work
The Strategic (Architects) Roadmap Canvas is a comparison instrument.
The canvas carries five evaluation dimensions for each initiative: Value, Complexity, Compliance and Governance, Principle Alignment, and Status. These are the columns that sit alongside each initiative row. This is where the group process matters most, because these are scores, not facts, and scores require calibration across different architectural perspectives.
Value is the aggregate benefit signal from the business cases. A high-value initiative is one where the quantitative benefits from the NABC are material, the qualitative benefits are visible to stakeholders who matter, and the need traces cleanly to a strategic objective. Business architects carry the primary voice here because they hold the capability and outcome context.
Complexity is determined by architecturally significant requirements, not by gut feel or project management estimation. An initiative is complex when it touches multiple bounded contexts, when it introduces new platform dependencies, when it requires data migration at scale, when the integration surface is wide, or when the delivery requires coordination across teams that have not worked together. Technical architects carry a huge voice here. The complexity score from the roadmap canvas should reflect the structural and domain challenge, not just the delivery effort.
Compliance and Governance is the regulatory and policy surface. What obligations attach to this initiative? What governance gates must it pass? What approval authority is required before the first line of code runs? Solution architects working in regulated industries carry specific responsibility for this column because they are the ones who will be accountable if a deployment triggers an audit finding.
Principle Alignment is about whether the initiative moves toward or away from the architecture direction the practice has committed to. This is the architects’ shared constraint. An initiative that delivers high value but violates a foundational principle creates debt that will be paid, with interest, by the team that inherits it. The roadmap canvas makes principle alignment visible at the portfolio level rather than discovering violations initiative by initiative during delivery.
The Scoring Protocol Is the Group Process
The BTABoK roadmap canvas specifies a scoring approach that many teams skip and then wonder why their roadmap meetings do not produce alignment.
Each participant scores independently, on a consistent scale, before anyone speaks. Then scores are revealed simultaneously. Then differences are discussed.
This is the mechanism that surfaces disagreement early, when it is cheap to resolve. A business architect scores an initiative at 8 for value because she can see the customer outcome clearly. A technical architect scores the same initiative at 3 for value because she can also see that the approach in the business case does not actually deliver the claimed benefit. That gap is information. The discussion that follows is architecture work.
Without the simultaneous reveal, the first person to speak anchors the group. The most senior person in the room anchors the group. The person with the loudest conviction anchors the group. The scoring protocol prevents anchoring and forces genuine calibration.
The output of scoring is not a ranked list to hand to management. It is a shared understanding of the portfolio: which initiatives are high value and low complexity and should move immediately, which are high value and high complexity and need further decomposition, which are low value and high complexity and should be dropped, and which have compliance or principle conflicts that need to be resolved before they can be sequenced.
Dependency Sequencing Is Where Technical Architects Earn Their Seat at the Table
Once the scoring is done, the roadmap canvas has a Key Dependencies section that most teams fill in lazily. It should not be lazy.
Architects know which initiatives are prerequisite to which others, not because of project scheduling logic but because of architecture logic. A data mesh initiative cannot deliver value until a master data governance initiative has established canonical entity ownership. A customer self-service portal cannot be built on top of a monolith that has not yet been decomposed at its integration layer. An AI-assisted workflow tool cannot function without the event streaming infrastructure that the previous quarter’s initiative was supposed to deliver.
These are hard architectural dependencies. They are not negotiable by adjusting milestones. The Key Dependencies section forces them onto the roadmap surface where they can be seen, rather than allowing them to be discovered during delivery when they become project risks.
The dependency map that comes out of this process is also the answer to the question every sponsor eventually asks: why can’t we just do Initiative X now without doing Initiative Y first? The answer should be architectural, not political, and the roadmap canvas is the place to make that case.
The Two Canvases Together Build a Picture of Demand
The point of running these two tools as a connected group process is not to produce paperwork. It is to build, as a practice, a coherent picture of what the technology portfolio is being asked to deliver, what it will actually cost, what it is genuinely worth, and in what order it can be done without creating structural damage.
That picture, built by architects who have done the work, is the foundation for a genuine conversation with the business about investment. Not a sales conversation. Not a justification exercise. A professional conversation between people who understand the technology and people who own the outcomes.
That is what the canvases are designed to enable.
The architects who use them as working instruments, not as documentation templates, are the ones who get to have that conversation.