Avoid Disaster, Embrace People-Processes Like Change Management
By Dave Berry on Jun 26, 2009
While discussing organizational governance processes in the last entry, I realized that endpoint management, UDDI and service bus is a topic probably best described as a technical governance process and thus really more about tools than people-processes. In contrast, I want to discuss a very important process that focuses more on the people and communications that should be established before even the first service is conceived. Change Management. Those 2 words alone might be enough to make even the most disciplined IT managers scurry back to the comfort of their Linux prompts. Why is it that organizations implementing SOA often minimize the importance of people processes such as change management in favor technical tasks? Undoubtedly for many reasons but maybe because they are easier than organizing a group of stakeholders in a weekly meeting and can be performed in the dead of night without anyone else's input.
So why is change management so important anyway for SOA and isn't that why IT departments create all of these environments to test, stage, retest and deploy to production? As with many things including coding, the majority of time should not be spent managing the things that go right but instead managing the exception cases or errors when things go wrong. Below is a list of questions you should ask yourself when considering the role of change management.
-Do you have a well documented back out procedure when things go wrong with a production deployment?
-Is there an approval chain of command in place to resolve and decide when a back out would be required?
-Are all of the stakeholders aware of the change schedule and understand the full impact of a failed production upgrade or deployment?
-Has the risk to external organizations to which you may have legal and financial obligations been taken into account?
-Do you regularly evaluate all of the risk(s) associated with changes to production systems?
-Have you taken into account the system loads across different time zones of your users?
-Have end users received adequate notification indicating the schedule and benefits of major changes?
-Do external auditors review the procedures and provide feedback on your processes?
This is not an exhaustive list by any means but simply meant to make you think about what people processes you have in place to address unexpected technology issues. For many, a list like this may in fact be the exact reason that you have not engaged in proper change management because it's just seems to be so hard to gain consensus. Maybe it is best to step back and take a higher view of things. I found the following definition of change management on Wikipedia that I think encapsulates the goals of change management very well.
"Change management is the process during which the changes of a system are implemented in a controlled manner by following a pre-defined framework/model with, to some extent, reasonable modifications".
Now granted this is a pretty high level view but wow, it sure says a lot in that 1 sentence. I especially like the highlighted words such as "controlled manner", "pre-defined framework" and "reasonable modifications". An organization could do a lot worse than posting reminders or mission statements in plane view for all stakeholders to see and read it regularly. I'm sure many have implemented fancy operational dashboards on large screens that show real time monitoring of critical systems for all to see. Why not pepper in some organization goals or definitions such as this that foster communications and other people oriented best practices at the same time?
Ultimately, these sorts of critical governance people-processes should be ingrained into the DNA of everyone in your organization much as code reviews (you do code reviews, right?) and extreme programming practices might be. With workers distributed across different geographies, regular change management meetings may pose a bit more of a logistical problem but really, that is just an excuse given the volume of repositories, collaboration and notification tools at your disposal. While they seem unexciting to many, these sorts of governance processes are going to be major contributors to your future SOA successes. I can only imagine some of the horror stories that readers could share on this topic. Please, don't be shy about posting them here and by all means make them anonymous if you need to, but I suspect these stories would be a good validation of why these people-process best practices are so important.