Configuration Managt Policy and Procedure template/help?

[bobduncan76]

We’re working on documenting a generic Configuration Management policy & procedure.

Please guide me to quality resources & examples which can help.

Thanks.

Bob.

[Guerino1]

Bob,

You may want to try CMCrossRoads.com. The entire site is dedicated to configuration management.

Regards,
_________________
[Edited by Admin to remove link]

[bobduncan76]

Cheers, I was looking for something like the MOF Configuration Management process document.

It’s a generic process which can be taken and customized by an organization, has flowcharts, is nice+simple.

Are there other docs, examples, templates etc out there I can get ideas from like this MOF doc? TIA.

Bob.

[Guerino1]

Hello Bob,

Good luck with running Configuration Management as a stand alone process. It's typically a byproduct of people actually performing their work, correctly.

NOTE: The definition of a "Configuration" is very vague in IT. People use it very loosely. I've found, throughout my own experiences, that it really represents anything and everything that revolves around "repeatability" for any aspect of a Product, any of it's Releases, any of any Releases' Changes, etc.

It's a little bit different for infrastructure than it is for software, but aside from automation, everything should be relatively the same. Here are some things to consider:

- All build information needs to be tracked, versioned, and managed
- Builds need to be repeatable, for both SW and/or Infrastructure
- Builds need to be highly defined, so as to make sure that you know and have access to each and every component of the build (or CI)
- Know and understand each and every source location for each and every CI
- Ensure that you track and manage every version of every CI
- Ensure that you can reconstruct any version of any build, in any environment, at any point in time (Checkpointing and Snapshotting)
- Builds are automated, where possibly, such as for software, infrastructure scripts, etc.
- Build templates are consistent for each and every team
- Build templates and tools are, themselves, treated as CIs
- Build templates and tools are all centralized and hooked into the master build system, such that they are part of the known configuration.
- Build documentation is all correlated by relevant Release, in such a way as to cover builds for each and every relevant component in each and every environment
- Repeat builds in each and every environment, so as to ensure the logistics are working properly
- Keep track of each and every relevant build tree, with all relevant frozen and tagged subcomponents/CIs
- Ensure that you can rebuild any and all Changes associated with any given Release
- Ensure that you can rebuild any and all Releases associated with any Product
- Ensure that you track and manage what New Requirements trace back to specific Changes, within a Release
- Ensure that you track and maange what Problems/Defects are being fixedx in specific Changes, within a Release
- Ensure that you track and manage what Risks are being mitigated by specific Changes, within a Release
- Ensure that you track and manage Build Configurations
- Ensure that you track and manage Packaging Configurations
- Ensure that you track and manage Deployment/Distribution Configurations
- Ensure that you track and manage Installation Configurations
- Ensure that you track and manage Instantiation Configurations
- Ensure that you track and manage Execution/Behavioral Configurations
- Ensure that you track and manage Deconstruction Configurations
- Ensure that you track and manage Rollback Configurations
- Ensure that you can track and Manage all of the above for Test Cases
- Ensure that you can track and Manage all of the above for Test Suites
- Ensure that you can track and Manage all of the above for Test Driver Data
- Ensure that you can track and Manage all of the above for Test Reference or "Gold" data
- Etc.

NOTE: There is no best practice area out there, RUP, MSF, SDLC, AGILE, etc. that covers Configuration Management properly. They are all very vague and general.

Also, there are very few people in most companies that truly understand all aspects of managing the details of each and every piece of Configuration Management. It is a huge space that requires a great deal of experience and understanding. It also represents a mindset or culture that has to be made mandatory by the Product Owners, who ultimatley are accountable for each and every aspect of their products.

Anyhow, I hope this helps.

Regards,
_________________
[Edited by Admin to remove link]

[itilimp]

Although it's slimmed down if you are looking for existing frameworks based on ITIL then also look at FITS

[bobduncan76]

The FITS example is nice.

Are there more examples like that out there? Even if by Vendors?

Cheers.

BD.

[itilimp]

The only other one that comes to mind at the moment is from the Ontario Government but I don't recall a config bit in there, I am most likely wrong so have a poke around their site.