A perspective on Cloud Financial Management

Voiced by Amazon Polly

One of the reasons Cloud Financial Management exists is to manage the changes to the process of procuring and consuming IT resources and the impact those changes have to accounting.  If you keep this perspective in mind, I think the job gets easier.

A metaphor – because who doesn’t like a good metaphor

There is no need to invent anything new to accomplish cost accounting in the cloud.  Think about the changes to the world of transportation when we transitioned from using horse drawn wagons on wooden wheels to internal combustion engines on vehicles equipped with rubber tires. (That’s tyres for some of you folks).  The velocity a vehicle could now achieve forced changes to the world around it.  We changed the way roads were constructed (infrastructure), we created a body of law to address the risks motor vehicles and their operators create along with standardized visual cues such as road stripes and signage (governance and guardrails), and we changed the fuel source from oats and water to hydrocarbon distillates (engineering for on-prem IT is not the same as engineering for the cloud).  The goal of the horse drawn wagon and the modern automobile is to convey people and things from point A to point B.  In that respect they do the same thing.  They differ pretty much in every other aspect…especially clean up.

From Cost Accounting to Cloud Financial Management

The concepts behind cloud cost accounting are nothing new.  In fact, they are old school and be traced back to J. Lee Nicholson who authored, “Nicholson on Factory Organization and Costs” in 1909.  I’m going to go out on a limb here and stir it up by saying: Cloud Financial Management (CFM) can be considered in part, the cloud incarnation of cost accounting.  At least I think it is.

When I was a developer, I spent most of my time implementing integrated accounting and manufacturing systems at mid-sized firms mostly located in the Midwest region of the United States.  When I was a financial controller, it was for companies that manufactured “made to order” engineered products.  So as you read this, it will give you some perspective as to my approach.

Now you’re asking, if CFM is a form of old school cost accounting that has been around over 110 years, why is it so darn hard to implement?  I believe the answer is centered around factories are fundamentally fixed costs which operate like step function that is predictable and periodically adjusted on a long timeline.  As assets depreciate, get retired, or get added to the books, there is a point-in-time near vertical adjustment to the cost curve.  What makes it easy is that these changes are relatively slow in nature and from a cost perspective they are linked to a point in time is almost always at the granularity of the fiscal month.  From an accounting perspective, traditional data centers operate the same way.  We purchase hardware and software, we add their costs to the books, we depreciate assets, and we deprecate hardware and software as they are taken out of service.   We make changes to our production hardware and software all the time.  It is important to note that these changes are typically performed at a velocity that is much slower than what cloud computing support.  Improved development and deployment velocities of software are a benefit of cloud use as they minimize the risk of experimentation and improve the ability to rapidly respond to the market.  It also creates complexity by creating a seriously large amount of data that is captured by these activities.

I tend to think of on-prem cost accounting as algebra and cloud cost accounting as integral calculus.  By definition, integral calculus is the mathematical study of continuous change or rates of change.  That resonates with me for some reason, but I didn’t want to use math analogies because for those of us who’ve taken calculus, we pretty much didn’t like it.  Since I am a manufacturing person at heart, I am switching back to that metaphor.

The cloud is your IT shop floor

Let’s employ the metaphor that our AWS estate is a data processing factory for this discussion.  In manufacturing the “shop floor” is the place where the work gets done.  In CFM, it is your AWS cloud implementation.

In the manufacturing world:

The shop floor is the place where people apply their skills to add value to inputs in order to produce an output that is sold to a customer in order to earn a profit.

In the cloud world:

The AWS cloud (shop floor) is the place where engineers (people) apply their intellectual capital (skills) to add value to data, software licenses, and AWS Services (inputs) in order to produce products and services (an output) that are sold to a customer in order to earn a profit.

That is how I see it.  We’re not solving a new problem here.  We need to cost our inputs and apply those costs correctly to our outputs so we can support the calculation of a gross profit margin for a product or service.

Cost Accounting when you have a fluid shop floor

So what’s changed?  My theory, unless you have a better one, is two-fold.   First, the time granularity of how our shop floor can be configured to support production has changed.  That is why I think of on-prem IT cost management as algebra and CFM as calculus.  It didn’t change by a little, it changed by orders of magnitude.  The change was so dramatic that it took us all, not just accounting and finance, by surprise.   The second change has to do with how we obtain and financially commit to using cloud based resources.  We collapsed the procurement cycle down to the time it takes to make an API call.  At the same time, we out flanked our colleagues in tech finance who oversee budgets and forecasts by putting the power to financially commit to cloud spend (provision and operate resources) in the hands of engineers.  Please note, this is not a bad thing…as noted earlier, that’s where the benefits of agility and minimizing the cost of failure come from.  However, it does require that we educate IT professionals who traditionally didn’t have to worry about the cost of operations about the cost levers of the AWS services they specify and use.

Let’s unpack that last paragraph a bit.  Traditional IT cost accounting operates at a very high level of granularity.  It often works in in monthly “time buckets” that coincide with the cycle of financial reporting.  Cloud cost accounting needs to operate at a granularity that is a function of the AWS Service being used and the duration or volume of that usage.  In the case of the serverless compute offering AWS Lambda, the billing granularity with respect to time is 1 millisecond.  Look at the traditional procurement-to-operation cycle for a server.  It’s not going to be measured in milliseconds, seconds, or even a few days.  It is typically measured in multiple months.  To play out an extreme case for AWS Lambda, there are 2,628,000,000 milliseconds in a standard AWS billing month of 730 hours.  In theory with AWS Lambda, there are 2.628 billion distinct time segments that must be evaluated and have their costs land in the right place.  I know it’s a contrived example, but its objective is to make a point.  Increased time granularity and the variable way in which we can use AWS Services across time create complexities that didn’t exist to this scale on-prem.  We need to address those new complexities just as we did when transportation transitioned from horse drawn wagons to automobiles.

Visiting our shop floor – one more time:

In the manufacturing world:

You have work orders (requests to produce something) that are built on top routers (the plan of how work flows through the shop floor from work center to work center) and bills of materials (purchased or manufactured components used to build the things we sell) that are instrumental in tracking our production costs.  These data are captured and used to develop an actual cost of production.  During the work order close process, the costs are charged to a cost of goods sold general ledger account for the product or line of business that owns the product.

In the cloud world:

You have products and services (work orders) that are built to form a work flow (on top of routers) and the detailed cloud cost and usage report (bills of materials) that are instrumental in tracking our operating (material) costs.  These data are captured and used to develop an actual cost of operations (production).  As you process detailed cost and usage data (during the work order close process), the costs are charged to a cost of goods sold general ledger account for the product or line of business that owns the product.

Is it making more sense why I am viewing CFM as the cloud incarnation of cost accounting?

In short, the cloud is a shop floor that can be reconfigured at a time granularity as small as 1 millisecond.  Resources can be procured and consumed in a manner that operates outside of the traditional path of review and approval used to govern spend.  The change from on-prem IT to cloud based IT in some ways is as radical as going from animal powered wagons to the gas-powered motor vehicle.  The velocity a motor vehicle can achieve and the sheer number of vehicles being produced caused changes to the world around them so their capabilities could be effectively used and their numbers effectively managed.  Thus, we need to adjust our IT cost accounting processes to support the changes in how resources are procured and consumed in addition to the increase in both volume and frequency of the cost data we must process.

Until something better comes along, that’s how I see it.