I have been mulling over a way to remember the topics I speak to in the next phase after preparation, the adoption phase. Its not quite fully baked yet but I thought I would throw out where I am up to.
The adoption journey if you want to really distill it down could be remembered as FLATS.
Function
Location
Aspiration
Time to return and implement
Service Levels
The order is not that great but here is some details on each. As you look to adopt Cloud for a particular use case work through those elements.
Function
What functions do you require in order to successfully run this application in the Cloud? There will be straight forward technical things and these will be based around the type of Cloud you are adopting. For SaaS you will be reviewing the features and functions of the software against your needs. For IaaS you will be looking at things such as the performance or configuration elements such as a load balancer.
Beyond the straight technology will be operational elements such as how much self management you can perform and how much the Cloud provider must do for you?What is the management Portal like? Can you integrate the authentication? What training might be required?
Also consider commercial functions. Do you already operate with and trust this provider? Are there legal contracts for you to arrange? What are the security characteristics of the Cloud service and do they meet your standards?
In the end you want to be confident that this particular use case for Cloud adoption can functionally do the job you require and that you can integrate it into your business.
Location
Where is the Cloud located? In this region (Australia) this topic comes up a lot and it certainly needs consideration. Where will the data reside and under what legal jurisdiction? However as Cloud is Network based the location and hence the network latency and bandwidth available may be very important as well. If you are using the Cloud for backup your location consideration may be different to if you are doing some Desktop-as-a-service.
Aspiration
This is a weird one and I have only just added it into my thinking. I am seeing in the market a real lack of aspirational ideas for Cloud adoption. How is your use case aspirational? Is it going to change the world and is anyone going to really care? I am not talking about living on the bleeding edge and being risky with "bet the business" workloads. What I am saying is are you actually changing anything. When I talk about what can be different with Cloud I often mention, "faster, cheaper, better". However when describing better I enforce that this is not just "doing things better but doing better things". As technology people we get all excited about cutting deployment time by days, but who really cares, how does this matter? What is the user or business outcome of this use case. What if a dramatic reduction in provisioning time meant that your Q&A team could run their regression tests every day rather than once a week, could this reduce the software defect lifecycle? With a shorter defect lifecycle could your programmers attack bugs closer to when they were introduced, giving faster turn around and getting the product out the door faster than would have otherwise been possible? Now thats doing better things not just doing something better and thats what your business and your users care about.
I am seeing too many people stuck in an Enterprise Architecture and looking at Cloud from a totally technical point of view, attempting to shifting their existing workloads feature for function from point A to point B. Interesting exercise but not very Cloud like. What do the users want? How does the different operational model of the Cloud bring to bear innovative opportunities that are just not possible if it was not Cloud based? This can be the case even for IaaS where the IT department may be the consumer/user.
In your adoption, lift your game, put some effort in and get aspirational. If not, why bother.
Time to return and implement
How long is it going to take you to implement the solution and how long to make your financial return. Now not all use cases will have a financial driver but it is usually a consideration. This is why one of the preparation steps before adoption is understanding your internal cost models. Yet you also need to consider how long is this going to take to implement, is this a rewrite of your application or do we just fill in a form and start using it? What is this going to take and is it worth doing?
Service Levels
What service levels do you require and what service level is available to you from the Cloud provider? This is something that could be tucked in under Function but its good to call out on its own. Don't be mistaken into thinking that the service level at a Cloud provider are lower than your own internal ones. A lot of companies do not run a 24 hour service desk, but the Cloud provider probably does.Based on these 5 elements you can review each of your Cloud adoption use cases. Some of the elements are more internal to your use case and only need to be applied once, such as the aspirational effect. Most of the others you will need to run a score card against the different Cloud providers you are considering. Having a score card will assist in your selection process.
Of course there is much to consider when you are ready to adopt Cloud. There are certainly things you need to consider at an organisational level along with your readiness program. However these are the ones I have matured for reviewing a particular use case as you embark on your actual adoption.
If you have any other ideas or feedback please post in the comments. Hopefully over the next few months I can lock this down, be great if I don't have to add another letter to FLATS.
Rodos