There are quite a lot of companies hopping the “private cloud train” the last months. Reasons for considering private cloud deployments are:
- Business data have to be “on premise”
- Industrialization, automatization, standardization of internal IT
- Re-use of investments already made (virtualization, server, storage)
- Development of internal skill sets supporting the move to a modern IT provider.
Most of such companies are running their IT under the governance of an IT Service Management System based on ITILv3 ®.
Question is: Are there any changes to the definition and implementation of the IT service management processes needed supporting the private cloud deployments?
Answer is yes, indeed, there are a couple of things that need to be reviewed, prioritized, communicated and trained.
- Considering a new customer/business perspective
Customers focus will shift to strategic discussion with IT rather than being busy complaining about number and duration of incidents. Very soon, they will be interested by when an under what condition they can move their applications to the cloud. This will be a discussion along Service Portfolio, Demand and Financial Management processes, followed by the definition of service quality parameters along the Service Level Management process. If the management system in place is not very mature (process capability wise) for all strategic processes, there are investments needed to develop IT capabilities supporting business relationship management on truly strategic level.
The Service Catalogue in place is just a collection of application names and prices? Well, catalogue management supporting a private cloud service means:
- Description of the cloud functionalities
- Options and descriptions of service quality parameters (i.e. capacity bands)
- Pay-per-use conditions in form of consumption units and real-time reporting options
- Instanciation of a good portion of the service catalogue as executable service request catalogue (self-service portal).
Service Level Management and all service quality processes (Availability, Capacity, Security, Continuity Management) are needed to frame the conditions under which the private cloud services are going to be delivered to the business. For a lot of IT organizations, private cloud initiatives will be the starting point of investing in the maturity of the Service Design processes. The service model is new, service definitions are new, customer/business requirements and expectations are fresh and unexploited.
The second customer perspective, a rather operational one, will be the ability to self- manage the service functionality and non-functionality wise. Self-service management means no traditional interaction with the IT organization neither with service requests nor with incidents tickets.
- IT Process and Operation automation
Having talked about Self-Service capabilities: What does it mean to process automation?
First of all: Before anyone can automate something, it has to be defined. Sounds simple but the reality of a private cloud program will unearth process bodies and zombies a big deal. An automated service catalogue with a self-service portal is just a starting point:
- Financial management: counting service consumption units (so called “metering” and real-time charging has to be defined and implemented. Consumption units are capacity volumes. Elastic and rapid increase and decrease of consumption of capacity volumes requires the automation of Capacity management.
- Self-service management means the execution of service request in real-time based on defined standard changes. An automated Request Fulfilment process will trigger process automation for Change, Deployment and Configuration management.
- Availability of a service is certainly one of the critical service parameters to the business. This will stay the same for private cloud services. However, Availability Management in the cloud will be different: The reactive part of availability management will become marginal; the proactive one has to be defined and implemented in an automated way. By re-thinking the consequences, there will be serious impact to the processes supporting availability: Event Management.
- Event Management will become THE backend process where a lot of the IT business logic will have to be deployed to. Automated self-run (resilience) and operation control capabilities are needed. Same for Release Management. Hopefully, well-defined and implemented Event, Release and Deployment Management processes will impact the Incident Management too: Assumed, cloud end-users will not be affected by incidents the same way like it is with traditional IT Services, a new definition of Incidents is required, especially the demarcation of Events and Incidents (when an Event becomes an Incident) will have to be reviewed. Fighting incidents itself will also be an automated process with a good portion of IT business intelligence. Which will lead to the question: What will be the role of the first level (Service Desk, IT Operation) and the second level (usually Technical Services in the future? For Service Desk and IT Operation, there will be a decrease in responsibility and workload for sure. For Technical Services functions there will be a workload shift from Incident Management to Problem Management. And for Problem Management, same as for Availability Management, there is a move from reactive to proactive management needed: Problem Management will be based on the analysis of events and trend of events and not so much on Incident Management information.
- Access management capabilities needed for private cloud are being sourced by three requirements: Self-service just-in-time, security aspects and consumption metering. Access management will have to automate the implementation of the combination of the three requirements: Authentication, authorization and accounting.
- Service Broker Capabilities
Private Cloud Services have their limits: Capacity volumes – and respectively business demands – are limited by the finite hard-and software stack “at-premise”. Almost infinite capacity would only be available by adding public capacity offerings to private cloud services. This discussion with the business will start very soon.
The theoretical concept behind the capability of the internal IT to enrich their private offerings with public services from the market is called “Service Brokering”.
Of the three Service Brokering models (see Gartner):
- Cloud Service Intermediation
- Cloud Service Aggregation and customization
- Cloud Service Arbitrage
the “Cloud Service Intermediation” model is one applicable for internal IT organizations. This model provides added value support on top of one or more existing cloud services (private) to enhance some specific capability of ‘said’ cloud services, without actually providing any of the cloud services itself (public cloud offerings).
Intermediation service capabilities may include identity and access management, service level management and reporting, security management and incident reporting, or supervision on pricing and billing. Intermediation services providers often also provide pre-contract consultancy services such as guidance of the cloud customer through the cloud selection process.
By looking to the requirements of such a model to the existing IT Service Management System in place, this model certainly will have an impact to the maturity of Supplier Management (supplier selection, service quality requirements and price models), Service Level Management (managing underpinning contracts), Security Management (business data ready for public) and Service Continuity Management (no internet – no service, complete vendor failures, contract exists and data availability).
Re-shaping the existing Service Management Model for private Cloud
All the above mentioned process capabilities have to be in place for an internal IT organization in order to become a private cloud service provider and a service broker on top of it.
Many IT organizations are making use of the already existing Continual Service Improvement Process (CSI) and addressing the gaps as part of the process. Other organizations start a dedicated project (some of them are using agile methods) to defined and implement the needed capabilities. And still others develop and implement a dedicated, new IT Service Management System (Cloud Operating Model) in parallel to the existing , traditional IT model and make use of a Cloud Migration Concept to transition traditional services into the cloud.
Very good post, I was really searching for this topic, as I wanted this topic to understand completely and it is also very rare in internet, that is why it was very difficult to understand.
Interesting article. The positioning of cloud service broker makes sense !