Public cloud is simple to buy and it’s simple to trial. For some reason this simplicity blinds people and cloud migration projects seem to appear from nowhere. People jump right in and start talking about network, storage and compute. Moving to the cloud is the answer. Can anyone remember the question? Where should you start when deciding what service, if any, could be migrated to a public cloud? You will find the answer in your service catalogue and not in any technical designs.
Before discussing things further lets clarify what I mean by service catalogue. Those of you with a technical mind might be thinking about virtual machine and service templates right now. You might be thinking about the methods by which users/consumers of the cloud will provision/purchase services. These things are important but not until after the decision to migrate to the cloud has been made. When I talk about a service catalogue I mean the database or structured document that defines all of the IT services that are offered to the enterprise and/or it’s customers. The contents of a service catalogue vary from company to company but at its core each IT service is described and defined from a business perspective. If you are going to define a strategy for cloud adoption surely the service catalogue is the place to start? All too often cloud migration/adoption projects are viewed as a technical project. The cloud has virtual machines; we need virtual machines. Let’s go!
Let’s think about what the service catalogue tells us. It typically includes, but not limited to, the following information:
- Service Name
- Service Description
- Service Owner
- Service Criticality/Importance
- Data Classification
- Legal/Compliance Requirements
- Target Availability
- Costs – Recurring and Initial investment
This sort of information is critical. You have to be sure that the public cloud can meet these business requirements well before thinking about the technical specifications. Let’s have a quick run through what I mean.
- Service Owner and Service Criticality/Importance: Lets take an IT Service that is owned by the CFO and that contains key financial data. Taken from a technology perspective the underlying software and database might be top candidates for cloud migration. But from a business perspective there is a lot to consider. You’ll have to work the service owner to agree if the service is a viable candidate for cloud before putting a business case together.
- Legal/Compliance Requirements: This varies from industry to industry but the question is the same. Does the cloud platform meet all legal and compliance requirements? I have seen this one crop up at the last minute and stop what seemed to be a viable project dead in its tracks. Find out what the requirements are and check with the cloud provider for validated compliance. Once you have understood each IT Service then you can start to consider which are viable candidates.
- Costs: The cloud is not cheaper. Its not and don’t let anyone tell you that it is. It’s a different type of cost (but you knew that). Your service catalogue should be able to tell you what the upfront and the recurring costs are for a particular IT service. The technology that supports the IT Service might still have a significant value to the business. The service might be a top candidate for cloud but you could be writing off a previous investment (people and/or technology) if you move too soon. Sometimes the loss is worth it but you need to at least quantify it. The alternative is to re-provision and use the technology elsewhere. Either way, it is important to review where the IT Service is in the investment cycle. Services that are nearing the end of their cycle are viable candidates for public cloud.
The point I am trying to get across is that a successful cloud migration strategy/project starts with choosing an IT Service is a viable candidate from a business perspective. The technical details can be worked out once all of the business requirements are met. IT departments/functions tend to be geared up to manage/provide systems and not services. This might explain why a lot of cloud migration projects are driven from a technical perspective.
If you are trying to decide/define what IT Services can be migrated to the cloud and in what order, then let the service catalogue guide you. Understand the importance of the service to your business and/or customers. Understand the where the service is in its investment cycle. If you are starting with how many VM’s and how many Terabytes of storage you need can I suggest that you stop right now and start from the beginning. Let your service catalogue guide you and don’t let cloud projects be defined by the underlying technology.