How TBM underpins agile at Mastercard and turns IT into an asset
- Summary:
- At Mastercard, IT is an asset not a cost - as technology business management (TBM) sets resources and goals for agile development and continuous delivery
The occasion was the annual European meeting of the TBM Council, an independent user organization which grew out of the CIO user community of TBM systems vendor Apptio. At its most basic, TBM gives business decision-makers better insight into their IT costs — earlier this year we wrote about MetLife's use of TBM to take control of its cloud spend.
At Mastercard, TBM goes much further. It provides the financial and budgetary framework for delivering the organization's digital transformation strategy, and helps define goals for its agile IT teams. As McLaughlin states:
We've used TBM principles to really guide and fund and change that transformation. So if there's one thing I want to keep coming back to, this is not about financial management. It's about how you think about your organization. How you organize is how you architect, it's how you operate — and that is what allows you to innovate.
Changing the mindset from projects to programs
The change in the financial framework mirrors the change in the development mindset from one-off projects to continuous delivery. As McLaughlin puts it:
Five years Soviet-style planning models just will not survive the environment we're in. Agility, innovation — life — is continuous. We have to move from project-based thinking to continuous thinking against progress, and that's a huge challenge.
In financial terms, that meant moving away from the old paradigm in which product teams would bid for a share of the budget to fund new IT projects, but then hand over responsibility for running the installed asset to IT. The old structure meant that goals were not aligned — product teams were focused on winning the battle to get their project approved by the CFO, IT was incentivized to hit SLAs while reducing costs, and there was no direct link to the revenue goals of sales teams and regional managers.
TBM turns that around and instead of spend on IT being seen as a cost, IT is treated as an asset that produces a measurable yield. McLaughlin explains:
I believe information technology operations is the primary hard asset of every organization. It doesn't necessarily mean you spend more, but you think about assets profoundly differently from cost centers ...
We were using TBM as a way of creating that center of gravity... for all of those desires, the key is, what is the yield? To know that, you truly have to understand the asset you're applying against it and what you're getting out of doing it.
TBM as a framework for agile development
This is inherently tied to agile development and continuous delivery because it provides a framework for prioritizing work and measuring success, he adds:
The biggest challenge that I've seen is people making the mind shift from project to continuous. There is no finish line, there is no end. It's an ongoing feedback loop. Unless you say, 'This is what's most important,' unless you meter against it, agility will kill you because people will just be going guardrail to guardrail, to the next feature they think's important, not using it as a discipline to manage a continuous program ...
In order to be truly effective in agility, in micro-services architectures, in continuous delivery, the key is aligning the managerial model, the organizational model, the architectural models, and then, and only then, the development methodologies around it.
TBM also provides the crucial framework for delegating the necessary decision-making on resource allocation to the program teams, he adds:
To be agile, it means the teams need to make decisions every day, which means they have to know the resources available to them, they have to be able to direct those resources — and you really do have to push that authority out. It's incredibly powerful.
But you can't go halfway on it. You can't try to say, I want a command-and-control structure. I want an old-school financial modeling. I want a project planning process, and oh, by the way, be agile. You're just going to end up frustrating people faster.
Setting guidelines for self-managed programs
McLaughlin described the TBM model Mastercard developed to make this delegation of powers work. A crucial element in reorganizing around program objectives was the appointment of a budgetary responsible person — shortened to BRP, or 'berp' — for each program. There's an overall framework of demand management that sets company-wide priorities for outcomes. Then the individual programs themselves bring together products, technology assets and market objectives in a flatter, cross-functional organizational structure made up of smaller, more atomic, agile teams. McLaughlin says this works equally well for both front-office and back-office initiatives:
It's the only way you can give a brave and dedicated group of individuals the freedom to obsess on what's most important specifically for their programs. When we do it this way, it then means the programs can either be market-facing or your internal assets.
The model for establishing each program is called COSI, an acronym for four principal ingredients — engineering Capacity, Onboarding and servicing, access to Shared components, and Infrastructure consumption. The most important of these is the first, which consists of the people and skill sets assigned for the lifetime of the program. It's up to each program manager to decide how to use that capacity through the life of the program in order to best meet their goals. Those goals have four dimensions — new features, health, required operations and sales support. When it's very early stage, most of the resource will probably go into new features. A program nearing end-of-life will focus resources on system health and required operations.
Incentives for infrastructure investment
Defining teams in this way avoids the tendency under the old model to under-invest in infrastructure, as McLaughlin explains:
We had in the prior accounting laws, prior to TBM, a bit of a moral hazard. If someone did something great to dramatically reduce the cost of what they were delivering, that money was just pulled back into the organization to be allocated again, to whoever told the best story for incremental funding. It really reduces your desire to dramatically reduce those costs, for it to go away to somebody else.
Under the COSI model, the underlying infrastructure is considered part of the program, and any savings made at that layer is reinvested back in the programs that use it. He cites the example of an infrastructure team that generated a savings of $12 million by moving to virtualization:
Rather than $12 million going away from some internal allocation, if I have a dozen programs that have a million dollars more to spend on value creation because it's something clever we did at the infrastructure layer, how amenable are you going to be for the next time we want to say, let's make an investment to run more efficiently? So again, within the program, retain the savings from the investments you made.
Business drives digital transformation
Applying this model has enabled Mastercard to adapt to the new delivery channels of device-based commerce, creating a digital token architecture in place of the traditional payment card, says McLaughlin:
Using TBM to organize around an initiative like that, allowing that team to make those decisions and be agile everyday and get this rapidly to market has been a foundation of the transformation for our business to go after those objectives.
Fundamental to this has been an appreciation that it's not just a technology transformation — the entire business must be involved. McLaughlin concludes:
Agile is not an objective. The cloud is not a destination. APIs are not the answer and AI is not a strategy. It's just stuff — incredibly compelling, mind-bending, world-changing stuff. But the only thing that matters with that stuff is how well we know who we are, what's most important, what we're trying to accomplish and how we use all of that stuff to create value ... For us, TBM is the framework we're using to do that.
Read more about those goals in my previous post, Mastercard going digital? Table stakes. Finding new markets? Priceless.
