Build It and They May Not Pay For It

Some of the biggest complaints I've heard (mostly from the SMB crowd) around the idea of the "build it and they will come" methodology of planning for cloud infrastructures, is that no matter how great the actual business value might be:

A) It is simply too expensive upfront (i.e. the capital expense or CAPEX required).

B) They are mistrustful about being able to recoup their CAPEX costs by charging for utilization.

C) With no clear asset owner (more on this later), they doubt their ability to fund the continuous CAPEX requirements for an ever expanding infrastructure.

These are all valid concerns and not just for the SMB market but for anyone who is thinking about transitioning to a cloud infrastructure. More important though, is that it is not typically the technology differences that are the sticking point, but the funding requirements (CAPEX and OPEX) and operational changes required that slow or stop the transition.

In this blog post, I will discuss the CAPEX and OPEX funding issues that are causing the biggest headaches in the industry. But first, (and I won't go into any technical details here) a major differentiator between a traditionally managed infrastructure and a cloud infrastructure is that a cloud infrastructure is proactive while a traditional infrastructure is reactive. 

Reactive means (and everyone is quite aware of this process) that as individual requirements are identified (i.e. the need for purpose built applications) only those assets relative to those requirements are added to the infrastructure. There are very clear and traditional process chains for how those assets are identified, specified and acquired with very clear supporting processes for how they are then tracked, handled and depreciated within the financial systems as they age and are eventually decommissioned.

Proactive, on the other hand, means that there is an infrastructure-spanning, generic set of capabilities (i.e. processing, performance, availability, security, capacity, etc.) that are defined (to be delivered via a service delivery framework). Then the infrastructure is built to deliver those capabilities, regardless of the underlying business requirements or any specific need. Another way of saying this is that the infrastructure is built in the same way that a power generation plant is built in that what is most relevant is what is known of future gross power requirements (or in our case, capabilities) and what is least relevant is what those power requirements (capabilities) would be used for.

So, as you can see, the proactive, or cloud, infrastructure is built first (CAPEX) and then the delivery of the services are then cost-defined (OPEX). The business users pay for the system as it is utilized (via a charge-back mechanism) by an aggregation of fractional asset costs for network, storage and processing capacity usage as well as administrative overhead. The major problem with this from the SMB perspective is that their entire budget processes are built on the idea that the infrastructure is grown organically based on specific business requirements related to purpose built applications (and associated assets).

For buying the assets they need for meeting the application's performance and capacity requirements, they follow the traditional process flow of: 

1. Business need
2. Business requirement
3. Technical requirement
4. Equipment specification
5. Project ID
6. Procurement

They simply have no way of building the infrastructure—or even portions of it—proactively because their internal processes (business, financial, etc.) are not aligned to such an upfront investment that spans multiple business initiatives or applications.  In their operational and business process systems, there is no way to differentiate who pays for what on the front end… and divvying up those costs on the back-end is equally as murky.

Now that you're completely disheartened about creating a cloud infrastructure in your company, let me say that there are indeed many SMB organizations that are moving ahead with their transition plans toward a cloud infrastructure, but are finding that, to be successful, they absolutely have to address their financial and operational (business process) systems with designing the actual technological infrastructure.  

Not one before the other (in a serial fashion) but at the same time.  

The chicken and egg analogy is as good as any here because the operational and financial processes (the chicken) will by necessity mirror the capabilities designed into the cloud infrastructure (the egg), but the cloud infrastructure cannot be designed without defining the necessary operational and business processes.  

I wish I could just write down all the process steps (how to effectively marry the operational/business process with the technology infrastructure design) that we've found to be successful at WWT but they are different, sometimes vastly different, for each business.