Home 
From the Editor What is Configuration Management anyway?
From the Editor What is Configuration Management anyway?
What is Configuration Management anyway? |
 |
| Written by Bob Aiello | ||||||||||||||||||||||||||||||||||||||||
|
Many of my colleagues, including most recently the very knowledgeable Mark Bools, would define Configuration Management as being four specific types of activities:
While this terminology is familiar to me and many other CMers - I believe that it is less than clear - especially to those who are new to the discipline of Configuration Management. For example, do you really know what Status Accounting is? The terminology is at best arcane and I suggest that we need to get better at explaining not only "what" CM is all about, but exactly how to do it on a practical and realistic basis. The CMMI describes Configuration Management as "the Purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits." Hows does that hit you? To be fair, the technology field often uses terminology that can be challenging to understand as do many other professionals. This weekend I spent some time volunteering in my favorite endeavor of working as an Auxiliary Cop. Transit Cops refer to being "down in the hole" or "coming topside" and everyone reasonably understands that cops have their own lingo. As a volunteer EMT, I often felt like I was speaking a language from another planet as I described my patient as being A&O times 3, after a positive LOC - you get the point. But still I believe that CM experts need to make our discipline much more approachable or actually the word that I am looking for is "compelling." What say you? How do we have a precise language and still translate it into a language that everyone can understand, and more importantly, relate to on a day to day basis?
Set as favorite
Bookmark
Email this
Hits: 1988 Trackback(0)Comments (10)
|
TrackBack URI for this entry
Subscribe to this comment's feed |
... Mark , you defined perfectly well, not only what is SCM but hoe to do this, I apperciate. |
Dirk Wessel
said:
 |
... I have once learned that Configuration Management is: Accommodating Changes, optimizing the reuse of standards and best practices, assure that all requirements remain clear, concise and valid, communication, and assure that the product, service, etc conforms to the requirements. |
Dave Foster
said:
 |
... AND, I should have included Asset Management as a Pre-Requirements Baseline discipline. Dave |
Dave Foster
said:
|
... All, I find all of these comments informative and descriptive of Configuration Management and I use the simplest one myself, that is: 1) Configuration Identification, 2) Change (although I refer to it as Version) Control, 3) Status Accounting and 4) Configuration Audits. What I find lacking are the interconnections to Requirements Management, Change Management and Release Management. These are all disciplines that inter-relate to make for a cohesive environment. If any one of these is completely missing, we have gaps that are difficult to overcome. For me, the easiest to understand is looking at the following Configuration Management Baseline Methodology. This methodology identifies various software development life cycle baselines for a project or organization. For each baseline created provides the following information: •How and when it is created •Who authorizes and who verifies it •The purpose •What goes into it (hardware, software and documentation?) It is essential that changes to various types of items used or produced in the course of a development project be properly controlled and managed if efficient and cost-effective delivery of a high-quality product is to be achieved. A Baseline serves to freeze related components at logical points in time in the implementation of new functionality or processes. A change could be composed of a series of small changes or a single more extensive change that impacts several processes or system applications. A Baseline provides the needed mechanism to introduce such a change or set of changes at one specific time. This is referred to as the Baseline date. Further, Baselines provide an official standard on which subsequent work is based, and to which only authorized changes are made. The beginning of CM baselines provides management with milestone markers for project planning and tracking. The CM baselines are synchronized with the phases in the project’s Software Development Life Cycle (SDLC) and maintained for the life of the project (refer to “Baseline Management and Control – Configuration Management” above). REQUIREMENTS BASELINE The Requirements Baseline begins with project initiation (definition) and planning of a project. The Requirement Baseline milestone is reached when all known and approved Business and functional requirements that have been identified and approved for a project phase. Comes straight out of Requirements Management. Auditing is performed by the CM Manager or CM Release Engineer. FUNCTIONAL BASELINE The Functional Baseline begins with the completion of requirements analysis, reviews, and approvals. The Requirements Baseline plus the changed and/or new software development Configuration Items make up the Functional Baseline. This is maintained as the developmental configuration from which developers check out, create new or retire Configuration Items, unit test the ones that have been changed or created, then check them into the Allocated Baseline. Even though this section references software, there is no reason why hardware and facilities can’t follow this methodology. Auditing is performed by the CM Release Engineer. ALLOCATED BASELINE The Allocated Baseline is made up of the modified version of a set of software components checked out from the Functional Baseline by a developer in response to an approved Change Request or Defect Report (Change Management). This includes the approved documentation demonstrating that the software or hardware modifications satisfy the change or fix specifications. All software components delivered to the Allocated Baseline by the developers are audited for completeness and correctness by the CM Release Engineer as described in the section for Physical Configuration Audit (PCA) and Functional Configuration Audit (FCA) before they are integrated. Prior to these audits beginning, the Allocated Baseline is frozen to protect the integrity of the Integrated Baseline that is going to be built. In steps Release Management. Auditing is performed by the CM Manager or CM Release Engineer. INTEGRATED BASELINE This configuration contains all Configuration Items from the Allocated Baseline compiled together to make an executable system. All new, modified and retired Configuration Items have been identified and audited. Auditing is performed by the CM Manager or CM Release Engineer (other than the one performing the deployment). PRODUCTION BASELINE This configuration is maintained as the most current and correct repository of software components of the software/system being delivered to the Production environment. Auditing is performed by the CM Manager or CM Release Engineer. |
Bob Aiello
said:
 |
