Micro-Optimization: Activity-Based Costing for Digital Services?

As I have argued in my other posts, the digital world is bringing a radical change in the role of the CFO. For one thing, the cloud and DevOps are turning fixed costs into variable costs. For another, rapid iteration and delivery make it possible—and essential—for us to make financial decisions based on marginal costs and marginal returns rather than on total or average costs.

Now, a final piece to the puzzle: with the cloud, we can break down even a single digital transaction into its component costs and then work to both optimize those costs and gain insight into our unit economics—not just on a customer-by-customer or transaction-by-transaction basis, but on a digital operation-by-digital operation basis within a transaction. The implications, as I will show, are substantial for finance and IT management.

The first clue I got to this new possibility was in conversation with two of AWS’s serverless heroes: Aleksandar Simovic and Slobodan Stojanovic. We were talking about the implications of serverless computing, which we agreed went deeper than most people realize. If you are not familiar with serverless, a brief explanation is in order here. Traditionally, computing infrastructure consisted of physical server computers in a datacenter. These were fixed costs—step costs, really—where each server could handle a certain amount of transaction volume, and then had to be replaced or upgraded when the volume of the company’s transactions grew beyond its capabilities. With the cloud, a company can pay for “virtual” servers managed by AWS, with a tremendous increase in flexibility—they can add or subtract servers instantly, or change the server’s processing power as needed for their ever-changing business.

But with serverless computing through AWS Lambda, the company gains an order of magnitude more flexibility. There is no longer a need for the company to provision virtual servers. Instead, it simply designates what code should be executed and under what conditions, and AWS deals with everything else behind the scenes. The company pays only for the execution of the code. “Compute” is essentially a utility, like electricity—flip a switch and it is on; flip a switch and it is off. You only pay for the electricity when you turn it on—let’s say to generate light so that you can read our blog posts.

Now think about how this changes the economic picture. The code executes only when a transaction is being processed, and the cost depends only on the execution of the code. In other words, cost is truly variable—by transaction.

Next, consider that each customer transaction is typically handled by multiple pieces of code, called microservices. For example, when you buy something online, your transaction is probably delegated to a microservice that looks up your customer information, another that checks inventory, another that processes your credit card payment, and another that tells the warehouse to pick and package the item. Some of these microservices might have been created by your technologists in-house; some might be services provided by third parties. Each of these microservices uses serverless compute—and you can find out the cost of executing that microservice.

Putting all these pieces together you can say that a digital transaction requires a number of activities, and you can break the cost of a transaction into the cost of its component activities. You can do activity-based costing, that is, even for things that are internal to a computing infrastructure!

Why would you want to? Well, first, you can get a very detailed sense of your unit economics and then you can make decisions that will improve what is probably a growing cost area of your business. Not only can you look at customer profitability, but you can look at transaction profitability and even profitability of the features within a transaction. You can use this information to set pricing, make decisions about what features to offer in a product, and determine what features to promote.

You can also consider alternative ways of structuring the digital services that make up your transaction. Will it be less expensive to stop using a third-party microservice component and instead develop an equivalent in-house? Before, you could only make this decision by comparing the fixed cost of developing it against your licensing fees. But that missed an increasingly important cost element: the cost of infrastructure or computing power. You can now bring that cost into your build versus buy decision.

Your technologists can also use the information to choose between different services that you can buy, or to make choices between different technical designs they can use as they are architecting the system. You can make granular decisions that—when you are operating at high volume—might make all the difference in cost and profitability.

Perhaps most importantly, you can better delegate responsibility for cost and profitability to the teams that are developing and managing the digital service. They can be responsible not just for the cost of developing the service—which made more sense when we thought of the service as just a simple capital asset that never thereafter changed—but for the costs of operating the service as well. I talk further about this economic accountability in another post on FinOps. The importance of making decisions at the margins—that is, in terms of marginal costs and marginal revenues—in my post on Marginal Decisions.

The idea of accounting for and making decisions based upon these micro-costs at high volume is real. Aleksandar Simovic has developed an elegant  software tool called CapitalFlow that report on this micro-cost information in a way that enterprises can use. You can take a look at it here: https://capitalflow.ai.

–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!)