Enterprises will spend more on private cloud computing services through 2012 than on public cloud services — but the decision on whether to "buy" or "build" needs to start with a deep analysis of service offerings, a strategic plan for each service, and an evaluation of when external services will be available to meet enterprise needs.

• Services are hierarchical — some private cloud services will be built on top of public cloud services.
• Most IT organizations overprovision because they don't always fully understand customer service-level needs.
• For some less-critical services, IT organizations should press their customers to consider lower-cost alternatives, and lesser service levels.
• Every service is at a different level of maturity, and has a different future.
• Don't assume that a private cloud service will never migrate to a public cloud service; it should be designed to ease a possible migration to public cloud services at some point in the future.

• Inventory your services, discover your service-level requirements, and determine your costs.
• Build unique road maps for each of the services you offer.
• Evaluate and constantly benchmark yourself against external cloud service offerings.
• Build a private cloud service only after you have developed a complete business case analysis for doing so — it's all about return on investment, in terms of cost and business value.

Many Gartner client questions have recently focused on how to start building private clouds. Vendors are at their doorsteps selling private cloud computing. Clients are asking what technologies to use, which vendors to choose, and how to build a private cloud. It's Gartner's view that this is exactly the wrong approach.

"If you build it, they will come" is not a reasonable strategy for private cloud computing. Instead of focusing on products and technologies, and even architectures, first, we should start by understanding the services themselves.

Inventory Your Services and Service Architecture. The starting point is to understand what services your IT organization provides. If you don't have a service catalog, you need to build one. However, you also need to understand the hierarchy of IT services — those offered outside the organization, and services that are internal to IT. Many "services" will actually be at the end of a supply chain of services — some that are exposed directly to the end customer, and some that are very internal or horizontal (such as server and storage capacity, backup, or disaster recovery). Each of them needs to be evaluated as a separate "service." Many organizations will also find plenty of redundancies — services that can be designed to be shared— not only at the end-customer level (such as a consolidated payroll service), but even throughout IT (such as a consolidated storage capacity service).

Discover/Document Service Levels. For each of the services you provide, what are the service-level requirements (performance, availability, security, compliance, etc.) explicitly expected by your customers? What are their implicit service-level requirements — facets that IT may provide that your customers may not even be aware of? Documenting these implicit requirements is important, and will give your customers a better comparison to external services as those services become available. Are there service-level requirements that the customer isn't asking for, and you aren't providing — but maybe you should be offering as an option (for example, disaster recovery, faster deployments, etc.)? Finally, how well are you achieving those service-level requirements (and is there more work you can do to fully achieve them)? Most IT organizations don't have a complete understanding of customer service-level requirements (and often, the customer doesn't either), which tends to lead to IT organizations overprovisioning everything.

Determine Service Costs. What are the itemized costs for these services and their specific service-level requirements? In some cases, discovery here might lead to re-engaging customers in understanding their service-level needs. Are certain service-level demands worth the cost? Would it be acceptable to provide lower service levels for some services? Are there lower-cost alternatives you can offer?

Build Service Road Maps. While IT can improve the overall maturity of their operational processes, their technology architecture and their organization, every service has its own life cycle, and requires its own unique strategic plan. Some services are fully mature and standardized. Other services might require more work on process, people, or technology. Services mature at different rates. The road map for two services might be completely different. For example, the future of the business intelligence service or a supply chain optimization service is completely different from the e-mail or the storage backup service. Not every service is destined for the cloud-computing style. But for those that are, we offer the following guidance.

Evaluate Cloud Services. Once you completely understand your service requirements and costs, you can benchmark your services against current (and future) services offered by external service providers in "the cloud." For existing cloud services, this requires discovering their explicit (and implicit!) service-level offerings and costs, and where those offerings may fall short. For many large enterprises, the majority of their IT services cannot be satisfied by providers in the cloud today. Enterprises will need to predict when those services will be available, and when they will mature and meet enterprise needs. Every service will be different. Some services are available now, some will take many years, and some might never generate a viable business model to justify a cloud-computing service.

Build a Business Case. Knowing when an external cloud-computing service could mature is important to helping create a business case for or against developing a private cloud-computing service. When could the external service be available to meet your needs? How long would it take you to develop a private cloud service, and how much would it cost? How long would it take to achieve a return on your investment in a private cloud? Are there business benefits that make an early move to a cloud-computing style valuable to the business (e.g., speed of deployments, elasticity), and are they ready to leverage those capabilities? In some cases, a private cloud-computing service can be justified. In other cases, it is better to wait for the external offerings to mature. In some cases, a private cloud service can be shared "horizontally" across many other services (such as a virtual server capacity pool), improving the business case. Deciding whether or not to build a private cloud service all depends on the return on investment, in terms of cost and in terms of business value, before an external offering is ready.

Build a Private Cloud Service. Only after you understand your service architecture, requirements and capabilities, costs, service road maps, external choices, and the business cases can you start to build a private cloud service. Private cloud services will be hierarchical, with services built upon other services, and with some services that are shared horizontally. The anatomy of a typical private cloud service will include a self-service or service-oriented interface, automation to deliver on those service requirements, and virtualized resources that are orchestrated by the automation. However, a very important attribute of a private cloud computing service is ease of sourcing migration. It should be designed to be easily replaced by an external offering if and when an offering that meets your needs matures at some point in the future.

Constantly Benchmark. IT organizations should be prepared to leverage external services when (and if) they become available, and should always be able to compare the service levels, costs and cost structures of the private cloud service with public cloud service offerings. When an external service emerges that meets your needs, the most effective migration might be a wholesale migration (if the service interfaces are unchanged and the data can easily be migrated); but more than likely, a stepwise migration — hybrid cloud computing — will be more pragmatic. For example, a development and test private cloud service could start to leverage external resources gradually in an "overdrafting" mode.

Private cloud computing won't be the right answer for every service. Some services won't fit that style of computing at all, and others can avoid the private cloud completely and jump to an external offering. However, making these choices requires more fully understanding existing services, service levels and costs, the unique road map of each service and the services available externally, as well as a business case analysis of building a private cloud service versus migrating to (or waiting for) a public cloud computing service.

"Private Cloud Computing: The Steppingstone to the Cloud"

"Five Refining Attributes of Public and Private Cloud Computing"

"The Spectrum of Public-to-Private Cloud Computing"

"Cloud Computing Doesn't Require Massive Providers"

"Q&A: The Many Aspects of Private Cloud Computing"