For years, I struggled to explain technology costs in a way that made sense to both Finance and Business teams. Finance wanted numbers; Opex, Capex, variance reports.
The Business wanted outcomes; faster releases, more digital capability, improved margins. And IT? were somewhere in between, trying to translate architecture, systems, and services into something that sounded remotely like value. Every cost discussion felt like a tug-of-war. That was until I discovered Technology Business Management (TBM), and realised it was the missing layer that sat right alongside enterprise architecture frameworks like TOGAF.
TOGAF gives you structure. It helps you define how business, data, applications, and technology fit together. It tells you what exists; the architecture building blocks that support the enterprise. But what TOGAF doesn’t tell you is what it costs. That’s where TBM comes in.
TBM complements TOGAF by adding the economic dimension, mapping costs to the same architecture layers TOGAF defines.
It answers questions like:
- What’s the total cost of supporting a given business capability?
- Which applications consume the most infrastructure spend?
- How much does it cost to deliver a service end-to-end?
TOGAF describes the architecture. TBM quantifies it. Together, they create a full picture: structure + value.
What TBM does brilliantly is give technology costs a language that aligns with architectural intent. It takes raw financial data : cost centres, invoices, licenses etc. and connects it to the capability and service layers defined in frameworks like TOGAF.
- At the Infrastructure layer, TBM organises costs into pools like compute, storage, and network.
- At the Application layer, it attributes those costs to the applications consuming them.
- At the Business Service and Capability layers, it rolls them up to show what parts of the business they enable.
In essence, TBM operationalises TOGAF’s structure in financial terms. It makes the architecture economically visible.
When you see costs through this structured lens, everything changes. Finance no longer looks at IT as a black box. IT stops defending its budget in isolation. And business leaders can finally see technology spend as investment, not overhead. The conversation moves from “Why does this cost so much?” to “What value does this enable?” It also exposes inefficiencies hidden within the architecture; redundant systems supporting similar capabilities, underused platforms, and shadow IT that bypasses governance. With TBM layered on top of TOGAF, you get the visibility to not just rationalise, but to re-align spend to value.
Adopting TBM isn’t just about deploying a new tool. It’s about data discipline and architectural consistency. Just like TOGAF demands traceability between business goals and technology implementation, TBM demands traceability between cost and consumption. That discipline builds credibility. It turns architecture from documentation into decision support. And once you have both, a structured architecture from TOGAF and cost visibility from TBM, your technology strategy becomes financially grounded and operationally defensible.
I’ve seen this integration come alive in organisations that mature beyond IT accounting. Architects start using cost insights to shape roadmaps. Finance partners begin validating technology investments through value chains, not cost centres. And CIOs finally have the vocabulary to explain why their architecture matters, in business terms. That’s when the dots connect: TBM brings the “how much,” TOGAF brings the “how it fits,” and together they answer the ultimate question, “Is this creating value?”
TOGAF gives you the map. TBM shows you what that map costs to maintain and where it truly delivers value. When the two come together, architecture stops being theoretical, and finance stops being reactive. You get alignment, clarity, and a shared understanding of technology’s role; not just as an enabler, but as an accountable, measurable driver of business growth.
Cirvesh
Comments
Post a Comment