Date Published January 10, 2017 - Last Updated December 6, 2017
During an event in a London hotel recently, I found myself in the unfortunate position of needing to call for assistance with Internet access. As a self-proclaimed "geek," I would rather "self-resolve." In this case, I was constantly swapping one IP connection for another as I moved about the hotel, and I noticed that I needed to login again and again. I called the service desk operator who asked me how many connections I needed. I replied with the number five, and I was quickly given an unlimited code, as according to their records, I was already at five, yet I was only dealing with a single device that was still not connected!
That incident reminded me of the challenges of IT growth and the exploding number of mobile devices running applications. The conundrum for most IT service management organizations is that these mobile apps more often than not bypass the IT infrastructure and our service management processes, yet users are expecting us to provide support as if we owned and ran the service. In short, mobility is accelerating business expectations of the service management professional like never before!
The App Update Mentality
Think about the latest app you added to your smartphone. That app evolves in frequent updates, almost daily in some cases, and the consumer thinks little about the update process (in fact many, like myself, set them to auto install). Reading the list of enhancements on any given app update, it usually starts with a detailed roster of bug fixes. It’s all driving a new attitude and expectation around service, as should an app fail, the user anticipates that an update will be available in a few days. If not, they will turn, as I usually do, to an alternative product if it’s a convenience or productivity issue.
Working in the service management world over the last decade, I know that many of my peers and I have been maniacally focused on the performance, availability, quality, and reliability of systems that were often buggy and failed regularly. To resolve what some called the "traditional operations problem," we implemented highly structured and rigorous systems using frameworks such as ITIL for incident, problem, change, and release management, and these have worked well with major changes across organizations. For instance, we removed developers’ access to production systems, grouped changes into releases that were only implemented within specified change windows, and "de-risked" everything—almost to the point of organizational paralysis.
But Don’t Forget the Back End
Today, the delivery of IT-enabled business is quite consistent in quality and availability. The new generation of savvy business professionals is leveraging technology as a major disruptive weapon, but in an evolutionary, rather than revolutionary way. Yet we still have back-end systems that our business depends on for day-to-day functioning, and these MUST be effectively managed to ensure not just availability, but more importantly the integrity of the information and the business processes they support.
Clearly, all change is not created equal, and the fault of many IT organizations is that we have been treating it that way. Therefore, the traditional service management approach must evolve from a scenario where all change is equal to one that is flexible and agile and better meets rapidly changing business expectations.
Time for a Tailored Approach to Service Management
I strongly recommend that we take a look at our application development brethren who saw this evolution well ahead of operations. Back in 2001, a group of visionaries got together to develop "The Agile Manifesto." The scope of the manifesto was to uncover better ways of developing software—individually and through communities. While Agile software development focuses on keeping code simple, testing often and delivering functional bits of the application as soon as they’re ready, the Agile Manifesto was created as an alternative to document-driven, heavyweight software development processes such as the Waterfall approach. Of course Waterfall still exists—typically used for large changes to "systems of record"—but the focus for application development is matching the correct demand type to the correct execution process.
The time has arrived, some say overdue, for the operations organization to get agile, and the service management function must transition to implement and support processes that enable a rapid rate and pace of change. For example the tried-and-true change management process, where every change is highly documented, closely reviewed by the Change Advisory Board (CAB) and then neatly scheduled in a change window, will no longer suffice. Much of today’s change just doesn’t fit that criteria, such as website updates, or updates to a mobile app. So the operations org must allow for this type of change without an extreme overhead of management practices and controls.
Now, not all change is agile in nature and traditional organizations have started to introduce pre-approved changes that are typically automated across the lifecycle using an orchestration or automation tool. That said, I propose that we need to go further and accelerate the categorization of change types in order to better identify changes. In short, less changes for the CAB meeting or maybe even fewer CAB meetings altogether, and those meetings we do have will focus on the meaty issues of high-risk/high-impact change.
Those of us in service management must start getting engaged with the business and our application development partners at the initiation of change – back at the demand phase. This potentially small change, with minimal impact and little risk to the organization, is a significant cultural change and should be communicated to the business with the advantages. Those advantages will include a greater flow of change and innovation to the production environment, shorter cycles and of our course a better relationship. Additionally business change that is high-profile, high-risk, and requires lengthy development can be effectively communicated to the business in terms of the value of good controls supported by the current good practices. It’s all about expectation setting with the business!
Different Change Management Needs Call for Different Approaches
Think about a large bank that has implemented a process that that identifies changes that target innovation, such as a new client self-assessment that will allow a client to prequalify for a new car purchase. The solution is perceived to have little impact on the overall business yet offers real innovation to customers leveraging web and mobile delivery, if they used DevOps as a philosophy. The development organization is constantly updating their new products and services (without sacrificing testing, which is automated) while branch systems can use a more traditional ITIL-like process. Then changes to the core banking system, a system of record, are managed according to their traditional processes. The results include increased business satisfaction with faster time to market for new business services, while the availability of core systems is kept at record levels.
The warning for younger players here is one size for change doesn’t fit all, and everything in moderation. Use the correct process for the appropriate demand type based on risk, impact and even the volume of work in the change.
I believe that if service management functions do not evolve to accommodate for these new realities of the application economy, they will soon be made irrelevant or bypassed by shadow IT.
I’d love to hear from you. Where is your organization in this evolution? Are you making one size fit all, or are you adapting?
Robert Stroud is a principal analyst on the Infrastructure & Operations team at Forrester, where he focuses on driving the market toward a refined approach to software-defined infrastructure development and delivery. Previously, he spent more than 15 years in multiple roles at CA Technologies in business applications, product management, and product strategy. Follow Rob on Twitter @RobertEStroud.