The architecture tax is the cost of building program architecture during execution instead of during planning. It is always more expensive than building it beforehand, because execution-stage architecture must be built under time pressure, with active work in flight, and with teams already operating on assumptions that the architecture may need to override. These three cases illustrate different manifestations of the architecture tax. Each program had competent teams, reasonable plans, and executive support. Each entered execution without an Architecture Blueprint. Each paid for that decision in time, cost, and organizational credibility.
Case 1: The Decision Stall Cascade
A financial services company launched a technology modernization program spanning four business units and a central IT function. Each business unit had a workstream with an assigned lead. Central IT had a platform workstream. The program had a RACI matrix, weekly status meetings, and a steering committee that met monthly. The architecture gap: no decision routing. The RACI specified who was accountable for each deliverable but did not specify how decisions got made when deliverables crossed workstream boundaries. A Governance Model with explicit decision routing would have given cross-functional decisions a legitimate forum. The steering committee was the only cross-functional decision forum, and it met monthly. During execution, the platform workstream needed decisions from business unit workstreams about data migration sequencing. Each business unit had preferences that conflicted with the others. The platform lead could not make the decision unilaterally because it affected all four business units. The business unit leads could not make it collectively because there was no forum for cross-workstream decisions between steering committee meetings. The decision waited three weeks for the next steering committee meeting. The steering committee asked for additional analysis. The analysis took two weeks. The revised recommendation went to the following month’s steering committee. Total elapsed time for one decision: seven weeks. This pattern repeated across multiple decisions. By month four, the program had accumulated fourteen weeks of decision-related delays across its critical path. The program was restructured at month six, adding a weekly cross-workstream decision forum that should have existed from the start. The governance problem nobody talks about describes the decision stall pattern and why monthly steering committees are insufficient governance for programs that generate weekly cross-functional decisions.
Case 2: The Integration Collision
A healthcare organization launched a clinical workflow transformation involving Nursing, Pharmacy, and IT. Each function designed its workstream independently. Nursing redesigned clinical workflows. Pharmacy redesigned medication management processes. IT built the technology platform to support both. The architecture gap: no Handoff Contracts. Each workstream defined its deliverables but did not define how those deliverables would be received by other workstreams. Nursing designed workflows assuming the technology platform would support certain functionality. IT built the platform based on its own interpretation of the requirements. Pharmacy designed processes that assumed both the nursing workflows and the technology platform would accommodate medication management needs. The collision occurred during integration testing. Nursing’s workflows required real-time medication alerts that IT’s platform did not support because the requirement had never been formally specified. Pharmacy’s processes assumed a workflow sequencing that nursing’s redesign had changed. IT’s platform supported the original workflow design, not the redesigned version, because nobody had communicated the redesign to the platform team. The integration rework required eight weeks. Three workstreams had to revisit deliverables they considered complete. The total cost of rework exceeded the cost of the original build for two of the three workstreams. Programs that failed with good plans documents similar integration collisions across multiple industries. The pattern is consistent: workstreams execute successfully within their boundaries and collide at the handoff points between them.
Case 3: The Ownership Vacuum
A consumer products company launched a supply chain optimization program touching Procurement, Manufacturing, Logistics, and Commercial Planning. The program had strong workstream leads in each function. It had an experienced program manager. It had executive sponsorship from the COO. The architecture gap: no ownership for the integration between workstreams. Each workstream lead owned their function’s deliverables. Nobody owned the connections between functions. Specifically, three integration tasks had no assigned owner:
- Aligning procurement lead times with manufacturing scheduling changes
- Coordinating logistics capacity adjustments with commercial demand forecasts
- Synchronizing master data changes across all four systems
Each integration task sat in the space between two workstreams. Each workstream lead assumed the other would handle it, or that the program manager would coordinate it. The program manager assumed the workstream leads had worked it out between themselves. The first visible failure: manufacturing changed its scheduling approach based on the new procurement lead times, but logistics was not informed. Logistics continued to plan capacity based on the old schedule. The mismatch surfaced when orders began arriving at warehouses outside the planned receiving windows. The second visible failure: master data changes made by procurement were not synchronized to the commercial planning system. Demand forecasts were being generated using outdated cost assumptions, producing margin projections that did not reflect the new procurement agreements. Both failures were traced to the same root cause: nobody owned the integration. The program added three integration leads after the failures, each responsible for one of the three cross-functional connection points. The integration leads did the work that an Architecture Blueprint would have specified during planning. The architecture nobody builds explains why integration ownership is the most commonly omitted element of program governance, and why programs consistently underestimate the coordination cost at functional boundaries.
The Pattern Across All Three Cases
The three cases share a structure. Each program had functional workstreams that executed competently. Each program failed at the boundaries between workstreams. Each program eventually built the architecture it needed, but built it under execution pressure rather than during planning. The architecture tax in each case included: the direct cost of rework and delays; the indirect cost of organizational credibility damage (teams losing confidence in the program’s governance); and the opportunity cost of weeks spent fixing structural problems instead of advancing the initiative. The Architecture Blueprint exists to move these costs from execution to planning, where they are smaller, less disruptive, and less visible to the organization. Building architecture during planning costs days. Building it during execution costs weeks to months and carries organizational consequences that planning-stage architecture avoids entirely. Fourteen stakeholders and zero visibility connects to a related pattern. The question is whether your next initiative will invest days in architecture during planning: or whether your team will spend weeks rebuilding it during execution, after the tax has already come due.
Keep Reading
Ready to close specific gaps in your Architecture Blueprint? These articles show you how: