When some analysts predict the end of ITSM
Last April, the InformationWeek-report published an article written by Art Wittmann - an independent IT analyst - titled “8 steps to modern Service Management” (read the report). The title was followed by: “ ITSM as we know it is dead. SaaS help kill it, and CIOs should be thankful. Here’s what comes next”.
ITSM as we know it is dead (Art says)
Behind this quite provocative introduction, this article vehicules some ideas that, to me, call for attention. Of course, from my ITSM-practitioner-point-of-view, it is riddled with preconceived ideas. But, above the discrepancies, I would like to refocus the eventual debate which opposes what Art calls the “pre-web era” (understand the IT and ITSM pros) and the ”scale-out world” (understand Virtualization, Cloud, SaaS, Devops and Agile culture). First, because the improvements susceptible to come from the technology breakthroughs and the new agile management approaches are (a bit) embroidered. Secondly, because ITSM is not presented as it really is. Probably, we - the ITSM community of practitioners - pay the ransom for our mistakes of the past. As a promoter of IT Service Management, I would like this article to be a positive discussion giving lectors a contradictory vision of how ITSM can support the “scale-out world”.
Perhaps, Art’s ideas are not widely spread within the IT community, and I should not worry so much about them. But they might create doubts. The reality is that Virtualization, Cloud, Devops and Agile culture have brought new approaches of managing IT Services. They strongly question legacy processes which may be perceived - by newcomers in the field of IT Service Management - as rigid and outdated. If questioning is a sane thing, this should not make us forget the lessons learnt from the past. Service Management, among others code-of-practice, makes us improve what technology had not achieved alone. What Art believes to be the solution will, from my point of view, obviously need IT Service Management practice to be secured and adapted to business expectations. At the opposite of Art’s vision, mine is that ITSM still has a bright future ahead of it.
In order to give you a piece of Art’s vision of ITSM, let’s take some extracts and comment on them:
“Millions of dollars and countless hours converting IT into a “Service provider” often via ITSM and ITIL initiatives, did little to improve delivery of tech to the business”
“Though not universally so, it’s fair to say that most organizations that adopted ITIL in all its splendor and glory ended up with the reputation of being insanely expensive, slow, and unaligned to the business”
“…since a move to virtualized datacenter can have more impact on service satisfaction that ITSM ever did.”
I can confirm Art that ITSM projects have provided more value to the business and performance to IT organizations than he thinks.
Art’s statements are too reductive and do not reflect reality. The analysis of ITSM achievements results in a mix of success and failure (as for any cultural transformation). If it is true that some arduous ITIL® concepts such as CMDB data model, demand modeling, or cost-per-service approach - to mention a few of them –have probably led to painful experiences due to a poor vision of what was exactly targeted or to a lack of guidance; at the opposite, it is also true that most implementations of Incident Management, Problem Management, Change Management, Service Level Management, Service Continuity Management, and others, have provided with concrete results for business, improving support responsiveness, service availability, trusted relationships with customers, and effective cost reduction.
I would not deny that some ITSM projects embrace too many objectives at the same time and didn’t sort out enough results. I would not contradict that some ITSM project managers have only focused on design outcomes providing poor practical results at the end. We all have been, once in our professional lifetime, struggling with abstract concepts with poor experience of them, making errors even if we were doing our best - this is the way we learn. We all know that the complexity of ITSM projects aiming to make habits and culture evolve, trying to get management support at all levels, are hard to achieve and generate frustrations. At the same time, if all IT organizations have an acceptable support service today it is thanks to ITSM best practices. If a minimum of control on changes difficult to automate exist today - avoiding adverse impact on live environment - it is thanks to the obstinacy of some believers in ITSM virtues. And 95% of companies – in western countries, from all economic sectors - have adopted ITIL concepts without rejecting the whole framework. So, it is not fair to lump everything together. What is probably true is that a lot of IT professionals, as customers, do not really know enough about ITSM contribution to business. If it was the case, this article would never be written. What we certainly mix-up is the mistakes of interpretation or implementation of the ITSM best-practices and their real efficiency. All depend of what you do with concepts.
Art Wittmann's statements (suite):
“ITSM was critical in the pre-cloud and pre-automation environments, but today it’s not well-aligned with Agile and Devops adoption”.
“…That timeframe is before there were cloud options, and IT was the only game in town – the concepts and tools of IT Service Management were indispensable”
“…now that the business has [SaaS] options and now that IT can be more responsive, ITSM and its concepts are outmoded. All we can say is, Right! Let’s move on”
I don’t see the point where ITSM is not well-aligned with Agile-Devops-SaaS approaches or Virtualization technologies
A lot of ITSM recommendations and best-practices support agility and actively contribute to building agile IT Services - in their infrastructure as much as in their applicative components - able to respond dynamically to strategic business changes. From the very basic ones such as event automation, service requests automation, to more elaborated ones such as standard change, release models, pattern of service consumption, service models - for which standardization go with agility and scalability at the opposite of bureaucracy and low responsiveness – ITSM offers a large range of media facilitating iteration, rapid decision, breaking silos, providing built-in quality design, etc. As to take examples with virtualization, many companies have re-designed their Change Management process and their Release and Deployment Management process to take full advantage of private or hybrid cloud and orchestration capabilities. If virtualization eases the delivery of computing power, storage and network, as of virtual workplace, ITSM is largely contributing to organizing their use in an efficient way through an agile “supply chain” - using sounded policy-driven workflows (called standard changes), request fulfillment portal, priority rules, cost or capacity monitoring, etc.
Too much credibility is given to “SaaS delivery model” and to “virtualization technologies” to be seen as the unique solution.
Placing SaaS approach and virtualization technology as being more “customer-oriented”, is a misjudgment. Automation secures operations and reduces the number of human errors. That is a fact. But technology alone has never sorted out organizational and policy issues. We already experienced important changes in service delivery automation and support operations in the past. The more the systems were automated, the more ITSM practice was required. The comprehensiveness and consistency of automation come from ITSM code-of-practice. What makes ITSM frameworks as ITIL® relevant are the common language and its concepts that help to anticipate specific situation and to propose the suited response that mitigate risks as it is expected by the business. This is exactly what feeds automation tools and future generation of hypervisor as well - and for a long time ahead.
Nothing prevents SaaS and Cloud providers to breach service levels if they don't apply ITSM best-practices
Another mistake is to consider that all SaaS or Cloud Services providers are good enough because they are based on new agile-provisioning approach. This sentence “What SaaS vendors knows and what IT pros need to learn…” is unlikely to be a certainty. Nothing is less reliable than a Cloud provider acting as a black-box. One of the major issues you can observe in some specialized press about Cloud Services, is the absence of best-practices application. So I would suggest lectors not to be too confident in technology adoption, but more in commitments and services delivery capabilities (which is valid for all types of Service Providers).
An adaptation of ITSM "legacy" processes is required, but new agile approaches don't replace them
This is true that virtualization of infrastructure and in general the “scale-out world” have created new opportunities to deal with incidents, availability management, and also Change Management. The ability to segment the resources capacity in multiple virtual environments facilitates testing, provides deployment reassurance, reduce interoperability incidents, and facilitate back-out plans. That forces us to change the way we usually protect the live environment from risks – and more permissive release models can be applied than before. But, that does not mean that all risks have been erased. For instance:
► Within a full automated word, the propagation of logical errors can be spread at a larger scale with poor Release Management and Configuration Management best-practices.
► Mixing DEV and OPS roles into a same team (which is sometimes the way organizations understand Devops) and responsibilities are not well understood, could lead to confuse agility with haste and comfort - which open to service breaches.
► Basic Scrum application, without global vision of the big picture, may engender loss of effectiveness due to a lack of standardization and templates use obliging to constantly reinvent the wheel.
All technologies need “architecture”, “standard”, “models”, to respect a minimum of rules and controls, which are provided by a code-of-practice as ITSM frameworks provide. So why consider IT Service Management as outdated if there is evidence that we still need it.
Art Wittmann's statements (suite):
“Painstakingly cataloguing and presenting services to customers, then managing those services in the ITIL fashion is too static. Going through the whole process is like painting the Golden Gate bridge, it takes a long time…. And IT environment is far less static”
“There are only 2 sets of people who like service-level-agreements: lawyers and uninterested [to customers] IT pros”
And some other extracts stroke me such as: the Service Catalog is seen as an “inward looking process” or that SLA is “considering users as the enemy”, or “the customer used to be IT teams in the era before SaaS”.
In most of the cases I know, SLAs and the SLM process have nothing to do with this.
On the contrary, all SLM activities are opportunities to create excellent relationships with customers, creating a genuine climate of trust, leading to business alignment. Because everything in SLAs is about understanding each other in order to provide the expected service, at the right cost, and being transparent about real capabilities. SLAs follow-up creates many opportunities to listen to customer’s expectations. If SLM uses metrics is to make factual appraisal, not to “hide [themselves] behind [their] SLAs”. The statement that “… they [the internal customers] don’t care about SLAs, …” is not the truth. Most of abandons of SLAs are due to a lack of trustworthy “partnership-spirit”, after a change in one-side's management. But, the ones who initially set up the SLAs know exactly their purpose and their value.
A positive sign is that Art “does not recommend to giving up on the idea of Service Management”.
He just believes in a “lighter-weight” and more “functional approach” to use ITSM. The solution for better IT Service Management resides for him in 8 points as follows:
► "Forget about SLAs”, just too bureaucratic and based on metrics for him,
► "Spend real time with customers”, what we could name as “Business Relationship Management” in ITSM language,
► "Work toward private and eventually public clouds”, to get more responsive provisioning of infrastructure – according to Art focus on technology,
► “Use synthetic transactions”, which means to monitor end-user's experience (or end-to-end transactions) - as Event Management recommends,
► "Empower the help-desk”, representing the voice of the customers,
► “Choose the right tools”, which seems to militate for “best-of-breed” solutions,
► “Survey customers and act on results”, which is common sense,
► “Constantly review IT team’s performance”, something that sounds very close to Continual Service Improvement.
At the end of these recommendations I see nothing really new breaking away from “legacy” ITSM best-practices, except his 1st point. So what is the conclusion to make from this article? Despite some doubts about ITSM understanding, nothing really opposed ITSM to the “scale-out world”. We can be even more convinced that both approaches will gain strength being implemented together. Most of the perceived oppositions don't come from an actual difference between the best-practices, but just only from the "ideology" you have chosen, its culture and its language. So whatever the "ideology" used, only achievements count.
Somewhere, ITSM has lost its credibility and we - the ITSM practitioners – have something to do to stop these opinions to expand - and if necessary, to restore the image of Service Management. I do agree with Art that ITSM practice should evolve with the new “web-cloud era” ; but not losing its core values and principles. New adopters of Agile’s approaches have to be opened to what ITSM has good to offer even if it sounds somewhere from a “bygone age” - see the article of David Hurwitz from Serena or get the report of Dave Bartoletti from Forrester, about the Cloud management in a hybrid cloud world. My conviction is that ITSM will survive to any technology change and to agile approach adoption.
Just to finish this article, I would like to mention the article of Kaimar Kairu (head of ITSM at Axelos) discussing the future of ITIL. This article of course gives much more positive perspectives to ITSM practices, and from my point of view, is closer to reality. Anyway, thanks to Art to have contributed to remind us how important ITSM is and to make it known.
End of article