What Does Your CM Manager Do?

Joe Farah's picture
Joe Farah asked on May 30, 2012 - 4:37pm | Replies (5).

A question came up in another topic, roughly: "Where does the CM Manager belong in the organization?" I found that to answer the question I needed to know what the CM Manager does - and this depends both on the tools and the organization.

In some organization's the CM Manager is responsible for builds. In others, not. In some the CM Manager is responsible for administration (ensuring servers running, users access, backups, etc.). In others, not.

So what does your CM Manager do? (and what CM tool(s) do you use?)

I'll start. We use CM+. Our product owner defines problems and activities to be addressed in each release of each product, in a prioritized fashion. The CM Managers observes, and occasionally contributes.

The CM Manager will handle most tool related issues. For example, if we change the host id or IP Address of a site (CM+MultiSite), the CM Manager will have to ensure those ids are modified in the "sites" file and then restart the transaction server on the affected site. When we do upgrades to CM+ (about once a year), the CM Manager is responsible for ensuring there is no down time (i.e. less than 5 minutes) and is responsible for ensuring that if it were necessary, we could cut back to the previous release.

More on the CM side, our CM Manager generates new Build IDs/Records to be used for system builds. Our CM Manager decides when to freeze a baseline (i.e. to create a baseline reference point). Our CM Manager decides where our "sites" are and brings up/takes down a site as necessary.

On the process side, our CM Manager ensures that the process is clearly visible within CM+, for changes, problems, requirements, whatever. Our CM manager creates new roles if necessary (e.g. customer rep). Our CM Manager adds new menu items, dashboards, and dialog panels as necessary, typically sitting down with a knowledgeable role representative from start to finish (typically for about an hour of interactive implementation).

And our CM Manager provides some help desk functions, especially to new users, along with a 2-hour course on the use of CM+.

So what do you do as a CM Manager?

5 Answers

bglangston's picture

Sorry, Joe, but that's a load of hogwash.

In the first place, builds is not a function of CM. It may be a task assigned to a CM person, but when that person is performing a build, he/she is acting as a build engineer. As to user access, if you mean to the servers, that is system administration. If you mean to the tool, or to product artifacts for which the tool serves as a repository, then that would be a CM function.

In essence, what you have done is obfuscate the division between the manager of the discipline of CM and some of the other activities that might be assigned to the position of CM Manager.

In my opinion, the bulk of your post is nothing more than an advertisement for how CM+ will facilitate/accommodate some of the activities that might be assigned to the CM Manager...but that does not necessarily mean that those are CM activities. But, mostly what you have done is present a thinly veiled advertisement for your product.

Joe Farah's picture
Joe Farah replied on May 31, 2012 - 5:32pm.

Thanks for you response... but I would disagree with you. I think when you talk about builds you're talking about compiling and linking, etc. At least if it has little to do with CM.

It is critical that the CM Manager participate in and take responsibilities for builds: Build Frequency, Types of Builds, Build Comparison functions, Build definition (prior to the build running), Build Promotion Process, Build Quality Metrics, and many more. Again, sorry you don't consider these part of CM.

In any event, I'd still like to know what you or your CM Managers do and which tools you use. As well, please feel free to identify what your definition of CM Manager is. Please contribute to the topic, but if you wish to take issue with the topic, you may want to do it through other channels so as not to "obfuscate" the topic.

Joe Farah's picture
Joe Farah replied on June 1, 2012 - 4:17am.

