Originally written for and posted on ThoughtsOnCloud.com.
Abstract: “Mama always said life was like a box of chocolates. You never know what you’re gonna get”. With cloud computing this is true on two ways because there is a wide variety of cloud services out there to compose with, like a box of chocolates, and it’s so that you don’t know up front what you’re going to get. This blog post offers the reader a 3-step-plan to guide your journey to the cloud.
Obviously the title is a variation on the famous quote from the movie Forrest Gump: “Mama always said life was like a box of chocolates. You never know what you’re gonna get”.
With cloud computing this is true on two ways;
1. There is a wide variety of cloud services out there to compose with, like a box of chocolates.
2. It’s so true that you don’t know up front what you’re going to get.
This blog post will discuss point 1; a follow up post will go into point 2.
A box of chocolates
The first statement of the title, the wide variety of cloud services out there, is a good thing. Almost every day more services are being made available as standardized services in the cloud, all available to be used to compose business functionality when needed. Now, I have been working as an IT Architect on standardization in IT landscapes for over years now, even wrote my masters thesis on this for IBM in 2008, I know this offers great potential.
And let’s face it; IT needs to be able to improve agility to take on the ever growing challenge of being able to offer enterprise users the functionality they need WHEN they need it. Both business and development want more agility, to consider IT as an asset and not just an inconvenient bottleneck in between. That’s one of the main reasons for the upcoming of the whole consumerization of IT trend, resulting in al sorts of “shadow IT” in organizations.
This is where the analogy of Lego bricks comes in, cloud is allowing all sorts of standardized bricks to be created, used upon demand and discarded once you don’t need them anymore. The difficulty however is that there are no building instructions on how to build your enterprise IT landscape with the available bricks, from multiple providers. My though on this is that we need a catalog of building instructions, same as Lego distributes building instructions with there boxes. Only difference is that we need to create building instructions with bricks from different vendors.
Lego your way into the cloud
The process of getting there is quite standard architecture, only the lingo is a bit different. In cloud the word workload has been added, see it as an abstraction of the functionality you require without going into the deployment model. Whatever way you look at IT projects and whichever terms you use, there are three main phases: Design, Build, Consume. Let’s go over each phase shortly to describe the key activities.
Basically, first figure out WHAT you need before you start HOW you will get it. Seems like an open door, but it only happens too often that organization units skip this phase or only do part of it. This results in organization unit deciding on a specific vendor or even cloud service, without looking at the broader picture. Not only functional requirements, but also non-functional requirements like security, resiliency, availability and data privacy should be taken into account.
- Create an IT Roadmap
Start your journey into cloud computing safely by first establishing a cloud strategy and implementation plan. Think long term before you act short term basically.
- Assess the workloads
Remember, there’s no one-size-fits-all cloud solution that will fit all your IT landscape requirements. Split up your IT landscape into chunks of unique functionality, called workloads, to be able to determine to get the best fit between each workloads requirements and cloud services out there.
- Define the best (mix of) delivery model(s)
There are many cloud services out there, from multiple cloud service providers each with their own strengths and weaknesses. Use a scoring mechanism to determine which delivery model best fits each workload.
- Define the business value
Don’t get all tight-up into just the IT part of cloud computing, actually look at the business value of each workload and how IT can increase this business value by focussing on specific aspects of cloud services out there. Think of rapid provisioning (have your in a matter of minutes) which increases business agility, the possible reduction of CAPEX (no upfront investment) or pay for use (stop paying for a service once you don’t need it any more) making it possible to expand/reduce your IT landscape without penalties.
- Establish the architecture
A common mistake is that a journey to cloud reduced the need for proper architecture designs, actually the opposite it true. Think about it, you are widening your IT landscape onto cloud services, this requires a well defined architecture that includes where which unique data is placed and how this data integrated with the rest of the IT landscape.
Start your transition into cloud with low hanging fruit, workloads that have lower non-functional requirements and/or are a one on one functional match with your requirements. Low hanging fruit can be development and test environments, which has lower non-functional and data privacy requirements than production workloads, or CRM functionality as a Service.
Once you have defined which workloads to focus on first, start composing the selected cloud services and integration mechanisms. Test the build cloud composite application and make sure it is integrated with your service management environment which should monitor key performance indicators, both functional and non-functional. This should allow you to manage and optimize consumption of cloud services.
Now we’re all done designing and deploying, we can start consuming the cloud composite services. Keep in mind that new cloud services, your building bricks, are created daily and evaluate if more can be gained from altering the composition regularly. More on this is part 2 of the blog.
So in short; get out your requirements, split your IT landscape into workloads and define architecture for each workload. Happy traveling on your journey into cloud!
Where do you see this going; do we need to build some sort of Cloud Consumption Reference Architecture, containing a wide variety of patterns on using multiple vendor ´bricks´? Let me know your opinion!