Posted: Mon Apr 07, 2008 6:24 pm Post subject: Change Management between Data Centers
My organization currently has one data center; we're building a second now. Once it's operational both will supplement each other - so it's a co-processing scenario rather than a disaster recovery type functionality. We operate across the spectrum of platforms - mainframe and distributed.
I am working to develop dialog in support of the change management practices and policies in order to keep these data centers "in-synch" with each other. This to ensure that changes approved and made in one data center are replicated at the other so that, in the event of a failover situation, all infrastructural elements are the same (i.e. changes to a core level router/switch at one site are propagated to the other so that traffic flow acts the same at both sites...).
I have searched high and wide for reading material on this subject; I know that numerous organizations fight the same battles between data centers, but can't find anything definitive.
Does anybody have any references, periodicals, white papers, etc. that can put me on a path to stimulate discussion, ideas, etc. on this topic?
I don't have any papers to offer you right now but this is a fairly simple argument from my experience (recently project managed a new data centre whilst also being responsible for the core Change Management process).
Who in your organisation does not understand the increased risk of offering 'identical' services to customers that actually might have different configurations? It mind bogglingly basic common sense, let alone 'best practise'.
Who are you pitching this too? And what arguements are you facing, or do you just want a seal of approval from an IT white paper?
Would like to help but need to understand more about the problem.
UJ _________________ Did I just say that out loud?
What we have is a traditionally silo-based organization that is evolving into a matricized arrangement; 15 existing divisions that need to come together.
The part that I need to get buy in on is how we will monitor for and control change between the data cetners. What kinds of passive or active detection of change should be used, controls that will be put in place, etc. Everybody agrees that change control is a requirement, now I just have to get them to agree on the methods.
So I'm looking for guidance/examples on:
- policies/controls to implement for planned change, and
- how to detect change between the data centers.
Ok so it sounds like the issue is not so much focused on acceptance of change management but the it's brother Configuration Management.
I can't give you a full a generic policy or implementation plan because all orgs are different, but maybe some these questions will give you at steer at least:
Do you have a defined list of services (if not a formal Service Catalogue)? A lot of people think Config management means just buying the best looking tool on the market and rolling it out. Well yes, a good product helps, but it's just the power without the control.
If you have/can get agreement on service definitions then it makes the next question a lot easier: What configuration items are important for us to monitor and manage between sites?
Should the services being offered be identical in performance whether they are offered from one site or another? If so they should be identical builds.
Consider risk, impact, performance, significance of relationships between config items etc. Too many CIs being managed will obscure your view of what's really imprortant.
What do you want to measure about the config items? How will you be able to articulate this back to your customers?
Consider the people involved in this confguration management process, who needs to be involved? Who will own the process? Is it viable to add the responsibilities to job roles?
How will this be interlinked to your Change Management Process? Will it now be mandatory to list all CIs affected by a change? How will you measure success of the change afterwards?
How about checking that neither process is bypassed by staff? Who will run daily/weekly exception reports against CIs to see what has changed without an approved change request?
What data is important in giving you the right level of granularity into your architecture when reporting?
Then, finally you can look at products. And this really depends on the above plus your architecture, especially in terms of replicated/mirrored systems and DR sites/infrastructures. As above, wherever the same service is supposed to be offered from different locations then the systems should be identical and any changes to one system set up should be replicated in any other versions of that system - this should be a part of your Change Management Policy.
I'm sure there's other bits and pieces, but once you've got those requirements nailed you have something to articulate and can then start looking at getting agreement across the various silos.
Hope my brain dump helps!
UJ _________________ Did I just say that out loud?
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum