Automating a Formal CM Process

I’ve spent a lot of time exploring ways to automate IT management. I’ve chosen Ansible as my primary tool for this purpose because of its push model, clean syntax, and use of SSH. I find Ansible very well designed even though I disagree with some of it’s designer’s choices. Now it’s time to take a step back and look at the same problem from a formal CM perspective. By formal, I mean a CM process according to IEEE 828-2012. Unfortunately this standard is behind a paywall so it’s not easy to get a copy. I have one through work. You can find a lot of information about this standard on the web, however, even if you can’t find a copy of the standard itself.

My goal is to develop and test an 828 compliant process using Ansible. As I do so I will explain the main tenants of 828 and how to apply them. I expect and, indeed have already seen, a culture clash between that of IEEE 828 and the “CM” tools such as Ansible and Chef. I put CM in quotes because although they call themselves CM tools they rarely use standard CM terminology. For example, I haven’t seen the documentation in these tools mention topics such as baselines configuration items (CIs) yet these are the two most import concepts in CM.

This is to be expected, however. New and innovative concepts like automated CM usually start from a blank slate so that they have the freedom to experiment and invent unconstrained. Bleeding edge technology blazes a new trail, and is only later incorporated into the known processes. Of course, when it incorporated, the original processes are changed. And this is precisely what interests me. How do you use a new innovative tool like Ansible in a traditional and formal CM process such as IEEE 828? How can we have the best of both?

Another key element is the practice of continuous integration. Continuous integration is borrowed from agile software development. Most of the tools have grown up in the continuous integration culture. The question is how does this practice translate to IT management? Software development is not operations, though they have much in common which is the point of DevOps.

That is my goal: combine the best of the new agile IT management approaches with traditional best practices.

Categories: DevOps


Share Your Ideas

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: