Tune into: Direct Container Costing
It is the day that you knew was coming, namely the day IT costs finally transitions from indirect overhead cost to direct attributable costs. This of course was to be expected with digital business becoming the norm(al). But the actual transition may still take a little longer than we might expect. The final transition needs what many would call a perfect storm, with all the ingredients lining up at the right time. A number of these ingredients is already present:
For one, we have seen – especially when the sold products themselves and the distribution thereof are becoming more digital – the share of IT cost in the total product cost increase, resulting in a greater need to account for these cost directly in the cost of each product. As a logical result of this we see the responsibility for these costs moving into the line of business departments. In addition we see the costs of the Internet of Things and smart machines shift to the line organization while we signaled years ago that in many industries the chief marketing officer may well have more to spend on IT than the CIO.
On a technical level we can – largely thanks to the introduction of containers – identify individual micro services costs and attribute them to the individual products or services that directly benefit from using these. Very much like we allocate the cost of wheels, saddles and gears in a bicycle factory to each produced cycle and not as a kind of convoluted overhead tax on the cost of the frames. What helps here is that we can start software containers per use and stop again. And that’s just the key difference between direct costs (such as mounting a wheel) and indirect costs (such as lighting or heating the factory).
This also opens the opportunity to move away from budget driven IT management. For digital business a budget driven approach is as inefficient as the budget-driven factories of the former Soviet Union. Where often already in August production had to be shut down for the rest of the year because the budget for saddles, tires or even bicycle bells was exhausted.
The scheduling of all those containers is by the way a challenge that is quit comparable to the challenges of planning production in a modern bicycle factory: pretty complex. Especially if we want to do a certain amount of long-term planning and set ambitious but achievable cost targets. Calculating how much it cost to produce an individual product after the fact is relatively simple, namely simply summing the individual cost of all the resources. But to set an upfront target cost (what should this product or service cost), we get stuck without a model that can be used to describe the service. In production we have known such models for years under the name of bill of material or formulation. In the cloud we often hear the term “services blueprint”, but in terms of maturity and acceptance of this, we are still some time away from beauty parades and model of the year elections.
For a sensible move to using direct costs, it is also necessary that we can pay our cloud providers based on the individual containers services used. With function platforms (fPaaS) such as Amazon’s Lambda we have seen this indeed become possible. Here we on pay per function called (in millionths of cents) and for the actual memory used (in tenths of seconds). But for many of the more generic container services payment is still a kind of flat fee calculated based on the cost of the underlying VMs, regardless of how many or what type of containers are actually running. That’s a bit like a bicycle factory which pays its supplier by the cost of the machine that produces wheels, instead of by the actual number of wheels consumed,.
The song “Das Model” from 1978 of the German band Kraftwerk is about a catwalk beauty parade. In the UK it originally came out as secondary B-side of as song called ‘Computer Love’, but the market was quick in deeming it the primary A-side, elevating it to the number 1 position in the UK top 75 singles.