Time for a tailored approach to service management
Service management must evolve to meet the new realities of the application economy or face irrelevance.
In my last post, I discussed the impact of mobility on the discipline of service management, and what it has meant for change management and also DevOps. Clearly, we’ve evolved to the point where change is no longer “one size fits all” proposition.
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 manifesto aimed 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 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!
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 – 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? Feel free to leave me a comment below.