Agile Infrastructure Transformation and Technology Business Management (TBM)

Agile Infrastructure Transformation and Technology Business Management (TBM)

Agile Infrastructure Transformation and TBM
via LeadingAgile by David Levine

When I first thought of writing this article, I struggled with how best to talk to these perceived different approaches. Questions of how does Agile apply to infrastructure and what does TBM has to do with Agile were in my mind. A simple google search reveals just a slim number of articles and these are mainly based on the theory of how these concepts come together vs. real-life learnings.

Let’s start with some basics. What is TBM?  I have had exposure to TBM in a past organization and the driver and my perception were that it was about IT Towers to assess costs and consumption related to infrastructure spend so that the organization could leverage benchmarks and “defend” our costs. My experience is that in a TBM implementation that is driven by a CTO or even a CIO in a defense mode (“Why are your costs so high?”) is a more than common approach, but falls short of the value and intent of TBM.

TBM is a model and taxonomy that at its most basic level does understand and map costs and consumption. But the intent is to elevate the discussion with the business related to value and trade-offs as you understand what is driving costs. So instead of having a defensive conversation with a CFO on why something costs so much, we are having a discussion related to what is needed and then can understand the costs related to supporting those business needs. TBM also seeks to link the long-term support costs beyond a project since once a project is done there are ongoing run costs that are part of the TCO of a product.

The TBM Taxonomy

One example I experienced around the value of Total Cost of Ownership. A prior CTO gave an excellent explanation of what it looks like to truly understand TCO. At the time, I was leading a group that was responsible for Application Portfolio Management and assessing risk, value, and cost for all of our applications in the company. The CTO told me he wouldn’t be surprised if we found applications with low value and high costs that we needed to retire or replace. He related an extreme example where a company had an application that had been in place for several years and was put in place for parking lot reserved space management for the company. Over time it became used for only the executives in the company. After a detailed TCO analysis they found that they were spending over $1M per year on this application in TCO (costs to manage, support, and run the application). Having this information enabled a conversation on options – one of which was to hire a person to manually run the function. See where this is going? A shift to a product focus.

Continue Reading