1. The frequency dimension: We are not talking about the frequency of operational changes to existing cloud services. What is more likely to become an issue, is the increasing number of service transition activities due to much more frequent onboardings and integrations of complete new cloud services reacting on business demand. In addition, after the implementation of an initial cloud, the lifetime of contracts for enterprise cloud services will shorten dramatically.
If we think about semi-automated brokering capabilities already existent on the market (cloud.exchange), a next transition dimension needs to be considered: the time dimension.
2. The time dimension: In comparing to traditional outsourcings, transitions of new cloud services are very short by nature. This is due to the agile development/engineering methods and reduced complexity because of the onboarding of already commoditized services. Short contract lifetimes (shortened service lifecycles) and the need for time critical completion of brokering and integration tasks will be a challenge for any organization.
3. Reduced complexity will lead to another dimension: Transition scope. When an organization has completed a first transition, the complexity and scope of any further transition should be reduced. This under the assumption, all transition and transformation tasks have been completed successfully at a frist time in order to be ready to operate/orchestrate the cloud service. Initial transition/transformation goals are:
- completion of all integration tasks (network ,access, security, data, application, processes, interface tools)
- setup and training of new/modified processes and interfaces
- setup and training of the new
- build of the new service on/off-premise
- modified organizational roles
- test according to defined service acceptance criteria
The first transition will set the ground for any further transitions. Main elements are already established by the first one (processes, interfaces, roles/responsibilities). Recurring transition activities will be more toward build, test, deployment and integration. Part of service transition is the decommissioning of services (contracts) and the transition of service and/or data back in-house, or to another service provider (contract).
4. The frequency, agility and reduction of scope of cloud transition will trigger another dimension to be considered: Transition quality. Quality of cloud service transition means consistent and repeatable transition performance – achieving service acceptance under time and effort constraints. Consistent quality will lead to commoditized cloud transition capabilities.
5. The definition of quality, related success factors and KPIs will be overseen by a next transition dimension: Transition governance. What generic frames are applicable for governing cloud service transition? During its first initial adaption of cloud, most organizations will adhere to the traditional project management methods to govern cloud service transition. This is completely adequate initially, but it is most likely not the right approach continuing the transformation toward cloud, given the frequency, time and complexity issues discussed previously. Adequate alternatives will be agile project management methods, or DevOps and Continuous Development/Continual Integration frame works based on a cultural change and process automation.
With process automation we are closing the loop between the traditional, ITIL aligned service transitions, with the more agile ideas of the cloud area. For Devops as well as for Continuous Development/Continual Integration, defined and automatized processes like change, configuration, deployment and testing are prerequisites.