Change Connections

There’s a guy named James Burke, a historian, who had a couple of TV series called “Connections” and “Connections 2” (Discovery Channel used to show Connections 2). In these shows he would demonstrate things such as, “How the popularity of underwear in the 12th century led to the invention of the printing press” or “How the arrival of the cannon led to the development of movies.” Just do a Google search and you’ll find plethora information on him and his works. Well, change has many unintended consequences, some good some bad and business and IT experience these consequences daily. The major goal of “Change Control Boards” is to prevent unintended consequences, yet the nature of change is generally so complex that such consequences still happen regularly.

What is the most likely factor when a change (of any kind) has a detrimental effect on the enterprise? For those of you who liked, Cool Hand Luke, “What we have here is a failure to communicate.” The enigmatic nature of change is that the very communication of change tends to bring up forces that oppose it. On a side note, I think I tend to embrace change easier than most, since by the time I graduated from high school I had attended 12 schools in 6 different states and countries! There is a kind of universal nature to the change process:

Funny thing is that the change process tends to be done effectively in certain silos of the enterprise, but not really at the enterprise level. For example, most companies that run mainframes have very stringent change management processes for that platform. In fact, one of our products, CHANGE MANAGER for DB2, actually implements the above process for database schema changes and migrating them from dev to test to prod. However, the failing (not of the product) is that the process tends to be focused on technology rather than on People, Process, and Technology. Any change to one of the three WILL have an impact on the other two. Of course, having been an architect in my past, I always search for universal truths such as a universal CHANGE platform that incorporates the three. The first tendency is to throw technology at the issue because technology/tools are tangible expressions of the desired outcome – but, see unintended consequences. The very nature of introducing technology is Change itself.

This gets back to my surprise at the lack of maturity in change management processes – because, if the processes were mature, any introduction of technology to the enterprise would be preceded by a change process that factors impact to people, processes, and other technologies. And the Discovery process wouldn’t be such a mystery, because people and process impacted by change would be readily available in a mature change management process. I had a pretty unique experience a couple of years ago when it appeared that a BMC product for which I was responsible was causing an outage at a pharmaceutical company. This company has robust change management process (not necessarily technology). I got introduced to their change management review meeting which was a worldwide video conference that included business owners of the impacted businesses, IT management, and their vendors at once. The meeting had an agenda for considering changes and issues that impacted the business – and we were on the agenda. It was pretty intimidating at first, but I realized that it wasn’t a witch hunt, but truly a forum for identifying impact and workarounds from all three perspectives. Luckily, after two of those meetings, we had a workable solution in place… I guess not too surprising that a pharmaceutical would have strong change management processes – in fact I’d be worried if they didn’t.

So CMDB gives you a mechanism for storing the relationships between people, process, and technology relative to the business. The next step is to use this information combined with intelligence to do impact analysis. And, of course, we have automation to execute the changes.

Now to RSS. Using RSS from a support perspective is effectively using it as a change notification tool – a device for communicating change. I believe most unintended consequences are caused by lack of communication. RSS is a tool that can be used to communicate changes to interested/impacted parties both inside and outside the firewall – if we had a mature implementation of private RSS. Of course, the first thing to address is process, but enhancing change communication is a near first goal also. And RSS does not address how the impacted parties communicate how the change will impact them – there any many methods for addressing this already built however.