I attended a meeting in March where John Easton presented his vision for the IT Department of the future. John is an IBM Distinguished Engineer and the Chief Technology Officer for IBM Systems and Technology Group in the UK and Ireland. See his published paper, The Future of the IT Department. John has also been interviewed by Neil Weightman for the Thoughts on Cloud blog site.
John used a component business model (CBM) for the Business of IT, and did “as-is” and “to-be” comparisons, showing his view on the impact and disruption cloud would have on the current IT department.
This method gave a good insight into where skills and resources would need to be rebalanced as we transition enterprises into being fully cloud-enabled. However, it got me thinking – what if we applied the same kind of thinking to an IT service management (ITSM) model, what would the post-cloud world look like?
For the purposes of the exercise, and to set some context, let’s assume these points:
- There will be a proliferation of cloud solutions within the enterprise, much of it sourced outside of IT, but IT is expected to ultimately manage it.
- The enterprise in question is fairly mature in terms of ITSM – most ITIL processes (or equivalents) are deployed and being executed with repeated success.
- The enterprises cloud providers will have various levels of ITSM maturity.
The following diagram illustrates this model.
At the top, we have all 26 of the ITIL V3 processes, fully matured within the enterprise. Below the line, we have a view of a number of cloud suppliers providing service to the enterprise, each with various levels of ITSM maturity. (Green indicates mature, through to red that indicates immature or not formally deployed.)
Enterprises will need to interlock their ITSM processes with the cloud providers. Depending on the maturity of each process within each cloud service provider, this process could be quite complex and resource-intensive.
Take for example the enterprise’s service desk. The service desk’s incident management process and work instructions will need to be updated to cater to each individual cloud service provider. Each provider is likely to have a different interface into their service desk, and in turn, incident management processes. For example, a cloud service provider may allow incidents to be reported through its website, but not commit to any service levels in terms of ticket response or resolution times. So in this example, the enterprise might initially log the incident in its incident management tool (for example, Remedy), but will then have to manually interface to the cloud service provider’s incident management tool.
So now, let’s consider the service operations towers and look at this information in detail.
|Process||Enterprise expectations||Possible reality||Impact|
|Event management||Systems are proactively monitored by the cloud provider. Any events that affect the enterprise are “filtered” up to the enterprise.||At worst, there is no monitoring, and issues and errors surface only when users contact the enterprise service desk, which in turn contacts the cloud service provider.||Enterprise moves from being proactive to reactive regarding the event management process.|
|Incident management||A fully integrated process and tool. For example, incident tickets raised on the enterprise incident management tool can be bridged to the cloud service provider’s incident management tool||The cloud service provider’s incident management tool is hosted on their Web Site, or is a forum. No service level agreements (SLAs) in terms of ticket resolution or response time.Each cloud service provider has different tools and method because no industry standards exist.||Increased incident resolution times. Complex service desk working instructions
Increase resources required on the service desk.
Where numerous cloud service providers are at play, the impact will be magnified.
|Request fulfilment||Each cloud provider has a service catalog, with APIs that allow the enterprise’s service catalog to be integrated.||Service catalog is online, each provider having its own. Manual integration between the enterprise’s service catalog and the cloud providers.||Increase request fulfilment times.Increase resource required for request fulfilment.|
|Problem management||Following Incidents, credible and comprehensive root cause analysis (RCA) reports are made available, and little evidence of repeat failures.Problem management tickets are ridged between the enterprise problem management tool and the cloud service providers .||Light-weight RCA is just enough!||Risk of repeat incidents.|
|Access management||Identity and access management processes and tools integrated between the enterprise and cloud service providers . Enterprise users have a single identity across multiple cloud service providers .||Each cloud service provider has different identity and access management processes and tools. To meet enterprise security policies might require introduction of manual processes (for example, starters and leavers).||Risk of security breaches because of badly managed IDs.Increase resource requirement to manage against corporate security policies.|
This is only the start – the same analysis could be done for all 26 ITIL processes.
So with this in mind, is the future of the IT Department one of service (and process) integration, shifting away from technical skills to service management and integration skills, becoming a broker between the business and IT service provision.
The cloud-enabled enterprise will have federated ITSM processes – this is inevitable. The key is to do this by design rather than by accident. IT need to ensure that sourcing processes are selecting cloud service providers with ITSM in mind – matching the maturity and integration requirements of the enterprise with that of the cloud service provider .