SA-301h · Module 3

Architecture as Business Case

4 min read

The architecture that is technically superior but cannot be justified in business terms does not get built. The architecture that is technically adequate and clearly tied to business value does. This is not a complaint about organizational priorities — it is a design constraint. The business case is as much a part of the architecture deliverable as the component diagram. The architect who treats the business case as someone else's job is the architect whose designs are perpetually "planned but not funded."

Do This

  • Quantify the business value of the architecture — revenue enabled, cost reduced, risk mitigated, time saved
  • Compare the cost of building against the cost of not building — the status quo has a cost, make it visible
  • Include the time-to-value — when the investment starts returning value, not just when the project finishes

Avoid This

  • Present the architecture as self-evidently valuable — technical elegance is not a business justification
  • Omit the status quo cost — if the current system costs $X in workarounds, manual processes, and missed opportunities, that number belongs in the business case
  • Promise ROI without evidence — an estimated ROI with stated assumptions is credible, a guaranteed ROI without evidence is not