... I am going to respond briefly to Mark and then to Joe. Mark - we should have the discussion of how to attract and motivate volunteers in the forum where you are developing the BOK & the CM Wiki. I agree with you that getting people motivated is important and I can share some thoughts about what I have found that works (and what doesn't). I am glad to partner with you in getting this effort on track. Joe - all good and valid points. In the standards world I am pushing to change the meaning of Configuration Change Control from managing versions of Configuration Items (relic from years past) to managing runtime dependencies. I have also been working on a framework for defining CM that more closely reflects how CM is used in the real world. The CMMI was famously criticized for saying "what" to do, without explaining exactly "how" to do it. Some purists in the standards world think that this approach is fine. I think its less than optimal. We need to show our colleagues exactly how to implement CM in the real world. So how else would we describe the field of Configuration Management? Does it include Asset Management as ITIL v3 prescribes? Does it include Environment Configuration? Bob |
Joe P. Townsend
said:
 |
... Bob, I think the problem with defining CM comes in how it came about and when. In the 1950's there were no PC's the concept of Distributed Systems might have been a dream but not a reality, and servers were the size of buses and produced a lot of heat. IT roles have changed over the years, as IT has moved from the server rooms to the desktops. As IT has grown, unfortunately the field of CM has lagged behind the reality of those changes. Some people argue that CM is the 4 functions you mentioned, while others update that to say its Change, Build, Release, Deployment, and Issue Management etc. There are so many terms and differences it becomes a big mess after about ten minutes of discussion. Here is a good example, who should make sure that a change was successful based on the requirements. Using the 4 functions you mentioned above the CM person should make sure the requirements were all satisfied, when in reality that function is handled by testers and BA's now. I currently build an application were I am at right now, and I have never even opened the Application up in 4 years. I define CM as simply this: "The management of changes to anything" Doesn't have to be IT and CM is actually in everything we do, we just don't call it that. Regards, Joe |
Mark Bools
said:
 |
... Bob: could not agree more. Everyone over to the Body of Knowledge group and CM Wiki. Let's get stuck in. If anyone knows of ways we can get some enthusiasm into these resources I'd appreciate the input — I'm out of ideas. They seem to 'die' regularly and I'm rather keen we should keep them alive. The problem seems to be a lot of cheering from the side-lines ("good idea", "I'd like to see this done", etc.) and no actual contributing to the game (writing articles, posing notes, commenting on existing material, etc.). |
waseem shahzad bokhari
said:
 |
... I really appriciate this initiative.Hope this will be more informative in future. Regards Waseem Shahzad Bokhari |
Bob Aiello
said:
|
... Hi Mark - obviously your response is absolutely correct. But it does not help much with actually implementing CM. For example, "knowing what you have" does not explain embedding an immutable version ID into a configuration item (e.g. binaries, word docs, scripts). We need to raise the bar and help people understand CM better and also understand how to implement CM. I think that we should start working on that! |
Mark Bools
said:
|
... How about this for a slightly more colloquial interpretation of the more formal definition (only slightly tongue in cheek). Configuration Management is... Knowing what you have. (Identification) Knowing what is happening to what you have. (Status accounting) Knowing how you got what you have. (Audit) Making sure you continue to know what is happening and how you get it. (Change Control) What it lacks in precision it makes up for in simplicity. |
Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.
