Step 4: Effectively Managing Change
I recently overhead someone state a claim that everything in the CMDB must have an associated RFC (request for change), include a view of the compliant state, but not let auto discovery tools provide regular updates. The risk and outcome being there is little value to users.
Once I managed to pick my jaw up off the floor, my immediate response was, “Can you share with me the business case you successfully had approved for the army of task-munchers you have?”
In step four of my seven part series developed to help re-think how users approach service management, let’s try to deconstruct this person’s statement, and then reconstruct it with meaningful (hopefully) comment and use cases.
1. Everything Needs an RFC
In previous blogs I discussed ‘When is a CI a CI” and the level of depth required to manage it. Depending on where you landed on the broad spectrum of details and attributes, the amount of change activity necessary to be recorded can vary greatly. Maturity of the change management process is often mentioned, but having a well-documented process does not necessarily mean it is effective in execution, and that IT resources are following it each and every time.
What constitutes a change is always a fun conversation during process workshops, breaking down what can be considered a BAU (business as usual) change, or a routine change, compared to those that potentially elevate the risk profile of any change being introduced into the environment. Change types are useful but don’t represent the maturity of the implementing teams or the level of maturity – if there is such a thing – of the infrastructure and services being changed.
I recently had the opportunity to work with some of the largest IT organizations in the world. Enterprises with 50k+ IT users, and the sophistication implemented in their network infrastructure is akin to NASA putting a man on the moon in 1969! These organizations have high-availability everywhere, multiple redundant paths and routing methods….and the list can go on and on. For this level of maturity, certain changes are well understood and demonstrated to be low risk but very high in volume. Updates to the CI’s are real-time and feed CMDB each and every time.
Obviously, not every organization is at this end of the spectrum, but as your CMDB grows and more CIs are deployed, scaling the process becomes a real factor.
2. Compliant State
What is compliance anyway? It certainly makes IT users shudder and run for the nearest closet when they hear it. A very similar reaction to the word audit!
A compliant state can be:
- A document
- Architecture diagram written at some point in time that states the recommended profile of any service or CI and its operation in the infrastructure.
Okay, great! Tick that box! Now, in reality, the guys who are fighting fires all day and stringing bubble-gum and chicken wire together to keeps the lights on likely have little to no respect for these compliant state documentations, if they even exist, or are up to date.
A large gap exists when introducing new IT services into the environment. Often during project initiation, a first step is to plan the implementation or draw-up designs. What is actually deployed in production is typically some concoction, tweaked and tuned, based on user testing. Really, who ever goes back and updates or modifies the original design and declares this new compliant state?
Security, audit and regulatory controls change at a rapid pace, so a strong process is a huge benefit to ensure the compliance state is a living/breathing document.
3. The Role of Auto-Discovery Tools
Personally, I am a massive fan of discovery tools. The secret sauce here is controlling the scope of what they are authoritative for, how often they update, and keeping track of the rate of change in the IT environment.
Several years ago, a large financial institution had a project to build and deploy a new 750,000 sq ft datacenter. This massive undertaking involved the relocation of over 52,000 servers and all of the associated hardware. The organization gained many efficiencies using some sophisticated metrics to determine what was a physical relocation, swing onto new hardware or what were candidates for virtualization. Discovery played a massive role in this project, as the IT team was able to use it to determine the current state, compare against the desired state (in the new datacenter) and then audit the actual state once the move was complete. At times, over 1500 servers were being “moved” per week, so there is absolutely no way this could have been accomplished by their team.
Discovery tools can also be a great audit tool to find all the work that occurs outside of change management, and which could potentially introduce more risk into the environment, or those skirting around the process itself. Deciding what the role of auto discovery tools is a crucial step during implementation.
Managing change is not only a requirement, but auditors can tend to get a little hot under the collar when they find stuff they don’t like. Change can really help manage the CMDB and ensure the right process and controls are in place. It \enables IT users to complete daily tasks, without being a burden or chased for updates. Certain situations typically add fuel to the fire and result in knee-jerk reactions, typically in the form of over-regulating the environment. We all have them….Major incidents!
So What Changed? Are you now able to answer the question at the start of this blog accurately, reliably and in a timely manner? Have a think about it.
Up next – The dreaded audit and attestation….