Monday, October 22, 2012

Critical System Workflow Management

This is something I penned back in 2008 before I had much knowledge of Service Management and the frameworks that support it. Our environment was plagued with poor communication and changes that had a rippling effect on systems up and down stream that nobody really seemed to care about. This document was a response to that. Of course, back then, this got no traction.


Critical System Workflow Management
By: Joe Frohne

Managing complex information systems across an organization can be a daunting task. The basic definition of a complex information system is one in which large collections of interconnected components work together. Complex systems have many architectural layers and different people responsible on each layer. Some layers may even have multiple areas of responsibility. The fundamental layers in most complex systems include networking, database, application, web combined with operating system and hardware support, client support and customer support. When changes affect a complex system, they involve many people across many departments and the customer base.

Two current methods exist to assist with managing change. (a) The first is the change management process. Change management is often the control mechanism from which proposed changes receive authority. According to the Gartner group, “Change management investments should focus on the workflow to establish approval for a change request.” (b) The other popular process is configuration management. Configuration management has a primary focus on tracking infrastructure changes over time. Often, configuration management is implemented by the use of a configuration management database. Tracking infrastructure and changes within a database allow for the following benefits, according to the Gartner group:

  1. A real-time or near-real-time view of infrastructure components (also known as configuration items) and their dependencies within and across each other.
  2. Improved risk assessment.
  3. Improved root cause analysis.
  4. More reliable change management.
  5. Facilities service management.

The two processes of change management and configuration management are symbiotic yet different. The melding of these two concepts into what I am calling critical system workflow management and allows for a hybrid system to authorize and track changes to complex systems across the organization.

Critical system workflow management has four key concepts that provide a flexible framework to track infrastructure changes.

  1. Community change authorization.
  2. Transparent communication to stakeholders.
  3. Automatic workflow for implementing changes.
  4. Historical infrastructure change tracking.

Traditional change management has a very rigid control and authority structure. In my experience, most technologists resist an authoritative control structure by management. The authorization of changes in critical system workflow management is dependant on a community of peers, including managers, being plugged into the system. Since the technologists are better equipped to police peer changes for validity, this system provides a better authorization method that involves a wider group of stakeholders. This fits in with streamlining work by the use of independent empowered teams.

Communication across the various stakeholders would be enhanced as it would provide information to a broad group. The advent of web 2.0 technologies allow for communities and groups of people to collaborate together. This type of technology would assist in creating a critical system workflow management system. It would be tie together the community and provide transparent communication to all stakeholders, provide an area for workflow to schedule changes and tie in with a configuration management database for a historical view of infrastructure changes.

Critical system workflow is a mechanism that will allow for the management of changes to complex systems across an organization in a transparent and holistic way. The empowerment of a community to manage their own change process without a large amount of management involvement is a win for empowered teams and a win for over burdened managers. The success of any change management process, including critical system workflow, is dependent on (a) sponsorship from senior management and (b) involvement from the stakeholders in the implementation to garner a sense of ownership.

Friday, August 31, 2012

A Change is Still a Change

One recent thing we are struggling with is the idea of setting changes up on an "automatic" schedule. For example, setting a cron job on a production server to apply OS patches and reboot the server. While this may prevent the technologist from being up at 2am during the maintenance window, it does not get around needing to submit a normal change request.

There was a miss perception that setting up "automatic" jobs somehow got around the need to submit a change request. It's something we have to remind people of fairly frequently.

Our current software is custom built and does not yet support recurring change requests. Hopefully we can get the time to code that in so we can help make the daily work lives of our technologists better!

Thursday, August 30, 2012

Emergency Change - Rant of the Week

It is always fun to get emergency changes and sometimes they leave you shaking your head.

Emergency Change Reason: Classroom switches to be replaced that are currently not in use, but will be when school starts.

Background: To proactively replace old switches with the potential of dying and causing an unplanned outage.

I am not sure this rises to the level of an emergency, but lets consider it for a moment. The first thing is the "Emergency Reason" and while it is great that the switches are not in use, it does not really say why this is an emergency. That is alright, lets read further and see if the "Background" indicates what could be happening. No, not much in the "Background" section other than replacing old switches.

These types of change requests need more information for the CAB to make any sort of realistic decision. Of course, then the CAB is perceived as being nit-picky, but seriously.

I am not advocating lying to the CAB, but at least make it sound like an emergency. Perhaps the switches are throwing errors or maybe they are physically falling out of the racks. Who knows! The point is that the CAB needs to help educate people on what they need without being perceived as being nit-picky or overbearing. I find myself using up a lot of my banked "goodwill" with my peers over CAB issues. Looks like I should start investing in doughnuts and coffee to help replenish!


Tuesday, August 28, 2012

Basic Change Workflow


We used this graphic to walk our Interim-CIO through the basic change management process. We tried to present ITIL without a lot of technical jargon, but it was difficult since one benefit of using a service framework is to standardize on terminology.