In one of my last blogs, I was reflecting on “Private Cloud and the impact to the existing IT Service Management System”. This view took in consideration design, transition and operation of an internally managed private Cloud.
There might be reasons to review the internally managed private Cloud model:
- Building a private Cloud environment with out-of-the box Cloud products might by cumbersome, especially all the necessary integration, automation and orchestration effort is far too high, complex and costly,
- Shortcomings in expertise, experiences, skillsets for Cloud architecture, engineering and integration design and build,
- Shortcomings in expertise, experiences, skillsets for efficient and effective Cloud operation management,
- Building an running a complete new set of technology is just not in line with strategy on core competencies,
- Sourcing opportunities/alternatives are in line with company compliance and risk profile.
So what is the impact to the Service Management Model by moving to an externally managed private Cloud?
First and foremost, the management would need to understand the value of a defined sourcing strategy supporting the definition and the sustainability of the business case for an outsourced private Cloud from strategy over design, transition to Cloud Service operation. Besides the decision on the horizontal life cycle span of sourcing, the other sourcing dimension to be considered is vertical range of ownership for the Cloud Service’s value chain.
Furthermore, the Cloud Service portfolio would need to be modified catering for the impact of the outsourced service elements. Same for the Financial Management: the definition and implementation of a pay-per use cost model between two separated legal entities would need to be supported.
Secondly, all the processes and functions supporting Service Design would need to be adapted for the support of an outsourced model. Sometimes hard to swallow for the teams in Service Design is the fact, that they have to revisit their traditional “selecting products (Cloud tech stack) approach” scope and responsibility. Now they are being asked to define service specifications based on business requirements and to process those specifications as part of a proper Service provider selection exercise. In order to do so, processes like service level, capacity, availability and continuity and security and, last but not least, supplier management processes and the respective process outcomes are becoming paramount.
On a capability level in Service Design, the shift to be supported is from technical skillsets to service and supplier management covering business consultancy, architecture and security as well as compliance and integration capabilities.
Thirdly, Service Transition and its processes are becoming a new challange since the Cloud Service is being setup under the responsibility of an external partner. All the integration layers between in-house and provider (data bus, identity & access, processes, roles, boards) would need to be established as designed and contracted during that phase. This requires tight and stringent governance over the transition project.
Finally, the internal IT organization is not struggling anymore with definition and implementation effort for automated processes in service operation. The Cloud service provider will have all the operation processes being automated and integrated with customer’s portal, sign-on, dashboard and reporting functions. Capabilities and skillsets remaining in-house in service operations are to manage the provider regarding service performance, demand and change management, service reporting and accounting as well as continual service improvement.
For the moment there’s only one thing left to say. Even when a company sticks to an internally managed Cloud Service model, by integrating public cloud offerings with private Cloud Services (hybrid model), all the listed aspects above will have to be taken into account as well.