How a Cloud Infrastructure Can Save or Make You Money

Before you left click that mouse to go to that other “work related” page, wait a few seconds while I explain what I’m talking about. While there is a ton of hyped up, blown out and super hyperventilated information out there about how the cloud makes your life better, reduces your workload and ultimately makes your coffee and butters your toast, not much is said about how the cloud can help your company save or make money. Real money…not that kinda-sorta-maybe-coulda money, but real put-it-in-the-bank money.

Before I start my explanation, first let me say that there is no such thing as a free lunch and no one gets something for nothing. The cloud, like any other technology or methodology in IT, requires CAPEX investment in order to be effectively utilized and have the desired benefits…and ultimately drive OPEX costs down over time (within the ROI horizon) or provide efficiencies that increase revenues. No hocus-pocus, no magic…it takes careful thought and some hard work but, yes Virginia, revenue benefits and cost savings do exist in the cloud. Of course you must calculate savings after all implementation expenses are accounted for…things like hardware and software acquisition costs, personnel and space requirements, training, etc.

Second, I am going to frame this discussion based on an internal, private cloud only (but many of the same characteristics exist for other types of clouds), as I just don’t have the space to explicitly differentiate here.

Third, I am going to compare costs based on a relatively mature “traditional” datacenter against the same datacenter but with a cloud infrastructure implemented and running in a steady-state. A traditional datacenter, in my view, is partially (<30%) virtualized with little to no automation or orchestration and is moderately managed from a holistic perspective.

Fourth, and my last condition before I begin my explanation, I am using the NIST definition of a cloud infrastructure (so no fancy bells and whistles) found here: https://www.nist.gov/itl/csd/cloud-102511.cfm.

OK, we’re all straight now, right? Excellent. So how I’ll lay out the rest of this post is that I will first describe a couple of scenarios that exist in a traditional datacenter and then I’ll explain how they would be done in a cloud infrastructure. Last, I’ll point to where the revenue benefits are found or where costs are typically saved.

Time to Market/Value

Traditional:

1. A business owner or LOB owner decides they need an application built that will provide a new revenue stream to the organization so they describe, to a Business Analyst, what they want the application to do in the form of business requirements.
2. The Business Analyst then takes those requirements and translates them to functional requirements (iterating with the Business as to end results required) and then uses those as the basis for the technical requirements which describe the supporting hardware and software (COTS or purpose built).
3. A Technical Analyst or developer uses the technical requirements and produces a series of hardware and software specifications for the procurement of the hardware or software resources required to support the requested application.
4. Once completed, a cost analysis is done to determine the acquisition costs of the hardware, any COTS software, an estimate of in-house developed software, testing and QA of the application, and the eventual rollout
5. The business analyst then takes that cost analysis and creates an ROI/TCO business case which the Business owner or LOB owner then takes to Senior Management to get the application approved.
6. Upon approval, the application is assigned a project number and the entire package is turned over to Procurement who will then write and farm out an RFP, or, check an approved vendor list, or otherwise go through their processes in order to acquire the hardware and software resources.
7. Approximately 8 to 16 weeks from the beginning of the process, the equipment is on the dock and shortly thereafter racked and stacked waiting for the Developer group to begin work on the application.

Cloud:

1. A business owner or LOB owner decides they need an application built that will provide a new revenue stream to the organization so they describe, to a Business Analyst, what they want the application to do to in the form of business requirements.
2. The Business Analyst then takes those requirements and translates them to functional requirements (iterating with the Business as to end results required) and then uses those as the basis for the technical requirements which describe the supporting hardware and software.
3. A Technical Analyst or developer uses the technical requirements and produces a series of hardware and software configurations required to support the requested application.
4. Once completed, a cost analysis is done to determine the start-up and monthly utilization costs (chargeback details), an estimate of any in-house developed software, testing/QA, and the eventual rollout of the application.
5. The business analyst then takes that cost analysis and creates an ROI/TCO business case which the Business owner or LOB owner then takes to Senior Management to get the application approved.
6. Upon approval notification, the Developer group accesses a self-service portal where they select the required resources from a Service Catalog. The resources are ready within a few hours.
7. Approximately 3 to 6 weeks from the beginning of the process (up to 10 weeks earlier than a traditional datacenter), the computing resources are waiting for the Developer group to begin work on the application.

Savings/Benefit:

 

1. If the potential revenue from the proposed application is $250,000 a week (an arbitrary, round number), then having that application ready up to 10 weeks earlier means an additional $2,500,000 in revenue.
2. NOTE: The greater the disparity of resource availability, traditional versus cloud infrastructure, the greater the potential benefit.

Hardware Acquisition

Traditional:

1. A business owner or LOB owner decides they need an application built that will provide a new revenue stream to the organization so they describe, to a Business Analyst, what they want the application to do in the form of business requirements.
2. The Business Analyst then takes those requirements and translates them to functional requirements (iterating with the Business as to end results required) and then uses those as the basis for the technical requirements which describe the supporting hardware and software (COTS or purpose built).
3. A Technical Analyst or developer uses the technical requirements and produces a series of hardware and software specifications for the procurement of the hardware or software resources required to support the requested application. The hardware specifications are based on the predicted PEAK load of the application PLUS a margin of safety (overhead) to ensure application stability over time.
4. That safety margin could be between 15% and 30% which effectively means that the procurement of the equipment is always aligned to the worst case scenario (peak processing/peak bandwidth/peak I/O) so for every application, the most expensive hardware configuration has to be specified.

Cloud:

1. A business owner or LOB owner decides they need an application built that will provide a new revenue stream to the organization so they describe, to a Business Analyst, what they want the application to do in the form of business requirements.
2. The Business Analyst then takes those requirements and translates them to functional requirements (iterating with the Business as to end results required) and then uses those as the basis for the technical requirements which describe the supporting hardware and software (COTS or purpose built).
3. A Technical Analyst or developer uses the technical requirements and produces a series of hardware and software configurations required to support the requested application.
4. The required configurations for the cloud infrastructure compute resources are documented and given to the developer group.

Savings/Benefit:

1. Because the hardware resources within the cloud infrastructure are abstracted and managed apart from the actual hardware, equipment specifications no longer drive procurement decisions.
2. The standard becomes the lowest-cost, highest quality commodity class of server versus the individually spec’d purpose built(highest cost) class of server thus saving approximately 15%-50 of ongoing server hardware costs.
3. NOTE: I mentioned this earlier but think it needs to be said again: savings become “real” after all cloud infrastructure implementation costs are recovered.

These are just two examples of where an internal cloud can specifically help an organization derive direct revenue benefit or cost savings (there are many more). But, as always, it depends on your environment, what you want to do, how much you want to spend, and how long you want to take to get there. The best thing to do is ask your favorite cloud infrastructure specialist today (um, pick me, pick me!!) to help you determine if this journey to the cloud is right for you!

This is a guest post from Trevor Williamson, from Green Pages. As Director of Solutions Architecture, Trevor 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.

Photo source: https://www.sxc.hu/photo/840240.