Mr. Langston. I'm not quite sure where you're coming from with some parts of your response, but I'll try to clarify things. Perhaps you're less familiar with the software side of CM, especially as standards have done a rather poor job in addressing software development, which is very different from hardware development. (That's another story.)

[quote]If the premise is false, then any conclusion that follows is false. [/quote]

Actually, more accurately, if the premise is false, anything (true or false) can be proven to be true from that premise (which means the conclusion may be false or true).

[quote]Does this mean that the definition of CM is dependent upon the tools one is using? (Or did you mean that an employees specific tasks are so dependent?)[/quote]

It does not mean or imply that the definition of CM is dependent upon the tools one is using. It does imply that what the CM Manager DOES(specific tasks) is dependent upon the tools one is using.

[quote]"CM is first a discipline; then a tool." (or something close to that).[/quote]

CM is a discipline - it's not a tool at all. Tools support the CM process. They are just software - not CM. Tools can help automate, organize, present, etc. But that's what they do, they HELP. CM is a discipline. A CM Manager is not a discipline. It is a role within the CM discipline. And this topic deals with what a CM Manager does and which tools (s)he uses to help do them.

[quote]<Builds> may have a little or a lot "to do with CM," and certainly the CM discipline is associated with or riding herd on these things, but that is a far cry from builds being CM.[/quote]

Specifically, there are three contexts for the noun "build" within software CM. The first is the "build" as a definition of what is to be built (and implicitly or explicitly how). The second is the "compiling and linking" part. The third is the artifacts of the build, including the build results.

As I mentioned before, the "compiling and linking" have little to do with CM, but certainly not nothing to do with CM, with the dependence being higher for languages that require a certain compile and/or build ordering. (e.g. Modula 2 required interfaces be compiled prior to implementation sections. Same with ADA). Unless these compile relationships are identified within the CM repository, the compiling and linking become less and less manageable. It is therefore necessary as part of CM Identification to not only give a label to these "sections" to be compiled, but also to be able to identify their attributes.

Futhermore, within the CMDB, it is normal to give these "sections" (generally files) unique identifiers, as required by CM discipline. However, such unique identifiers are different than those understood by the compilers and linkers. Hence, it is also necessary to be able to translate this identification into compiler/linker friendly identifiers (typically file names, each with a directory prefix). Furthermore, the directory prefix can change from one revision of a baseline to another (or from one build to another). Therefore, CM identification requires that we be able to relate the internal CM identification to this friendly (external) identification in a context-sensitive manner. (E.g. which directory prefix do I use on a file for build A vs build B ). This is quite a complex part of CM Identification that the vast majority of tools cannot cope with fully, and so short cuts are often taken which limit the functionality of the CM tool with respect to the required CM Identification.

Furthermore, it is necessary to be able to, given a build identifier, identify exactly which revisions of each object are in the build. This can be done from the CM repository with many tools. But it is sometimes necessary to be able to ask the same question of the software while disconnected from the repository. As such, some CM tools have the ability to insert identity information into the executables (through the build process) so that the file revision identifiers can be determined even when there is no access to the CM repository. This identification is still part of CM, even though it's not performed with access to the CM tool.

Also notice the need for unique identification of each "system" build (i.e. each significant, and hence recorded, build). One key use here is to ensure that the build artifacts are linked to a specific build definition, giving traceability from the actual deliverable back to the constituent components.

But this is only the start of the use of a build id. Let's look at the CM Audit Function. In software, a CM audit is not done by sitting down with someone and executing every functional case before their eyes and verifying the results. This would take an insane, unacceptable amount of time. Instead, the functional audit is done by ensuring that the requirements have all been addressed successfully. This in turn requires a record, not only of test cases and how they relate to the requirements (requirements traceability matrix), but also, of which test cases have been successfully/unsuccessfully run against a specific build, identified by its build identifier. If this specific capability is not present, then, except for very, very small software projects, you will not have adequate means to complete a functional audit. It is these build records, that is, which requirements have passed functional audit for a specific build, that help determine whether or not a build is going to pass the audit. Now in a large software project either the set of test cases is insufficient, or you will never get all test cases to pass for a given build. But that's OK - because it's software and can be fixed in place if necessary. So the passing of the functional audit has more to do with confidence of the software. This in turn is deduced from the Build's test case metrics, along with careful analysis of the types of failures that occur.

And it gets a lot more complex because requirements change over time, and so do the test cases, and the set of test cases that apply to a specific build (i.e. set of build artifacts).

In short, if the CM Manager does not take responsibility for the various aspects of performing builds, you will not be able to complete a software functional audit. As well, given that you can, you still need to ensure that you can identify the build, and verify that the components of the build match the physical audit (which revisions of which files are in the build executables, which in turn is traceable to which changes have gone into the build and which requirements are ultimately addressed by those changes). Tools HELP immensely here, but tools are not CM. It is also critical that builds do not go downstream (from development to integration to verification to validation to alpha to beta to production, etc.) without the proper criteria being defined for such promotions. Otherwise, although you have identified builds and failed their audits, they very well could end up in customer sites. So this promotion level, including the criteria, are an integral part of the Configuration Audit.

In software, the physical audit may be done manually for very small projects, but ultimately, you have to have confidence in your tools that it is putting into the builds what you expect is going into them. This confidence is gained in two ways: inspecting components of builds, and inspecting the tools and process that cause the components to end up in the build (i.e. artifacts).

[quote]Why is it "critical" that the CM Manager take responsibility for the activities you list?

I've dealt with some of the activities above... to continue:

One specific facility for doing these inspections is Build comparisons. At a low level, you might compare which file revisions went into build B that weren't in build A (and vice versa). But higher level build comparison tools allow you to compare which outstanding problems were addressed in B since A, which features and requirements were addressed in B that weren't in A, and which test cases passed (or failed) in B that did not (or did) pass in A. These are crucial for configuration audits. Build Frequency affects how easily such comparisons can be done. Incremental builds, as opposed to full builds, can be used (if done properly) to minimmize the re-creation of artifacts that aren't affected by the changes between builds. This may or may not make comparisons, and hence audits, easier, depending largely on your tools.

There are many other aspects of builds that affect status accounting. The state of a revision of a file is either in-progress or completed. Not so for the state of the build, which has a much more complex life cycle than a file revision. The integration and verification steps on a build allow us to identify the state of the changes that have been applied (often tagged against the file revision instead of the change package). But let's leave that for now.

Configuration control does not just deal with how change occurs to a configuration, but also who has access to perform such change. As such, things like roles, enforced process and access control are an integral part of configuration control.

In the same way, status accounting is not just a recording of "states". It covers an important "reporting" capability so that the "accounting" can be done. And it is important to be able to make decisions in a timely manner using the capabilities of the tools to provide status information. In this sense, the more you can adjust your tools to present the information each role requires with as little effort or change for error as possible, the more successful your status accounting capabilities will be. This is why we equip our CM guys with the ability to improve things like traceability navigation, build comparisons, process visibility, summaries, etc. Often this is done through the creation of dashboards, with a dashboard satisfying a particular aspect of a role (whether a CM Manager role, a product owner role, a developer role, or otherwise). Status accounting affects all roles because all roles need the communication of information which allows for proper configuration control, context-sensitive identification and various audits.

But you're right. If a CM Manager has to turn on his own light, electrician is not part of the CM Manager role. But even if it were, that has nothing to do with the definition of CM. So I'm not sure how you got to "What is CM" from "What does your CM Manager do".

But you sure raised some good questions that, when answered, help to clarify how my "carelessly tossed out" examples relate directly to the CM discipline. So thank you for the opportunity to clarify these. Sorry if it's not crystal clear - there's only so much time I can spend on such clarification. And there's tons more to add, but hopefully the picture is sufficiently painted here.

Now back to the Topic: What does your CM Manager do, and which tool(s) does (s)he use?

bglangston's picture

Mr Farah,
Thank you very much for a thorough explanation.

There are just a very few things I'd clarify.[quote]Perhaps you're less familiar with the software side of CM, especially as standards have done a rather poor job in addressing software development, which is very different from hardware development. (That's another story.)[/quote](1) I probably am less familiar with the software side of CM -- I've been working with software for only 25 years or so. Before that, it all started with publications, then moved to requirements, design, and data standards. Some of that software was autonomous, some was integrated with other subsystems, mechanical and electronic.

(2) I would argue that the standards apply to either hardware or software. The difference is in the application, or the mechanics if you will, of how the principles are accomplished. As you say, most of those CM mechanics are now performed by automated CM applications, which have been properly tailored by either the CM Manager or an app administrator (the latter hopefully according to the CM Manager's design).

(3) As you say, these applications save us CM folks monumental amounts of labor. There was a time when any (hardware or software) product required a CM team to perform all the tasks. Even the advent of electronic spreadsheets did little to reduce the labor hours required to maintain CM data records.

With that said, CM Managers, like many other job titles, have many duties and tasks to perform. These tasks can be separated into two broad categories -- CM duties and tasks and collateral duties and tasks.

Without going through your last response item by item, my response will address your previous post:[quote]It is critical that the CM Manager participate in and take responsibilities for builds: Build Frequency, Types of Builds, Build Comparison functions, Build definition (prior to the build running), Build Promotion Process, Build Quality Metrics, and many more. Again, sorry you don't consider these part of CM.[/quote]I do not consider these "part of CM" because they are the results of an effective CM program. The part of CM relevant to these items is ensuring that the items are addressed in the planning and accounted for in the execution. It would probably be more effective if the CM Manager addressed these items with the appropriate project decision-maker as part of developing the CM Plan or CM Procedures for the product. Take Build Frequency for example. Would a lead developer allow the CM Manager to decided how often his team would perform builds (any of the three meanings)? For many of those items, the CM Manager may make those determinations and perform the tasks, but frankly I can't think of a one for which it is critical that the CM Manager actually do them. If performed by the CM Manager, they would in my mind come under the heading "Collateral duties/tasks."

In any event, you'll have your adherents and I'll have mine. So I'll leave you to your topic:

What Does Your CM Manager Do?

jptownsend's picture

Billy and Joe,

I know this topic has been covered many times, perhaps both of you are right on CM duties and responsibilities and definitions.

Now the whole topic of sweeping up sawdust is a carpenters duties thing,
well it is, so is going to the hardware store, changing flat tires on his trailer, helping plumbers, carpet layers, brick layers, etc. As far as turning out the lights is what you do evey night is required and your the CM person who has to stay there after everyone is gone, then yes thats a CM function where you work and your replacement if its required they be the last person leave.

Again things change CM has changed dramatically, it has placed things on our plate we never imagined, but thats the beauty of this elvolving position, sure I could do everything a CM tool does manually and not even have a tool. I can manually install code, change things with a pen and paper, but I don't.


The Other Joe

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.