Planning and Paying for Cloud Infrastructures
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 for planning 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. SMBs are mistrustful about being able to recoup their CAPEX costs by charging for utilization
C. With no clear asset owner (more on this later), SMBs 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 or operational expenditures) 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. They are very clear, supporting 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. That is, 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.
Trevor WilliamsonTrevor Williamson is Director of Solutions Architecture at GreenPages Technologies, where he contributes to the journey to the cloud blog. He is directly responsible for working with Global 1000 (financial, insurance and pharmaceutical) companies for the assessment and analysis, planning and design, and construction and management of enterprise technology (virtual, physical) infrastructures and for specifying and coordinating onsite professional services. Williamson has extensive knowledge and expertise in business applications and enterprise systems including designing complex, highly distributed virtual desktop environments for large enterprise clients. He has provided program and project management oversight and support for enterprise-scale solutions and is responsible for coordination of internal and external (partner) resources.