Planning for Cloud Infrastructures: Build It and They Will…Not Pay For It?

Trevor Williamson

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 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 (as defined by NIST) 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 chargeback 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).

 

They follow the traditional process flow of business need>business requirement>technical requirement>equipment specification>project ID>procurement for buying the assets they need for meeting the application’s performance and capacity requirements.  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 backend are equally as murky.

 

So 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 in concert 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 but they are different, sometimes vastly different, to each business.

 

What we have found to be uniformly successful amongst all businesses is that, when those businesses understand that a cloud infrastructure is not a thing or place, they are able to more effectively address the many interrelated issues that prevent so many other businesses from moving forward.

For more information check out this  Preflight Checklist for Preparing for a Private Cloud Journey.

Contact Us

 

  • Pingback: Build it and they will … not pay for it? « EC Insight – CIO Blog

  • Pingback: How a Cloud Infrastructure Can Save or Make You Money | Rickscloud

  • Pingback: How a Cloud Infrastructure Can Save or Make You Money | CloudTweaks.com - Cloud Computing Community

  • Trevor Williamson

    Tim- Thanks for the comment.

    I agree that building a private cloud is very much like building a power plant (nuclear or otherwise) inasmuch that it is an upfront CAPEX investment and that the ROI doesn’t happen until it starts producing power (value) but I disagree that applications must be refactored in order to run effectively on that platform. One of the clear “value” parts of a private cloud is that the hardware is abstracted away from the application—meaning that you can forklift replace the underlying hardware at any time without touching code in the application.

    I also agree that most new “startups” these days defer a physical infrastructure but they tend to do so from a cost perspective, not particularly because it is a better choice (operationally or effectiveness). Once they reach critical mass where they start to need differentiation in their systems (better, faster, cheaper but more importantly, relevant) they start bring those resources internal because they have the direct access and control needed for that type of system and process optimization. Things you cannot do with a SaaS offering.

    As far as Carr’s predictions, when has sourcing the lowest cost resource inside an organization *not* been a strategic differentiator? If it was manufacturing steel widgets, would you call investing in a machine that manufactures them at 10x speed of your competitor not strategic? Of course there is CAPEX associated with that investment but as you ramp up production, the ROI results from bringing more supply online faster than your competitor—so isn’t speed to market a strategic differentiator?

    A private cloud allows organizations to reduce cost and speed to market by standardizing on commodity hardware (i.e. purchased in bulk in anticipation of need) without decreasing or even altering the complexity of their applications because the cloud itself abstracts the hardware…meaning you can slice and dice the delivery of specific hardware resources irrespective of the hardware itself. If an application calls for 32 cores and 256 GB RAM on top of a 10GigE network connected to 1 TB of RAID 10 storage then you would simply define that in a configuration file…not the hardware.

    And, by having that abstraction later, you also reap the benefit of being able to capture every single I/O transaction that occurs because you stand between the software and the hardware. Once you apply a value to those transactions it is easy to aggregate them into a coherent set of service definitions that can then be “priced” for application against CAPEX and ongoing OPEX.

  • Pingback: Planning for Cloud Infrastructures: Build It and They Will...Not Pay ... | Cloud Computing the future or Not so much? | Scoop.it

  • Tim

    Isn’t building a private cloud the IT equivalent of building a nuclear power station to generate electricity?

    Few new companies own IT.

    For the most part, Nicholas Carr’s predictions are coming true: IT is rarely a strategic differentiator, it’s an input of produciton, so it should be delivered at lowest cost, which means sourcing commodity services, then commodity products where there’s no economic commodity service.

    The only IT challenges are how to refactor the applications to run on low cost, low reliability computers charged by the hour, rather than owned assets, and how to put the IS capability more into the business lines. Much of the technology specialisms should (IMO) be closed down.

    Divvying up the cost of Capex in a traditional IT function is nearly always a source of friction with the business – that’s one of the reasons that *aaS is so attractive a sourcing model.