Introducing FinOps—Excuse Me, DevSecFinBizOps

Who is accountable for managing the costs of a digital service?

Enterprises are increasingly pushing accountability outward to cross-functional teams. There is an important reason for this: teams can make decisions and put them into action quickly, and speed is important. By putting a cross-functional group of people on the same team, the enterprise makes sure they have all of the skills and authorities they need to do their work—they become a single, self-contained unit, thereby avoiding time-consuming handoffs between different functional silos in the enterprise. Because the team is jointly accountable, it makes good decisions that don’t sacrifice one group’s needs for another’s.

In the IT world, today’s best practices revolve around DevOps. In the past, IT development and operations were two separate functional silos: IT development wrote new code, and IT operations managed that code when it was running in production. There was a handoff from development to operations when the code was ready, and the two groups worked to conflicting incentives: development wanted to deliver new functions as quickly as possible, and operations wanted stability. The DevOps solution was to make a single team responsible for both development and operations—thus the name. The slogan was: “You build it, you run it.” The team as a whole was incentivized to build quickly while at the same time ensuring stability.

It didn’t take long to realize that there was another functional silo with a somewhat different set of interests: security. Security, the IT profession realized, should be built into code as it is developed rather than added later on by a different team. Predictably, the idea became known as DevSecOps or some variation on that term.

In A Seat at the Table: IT Leadership in the Age of Agility, I introduced the idea of teams that brought together business folks and technologists with shared incentives. The goal was to avoid the handoff of requirements from business stakeholders to the IT team, and instead make everyone responsible for accomplishing a business objective. I didn’t use the term, but why don’t we just call it DevSecBizOps.

Well, today I’d like to introduce you to FinOps, the idea of combining financial accountability with autonomous team delivery. Delivery teams can be made responsible not just for delivering code, operating the code, securing the code, and making sure that the code accomplishes its objectives, but also for managing its costs, both fixed and variable.

Why does this make sense? Costs, like performance and other characteristics of the code, can be optimized by taking feedback from actual performance and using it to tweak the code. Just as the team might monitor the performance (speed, availability, etc.) of the code, they could just as well monitor the costs of their code, both in the infrastructure it consumes in the cloud, and in the licensing fees paid to third-parties whose products or services are used by the code.

They could then make good tradeoffs and optimization decisions that factor in costs. For example, if the code used an Oracle database, the delivery team would have an incentive to find a less expensive database that maintained the equivalent level of operational performance (or better or even somewhat worse, as appropriate). As I describe in a related post (Micro-Optimization) the team could look at the operational cost of each of the microservices it built or used off-the-shelf and find ways to reduce their cost, perhaps by rebuilding them or re-designing the system to avoid using them.

If the code was deployed using automated scripts into a particular instance type, the team could consider using a less powerful instance type or fewer replicated nodes. Really, there are a tremendous number of variables the team could work with in managing costs.

In other words, the team would be accountable for all aspects of its piece of code, including its cost—its cost to develop and deliver, its cost to secure, its cost to run, its cost to upgrade, and everything else. It would be the part of the enterprise best positioned to take on this responsibility, as it could make the best tradeoffs and would have access to the most detailed cost data.

To move toward this model, the first step for an enterprise would be to give the team transparency into the costs associated with its code. This is facilitated by the micro-optimization I described in the other post. The team would be able to track, at a detailed level, all of the aspects of cost for its service, and would be able to see how it changed over time.

The second step would be to get the right skills onto the team. DevOps usually favors T-shaped people for its teams—that is, people who have a broad set of skills but go deep in one area. So the financial skills might be secondary skills of someone already on the team (most likely of someone who has a background in IT infrastructure and operations).

The next step would be to change the team’s delivery process to include consideration of costs. A good model for this is the way we handled automated performance testing at USCIS. Every time new code was checked in, the entire system was rebuilt and re-tested. Among those tests was a test of the code’s performance (speed) when executing a certain set of transactions. The results were considered historically—if the code suddenly performed more slowly when someone’s new code was checked in, then the problem was flagged and the developer could investigate whether the slowness could be avoided. The same technique could be used for costs: every time new code is checked in, it could be tested against a cost baseline.

Finally, the enterprise would establish aggregate reporting of costs and set priorities and incentives for managing costs within the code.

That’s it—DevSecFinBizOps, for your enjoyment and implementation.

–Mark

@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age (now available for pre-order!)