Frank Schophuizen's blog

SCM tools are not configuration management tools

2009-06-08T19:16:00.006+02:00

The main reason why most so-called SCM tools are not really SCM tools is because they don't support managing software configurations. Making software is more than writing source code and converting them into executable code and data models for databases. A real SCM tool would be able to capture everything that is important for deploying and maintaining the software. This includes requirements, designs, models, sources, tools, infrastructure, knowledge, skills, test scripts, test data, manuals, scripts and other information.

Most SCM tools are able to capture files in a structure and control changes to the files and the structure. New files and new versions of existing files are all merely new files. Typically, the structure is 3-dimensional:

Directory (or folders) structure
Version (or revision) structure
Branching structure

The directory structure may seem to be a 2-dimensional structure (i.e. nested directories and directory next to eachother at the same nesting level), but if we consider the pathname + filename as the single identifier for a file, then the directory may be considered as 1-dimensional. The version structure is 1-dimensional: the successive versions supersede their predecessors. How about parallel versions? Parallel versions are partial contributions to a single succesor version. The actual successor is a merge of these partial contributions. Branches look similar to parallel versions, but the essential difference is that parallel versions are partial contributions to a single successor while branches are full contributions (version structures) to alternative successors.

If we look at the implementation of these dimensions, then the most simple implementation is 1-dimensional: all 3 dimensions are projected onto the same implementation, e.g. as directory structure (or path+filename). The "version control tool" could be an ordinary file system. For example:

main/gui/generic/foo-v1.c
main/webgui/unix/foo-v1.c
main/webgui/unix/foo-v2.c
main/webgui/unix/foo-v3.c
main/webgui/winxp/foo-v1.c
main/webgui/winxp/foo-v2.c
R1.0.0.0/gui/generic/foo-v1.c
R1.0.0.0/webgui/unix/foo-v2.c
R1.0.0.0/webgui/winxp/foo-v2.c

The problem with this version control system is that path+filenames changes for every new version. So users and the build process have to do more work to figure out which version they should us.

The next better implemention would be a 2-dimensional implementation: directory and branching are combined into a single dimension (path+filename), and versioning is the other dimension. Simple version control tools like Subversion works this way. For example:

main/gui/generic/foo.c (versions: 1)
main/webgui/unix/foo.c (versions: 1, 2 and 3)
main/webgui/winxp/foo.c (versions: 1 and 2)
R1.0.0.0/gui/generic/foo.c (versions: 1)
R1.0.0.0/webgui/unix/foo.c (versions: 2)
R1.0.0.0/webgui/winxp/foo.c (versions: 2)

Advantage is that the path+filename remains the same for all versions within a branch. But for different branches, the path+filename is different. And since directories and branches are resolved in the same dimension (the path), it is not possible to distinguish between a directory and a branch. For example, are main and R1.0.0.0 different branches? Are unix and winxp different branches? Are gui and webgui different branches? Or are they different directories within the same branch? So users have to make agreements about naming conventions to distinguish between branches. The SCM tool only takes care of deciding (automated) which version is used.

One step further is a 3-dimensional solution, where directory (path+filename), version and branch are independent of each other. More advanced version control tools like ClearCase or Synergy are needed. For example:

gui/foo.c (versions: 1 on branch: main)
webgui/foo.c (versions: 1 and on branch: main; versions: 2 and 3 on branch: unix; versions: 2 on branch winxp)

Advantage is now that the path+filename remains the same for all versions and all branches. This simplifies the implementation of an automated build process and the description in design documents and models. But the counterside is that SCM has to have the information to decide which branch a user is working on in order to select the correct version for the user to work on. And the user may be unaware of the branch he is working on - introducing the risk that he is working on the wrong branch.
So on one side SCM makes life easier for the user and the organization (e.g. automation), but on the other side it introduces extra work to reduce the risk mistakes or to repair them.

As you can see, I have left out the baseline (R1.0.0.0) from the last example. In the first and second example (1 and 2 dimensional), the baseline was combined with the directory dimension. In the last example, the baseline could be combined with the branch dimension, but it could also be implemented as a 4th dimension: labeling or tagging.

And this brings me to the point where version control enters the domain of configuration management. An essential feature of configuration management is to identify dependencies. A dependency defines which objects belong together. There are many different dependencies that can be (or need to be) identified, for example:

Directory dependency: all files within the same directory tree
Branch dependency: all files on the same branch
Version dependency: all latest versions
Status dependency: all files with the same status (e.g. release R1.0.0.0)
Content dependency: all files with compatible content (e.g. requirements-design-code consistency)

The status dependency is typically modeled in a so-called promotion model. All files go through a predefined series of statuses, and files (versions) with similar status and context (e.g. branches, directories) belong together as a configuration. These statuses are for exampe: working, integration testing, system testing, released. Tools support promotion by branching (e.g. ClearCase/UCM by deliver and rebase, or Subversion by "smart" copying of directories called branching) or by selection rules (e.g. Synergy by reconfigure property templates).

But one of the biggest shortcomings in SCM tools that I know is the absense of support for content dependencies. How do you identify the impact of the change of the design on code, requirements and tests? How do you identify the impact of code changes on other code, interfaces, design models? How to maintain the content information efficiently? How to you know that the content dependency is compromised? How do you know that release 3.2 of product X does work with release 1.2 of the framework, but not with release 1.1 of the framework? How do you know that release 6.1 of product Y cannot work with product X because it does not work with framework 1.2?

Another big shortcoming of SCM tools is that they only support control on file level. They don't control requirements, components in the design model, test cases in a test specification, tool versions (e.g. compilers, IDEs, webservices), hardware versions (e.g. 32-bit architecture). Consequently, many organizations try to capture those items in files, e.g. by creating a requirement specification document that "baselines" a set of requirements. But then again, those individual requirements - although versioned in a requirement management tool - cannot be identified as separate objects in the SCM tool, let alone that dependencies on requirements level can be identified or that individual requirements can be identified to a baseline.

The only solution that I am aware of that comes close to an "SCM tool" is the Jazz platform, starting the Rational Team Concert, but integrated with the requirements, test and project management applications. Since all information is stored in a composite repository, where information objects are actually identified as objects (not as files), it becomes possible to identify relationships (such as dependencies) between objects (not only files). Yet, I doubt whether it will be capable of identifying dependencies between configurations, e.g. content dependencies between software packages.

Rational ClearCase is not an SCM tool

2009-06-08T18:53:00.002+02:00

If Telelogic Synergy is not an SCM tool and Subversion is not an SCM tool, it is easy to conclude that IBM Rational ClearCase is not an SCM tool either. Not even ClearCase/UCM is an SCM tool.

Telelogic Synergy is not an SCM tool

2009-04-04T23:09:00.003+02:00

In Januari I talked about Subversion being not an SCM tool. Now let's have a look at Telelogic Synergy, which has been acquired by IBM recently. Until recently, I did not have much practical experience with Synergy and most of it slipped away. Now, I am working with it quite intensively and I came to hate and love it.

So let me explain why I think Synergy is not an SCM tool either.

Promotion model
Since the introduction of the task-based, more or less as a replacement of the ancient object-based approach, Synergy has adopted the approach of change sets. Tasks are actually change sets.

In Synergy you can define almost any configuration regardless of how, where or when the objects are changed. There are a few predefined change models, e.g. Collaborative Development and Insulated Development. The difference is that with Collaborative Development all completed tasks come available to other developers, while with Insulated Development tasks are promoted manually by the build manager.

Using queries on the database you can define almost any configuration. Through (semi-)automatically updates of the configurations, objects are "promoted" to the configuration. So for this Synergy qualifies as an SCM tool.

Real baselines
With the introduction of Rapid Baselining, you can freeze a configuration of multiple components and subcomponents instantly. The resulting configuration are immutable.

So again, Synergy qualifies as an SCM tool.

No projects, teams and streams
Synergy structures a database into (what Synergy calls) projects. In fact these are not projects, but components that can be developed and released independently of eachother, of hierarchically if you wish. Calling them "projects" is misleading because they do not constitute an enterprise for an goal within an agreed timeframe, using a set of resources. Moreover, you cannot even assign people to a project (only to a database) or define a particular scope to a project.

Synergy does not know the concept of teams, or roles assigned to people in a project. It does define "roles" to assign tool privileges, but no roles in the sense of a project (e.g. project leader, librarian, developer, tester, release manager, etcetera).

It may sound strange, but Synergy does not know the concept of streams. You can create parallel configurations (called "parallel projects") and parallel versions, but the concept of "a flow of changes" (like a river meandering through woods and valleys) is missing. Configurations are more like cities (being somewhere, changing constantly but going nowhere) than like rivers (changing constantly and moving constantly). You can define concepts that look like branches or streams using the release value, purpose and platform, but they remain configurations not streams.
Even worse, Synergy is quite "parallel intolerant". There is no distinction between checking out the same version twice (with the same release/purpose/platform value) and checking out versions in completely different projects (with different release/purpose/platform value. Why would you be need to be warned that someone in another project is changing the same object as you are? I can understand why you need a warning if it happens within your own project team.

Change sets
As a wrote above, tasks (or change sets) are in the core of Synergy. It's more powerful and more comprehensively implemented than any other tool I know.

Components
At first sight, the so-called projects may be considered as components. However, since Synergy tries to be "smart" in selecting sub-project versions (or sub-component versions) there is a clash between using baselines of released components and using a development configuration of a sub-project/sub-component. Due to this smartness, Synergy sometimes selects the "wrong" configuration.

No roles
Yes, Synergy does define roles but only to distinquish between different tool privileges (e.g. developer, build_mgr, ccm_admin). Roles to separate responsibilities and authority, for supporting promotion models and release management are absent.
Although... you can define a change promotion model in Change Synergy that grants authority to promote requests. So in Change Synergy (control of requests) roles can be defined but in CM Synergy (control of configurations) you cannot.

Although some things can be customized, Synergy does not quality for SCM tool here.

Limited branching
Some branching can be implemented using release, purpose and platform, but it is rather a way to distinguish between different configuration than between different branches. Also, Synergy supports parallel versions but it is hardly sufficient to call it branching.

Conclusion
Taking all the pros and cons into account we can conclude that Synergy is a very powerful tool and it comes close to a SCM tool. Yet, it lacks several important concepts.

Subversion is not an SCM tool

2009-01-30T20:07:00.002+01:00

Subversion (SVN) is not a Software Configuration Management (SCM) tool. It is a Version Control tool. Basically, Subversion is nothing more than a versioned directory tree with a few version control features.

Let me try to explain why I think that Subversion is not an SCM tool.

No real promotion model
First think that is missing from SVN, and many other version control tools, is the ability to support only the most basic promotion model: promotion of changes from your private work area to the branch in the repository, and vice versa.
A real promotion model would allow you to promote between various areas as defined for your organization. For example:

Private work area
Private system build area
Team integration area (also called the "stream")
Build area (often running a continuous build)
Test area
Release area
Staging area

In a real SCM system, you can define these kind of area and the rules (criteria) to promote between them. In SVN you cannot. What you can do is use branches - which are actually just a copy of a directory - and create a script or application to automate it (or do it manually).

No real baselines
A baseline is a reproducible configuration that is immutable (you cannot change it anymore). SVN does offer "tagging" but in fact it is creating a branch - which is a directory copy. The tag/branch is reproducible, but it is not immutable! You can still check out and check in on it, which is the normal way of making changes. Again, there may be workarounds, e.g. to remove write access for all users on the tag or by writing a pre-action hook that prevents check out.

No projects, teams or streams
Many software development organizations run more than one project at the same time, and/or have projects consisting of teams that work simultaneously. Projects will make baselines and teams will deliver to other teams. In SVN you cannot define integration areas (aka streams) for different projects or teams that are isolated from each other.
Again, we could use branches as a workaround; project-branches result in project-tags and team-branches are integrated (merged) with other team-branches and ultimately with the project-branch.

No change sets
Here is something you may disagree with. In SVN you can submit your changes in the work area to the repository. SVN does not create a change set for it, but it creates a new revision of the (whole!) respository. Of course, the new revision will be equal to the previous revision except for the changes you submit, but still SVN does not make a change set out of it. Nevertheless, you might argue that the submitted changes form a unity, which could be called a "change set".
The problem is however, that you submit all changes from your work area as a single change set, while in fact you may have been solving a problem report and implemented a new feature. If you want to identify the solution for the problem report (i.e. the change set corresponding to it) you are unable to do that.
A real SCM system is able to identify change sets related to units that are identified as managed items (e.g. work items, problem reports, change requests, requirements). Using a diff between revisions might be solution, but if branches are used to separate different areas, projects, teams and streams, the sequence of revisions in SVN or not so obvious. And again, adding a script to automate the selection of revisions to compare it adding an SCM feature that SVN is missing.

No roles
An SCM system is supposed to support an SCM process. One of the characteristics of an SCM process is that people can have different roles. Depending on the role, the process is different and with it the SCM tool behaviour is different. For example, a project leader is authorized to assign roles and the scope of control of a particular team or individual, but only for the project he is responsible for. These roles assigned privileges to the members of the teams.
SVN is able to assign read/write access to users at path level, but offers no means for roles like project manager, integrator, librarian, build master, developer, etcetera. Of course, you can implement this by hooks and scripts, but again you are extending SVN with SCM features that SVN lacks.

SVN does offer branching
Branching means that from a certain configuration (or revision in SVN) you create two - or more - parallel configurations. Typically, branching is intended to update a configuration from the past that cannot be implement in the current configuration (aka trunk, main, latest), for example a patch of a baseline. This is something that may be considered an SCM feature, which is supported by SVN.

Finally, SVN offers branching as one of the few SCM features. But reading back, I notice that many lacking SCM features can be resolved by applying branches for different purposes. If you are going to use the same technical solution to solve conceptually different SCM features, it will be quite difficult to distinguish between them: is the directory a promotion area, a project, a team, a stream, a baseline, a product, a component or module, just a parent directory to cluster projects, teams, streams, baselines, products, components, modules or just a leaf directory to cluster a number of files?
An SCM tool is supposed to help you implement an SCM process and a structure in the database. SVN only offers a versioned directory storage system. It's not an SCM tool.

Getting Things Done (GTD) made simple

2008-10-17T08:05:00.002+02:00

For many years I have been looking for Getting Things Done (GTD) in a simple way. And now I have found one:

Monkey GTD at http://monkeygtd.tiddlyspot.com

It's a TiddlyWiki file with a very simple, very sparse user interface, yet extremely powerful and versatile. No wasted screen space, just plain and simple look-and-feel. Since it is a TiddlyWiki, it comes as a single (html) file, requires no installation except a browser supporting javascript. It works perfectly with Firefox.

You can create actions, ticklers and references. Actions are set next, waiting or future, ticklers are connected to a date at which they will appear on the dashboard, and references are just entries with no timing constraint. Each can be connected to a contactperson, a project, an area (e.g. a department), a context (i.e. a category) or a realm (e.g work, personal), and it shows and updates cross-relationships on-the fly. For example, if an action is connected to a person and a project, you will see the action from the person and from the project, but also from the area that the project is associated with.
Each of the entries are just tiddlers, with some additional features. A tiddler is a wiki-page in TiddlyWiki. This means that you can add (formatted) text, or change the title or other settings. And of course you can make ordinary tiddlers.

I also use it to first define an action (e.g. "Schedule meeting with Joe about CruiseControl"), then add my meeting notes (preparation notes and discussion notes) to it and finally change the action into a reference (e.g. "CruiseControl") or into a contactperson (e.g. "Joe Plummer"). This way I build up my own wikipedia, while also supporting GTD.

If you don't know TiddlyWiki, you definitely need to take a look since it is the simplest wiki in the world, yet extremely powerful and extended by macros and plugins.

Rational Team Concert and the future of ClearCase/UCM

2008-09-27T16:24:00.009+02:00

Now IBM Rational Team Concert (RTC) supports Software Configuration Management (SCM) and build management, I am wondering how this would affect the future of ClearCase and UCM. Will it replace ClearCase? Will it complement ClearCase? Will RTC only be for small organizations, just like UCM started?

Number of users

Currently RTC is suited for no more than 250 users. This number is significantly lower than the maximum number of users that ClearCase/UCM can deal with. But how will this change in the future.
The Team Concert application may be technically improved to support more than 250 users. However, RTC is particularly suited for Agile developments and in my opinion a team of 250 users is about the maximum for an Agile project. A team in SCRUM should not exceed 10 people because stand-up meetings will take too long and people are not made to listen and remember the daily stories of more than 10 people. Having a SCRUM-of-SCRUMs of 10 people means that you cannot bundle more than 10 teams of 10 people, which makes 100 people.
Give or take a little larger teams, or smaller teams and 3-level SCRUM, I cannot image to exceed 250 people significantly.

RTC replacing ClearCase/UCM and Telelogic?

IBM now supports 3 SCM solutions: Rational ClearCase, Rational Team Concert and Telelogic Synergy. Given the number of users, RTC cannot replace ClearCase.
The most obvious direction is to use ClearCase or Synergy as the enterprise backbone for SCM data. All major deliveries (e.g. major milestones, releases) will be kept by the ClearCase database. RTC will then become the user's front-end to SCM.

The way this is going to work is through the connectors of RTC. RTC will combine SCM, build management and work item management, which more or less bundles the management of activities and their results. The data is kept in a RTC repository, the Jazz Team Server, using a rich data model; more rich than ClearCase or Synergy needs. Through the connectors, the rich data is synchronized with the enterprise SCM backbone (ClearCase / Synergy).

The RTC repository (Jazz Team Server) will contain only the data that is needed for the project, no more, no less. The project is started by extracting (through the connector) the needed data from ClearCase/UCM. Since UCM supports streams and baselines similar the RTC, there is an easy match to the new project's stream definition, especially if the new project is a successor of an old project that delivered the data from RTC to ClearCase/UCM in the first place.
When the project is run it is synchronized with the ClearCase/UCM backbone system through the connector, at the events as defined for the company (e.g. hourly).
And finally, when the project ends the RTC environment is synced with ClearCase/UCM and the RTC environment can be removed.

This way, RTC will become the high performance, high features, integrated project front-end while ClearCase (and other enterprise systems, e.g. a planning system, a financial system, HRM systems) become the enterprise backend system for all current and historical data.

ClearCase and the Jazz Team Server

If RTC is the project's front-end and ClearCase is the enterprise SCM back-end through the connectors, then integration with any other SCM tool has the same (dis)advantages as using ClearCase as back-end SCM system. So it will be a matter of time until the competition has developed connectors. How will Rational safeguard its competitive position with ClearCase then?

I have heard that RTC and ClearCase will be integrated more directly. ClearCase (and many other Rational tools) will move towards the Jazz Team Server as the data repository. Using the data model of Rational Team Concert, there will be a more efficient synchronization between RTC and ClearCase than through connectors. This will be a significant advantage to the competition. And the competition will not move to Jazz Team Server integration because that creates a too tight dependency on IBM Rational, so they will stick to the connectors. That's pretty smart of IBM Rational!

ClearCase and Eclipse

The ClearCase Remote Client (CCRC) is implemented on Eclipse, allowing it to run in a single user environment in coexistence with other applications on Eclipse. Through Eclipse, the need for platform dependent clients (Windows, Linux) is removed since Eclipse takes care of platform dependencies.
The native ClearCase clients will move towards Eclipse. In fact, the CCRC is going to be enriched with ClearCase functions, not only to enrich the remote client functionality but ultimately to replace the native ClearCase clients. In short, CCRC will become the one and only ClearCase client.

And through the integration of all Rational products in the Eclipse environment, these applications will not only look-and-feel integrated - even if they are just separate applications within the same environment - but they also can evolve into a truely integration environment. And this is precisely what is happening in the Rational Team Concert, where different functions (not necessary different applications) are integrated into a collaborating set.

Where does it all come together?

RTC is built upon Jazz to provide the collaboration functions (instant messaging, hyperlinking, dashboard creation, etcetera). Jazz is built upon Eclipse to provide the UI and platform independence. Jazz is also built on the Jazz Team Server to unify all data, and Team Concert defines a rich data model to unify different data models.
The connectors of RTC allow synchronization with back-end applications in a controlled manner, possibly foreign applications. They also allow existing Rational tools to be connected as "foreign" applications to eventually integrate with the Jazz Team Server to high performance, high functionality integration.
The Jazz Team Server serves as intelligent cache between the back-end and the front-end.

Will everything become a plug-in?

One of the most persisting problems of software development applications for customers is the integration of applications that are not integrated by the vendor. Through the concept of connectors, external applications will be able to integrate simply by developing their own connector. However, connectors are not able to extend the data model of RTC.

So yes, all applications will be able to become a "plug-in" and fade to be background of the user experience, but only if IBM Rational allows them to - or if another application vendor will make an Team Concert-like application.

Won't IBM Rational lose ground?

IBM Rational will be the conductor of the orchestra to determine the direction of the (Rational Team) Concert. If customers want full integration, they will depend on IBM.

In addition, IBM Rational will be able to develop applications more rapidly than the competition that integrates with RTC for a number of reasons. First, they will be determine how the data model will look like and they can mold the data model to optimize integration with Rational tools. Secondly, they are much earlier than the competition because they can make use of the extended data model before it is released to the market. Thirdly, they can better integrate with or without connectors because they have all the internals information available.

And finally, through the above mentioned advantages IBM Rational will be able to bring higher quality integrations to the market at an earlier stage than the competition. The counterside of it all will be: will the customer be willing to pay for it, or rather choose for later, less functional but significantly cheaper - possibly free - alternatives. If IBM Rational will be too expensive, it is likely that an open source alternative of Rational Team Concert will emerge (just like Linux as an alternative of UNIX).

Why SCM is not sexy, and SCM-ers are nerds

2008-09-22T14:41:00.010+02:00

Software development is inherently difficult. One of the reasons is that computers are inherently stupid and persistent in doing the same thing over and over again. Computers do exactly what they are told (programmed) to do, regardless of whether that is what you expect them to do. They are not human! To make computers do what you expect them to do, you need to be very meticulous and persisting in telling them what to do and how to do it.

Software configuration management is also inherently difficult. One of the reasons is that people are inherently clever and flexible in doing the things differently every time. People do what they think they must do, regardless of whether that is what you expect them to do. They are not computers! To make people do what you expect them to do, you need to be very convincing and careful in telling them what to do and how to do it.
Another reason is that software configuration management has a lot to do with computer systems, which are inherently stupid and persistent. You need to be very meticulous and persisting in telling them what to do and how to do it.

Try being meticulous and persisting in telling people what to do and the effect will be exactly opposite of what you might expect: resistance against your attempts to convince them of anything.

"computers cannot be convinced and people cannot be programmed"

A software configuration manager needs to be blessed with both talents to be really successful in SCM. But these skills are almost opposites, so the combination of both in a single person is rare.
Many SCM-ers like writing scripts, setting up and adjusting SCM tools and processes, performing software integrations and builds reporting results on websites and tuning systems performs and interactions with other systems. These SCM-ers are systems oriented, skilled with abstraction and logic. If they are good are likely to become the technical nerds of an organization.
Other SCM-ers like working with people, communicating, coaching, leading, defining strategies, giving trainings and presentations, coordinating the work in projects and process improvements. These SCM-ers are people oriented, skilled with social intelligence. If they are good they are likely to become the inspirator to bring the organization on a higher professional level. This group of SCM-ers is considerably smaller since they are likely to move on to other - more respected and better payed - jobs.
And finally, there is the extremely small group of SCM-ers with skills at both ends of the spectrum. They have a large interests in systems, structure, organization and tools, and at the same time a strong urge to inspire people, coach, guide and lead them.

Now if its true that the majority of the SCM-ers lack the necessary social skills to "sell" SCM and many people needing SCM lack the necessary technical skills to "buy" SCM (from these non-sellers), then its not so surprising that SCM is not seen as a popular profession.

Auditing is not a primary CM element

2008-07-31T11:16:00.001+02:00

We can distinguish two types of auditing in product development projects. Process auditing looks into the project to find evidence that the (agreed) processes have been followed. Data auditing looks into the project and product data to find evidence that the data is correct. In which category falls configuration auditing?

The configuration management activities follow a process. Compliance to the agreed CM processes can be audited. According to CMMI, the process quality assurance is a PPQA responsibility.

Configuration management controls configurations, which involves aspects like storage, distribution and retrieval, status and promotions, traceability of changes, visibility of dependencies, etcetera. Compliance to the agreed CM definitions (storage locations, distribution databases, data reference links and other metadata) can also be audited by CM. But if non-compliances are the result of process deviations, it may be more effective to audit the process (by PPQA).

And finally, the correct content of configurations must be assured. This can be audited, which is usually called a baseline audit. According to the NASA, a "baseline audit verifies that a configuration item, or a collection of configuration items that make up a baseline, conforms to the documentation that describes it" and should be done by CM. However it is part of product quality assurance and therefore the auditing should be the responsibility of PPQA.

How much does that leave for CM audit? Not much!
Therefore, there is no good reason to consider auditing a primary element of CM. Of course, CM people may and often will assist PPQA people with executing the audits, in particular to find evidence (e.g. configuration records and configuration items). In this respect I agree with Anne Mette Hass in her book Configuration Management Principles and Practices that auditing is not part of CM.

Identification is not a primary CM element

2008-07-30T08:56:00.008+02:00

Although it is generally accepted that Configuration Identification is a basic element of Configuration Management (CM), I don't agree that is should be. Why not?

The core of CM is control of configurations. To know what configurations we are controlling, we need to identify them. To avoid confusing one configuration for another, we need to uniquely identify them. Equal configurations should not be identified differently. As you see, CM is interested in unique identification, but how the identification looks like is not relevant, as long is it is a uniquely. Of course we need naming conventions, but how it looks like depends on the requirements for humans, automation or (CM) tools.
As such configuration identification is a secondary requirement for CM, not a primary element. The identification process does not even need to be part of the CM discipline, in which case CM is a user of identifiers, just like most other people in a project, but with a different purpose than other people.

Identification and naming conventions
An important implication is that when using a version control tool or a CM tool - I assume you understand the difference, but for now that's irrelevant - the unique identification may be left to the tool. This often results in unreadable object identifiers (e.g. 23987sg2b.38h830okdh34.8827481) but this is sufficient for CM. Even if you do CM by hand, you may just keep a list of sequential numbers.

In practice it is more convenient to have human-readable identifiers such as file names or document titles (or document identifiers) and/or to have identifiers that ease automation (scripting). Also it is often practical to put semantic (meta-)information in the identifier, such as a file type or a component identification. Because identification is not primary requirement for CM, the definition of naming conventions does not have to be a primary responsibility of CM people. You may document it in the configuration management plan (CMP), you may assist in the definition of a naming convention, your may be involved in auditing the compliance to the naming convention and if you are responsible for automation/scripting you may have their own naming requirements, but ultimately you shouldn't really care (as long as identification is unique).

Identification of everything?
Another reason for not considering identification as a basic element of CM is that not every identification should be the responsibility of CM. In principle, only the configurations that are under configuration control need to be identified for CM - note the different between "for CM" and "by CM". Some identifiers are an attribute value without identifying a configuration. Attribute values are for example enumerated values that are used on forms or documents, database identifiers (e.g. PRCR numbers) or just names (e.g. person names, product family names). In practice the distinction between an attribute value and a configuration is not always clear.

So what?
The reason that this is important is that CM is often held responsible for naming conventions and for identification. Commercial names are the responsibility of Marketing or Product Management. Identification of a certain technology used in the product is the responsibility of Engineering. Identification of production lots is a responsibility of Logistics. Not everything that has to do with identification should be considered a CM responsibility. In fact, CM is not really interested in identification as long as configurations can be controlled properly.

International Certified Configuration Manager

2008-01-06T08:37:00.000+01:00

The international Certified Configuration Manager association (iNTCCM) is founded in March 2006, with the objective of setting the standard for professionals in configuration management. Recently, I joined the iNTCCM association as a member.

How is hardware CM different from software CM

2007-12-09T22:21:00.000+01:00

The last few weeks I have been more involved in hardware CM, or more specifically hardware CM for IC (chip) development. The design process for a chip if very similar to the design process of software.
To design an analogue chip, you first make a model the electronic circuits using an modeling tool where you connect signal and power lines between standard components. This model goes into a simulator where you "test" your design. For a digital chip, modeling is even more similar to software development: you write code using a programming language. A code checker is then able to calculate the output bits based on the input bits. So in both cases, you create source files to describe the system behavior and you run a build to check the code or model, and generate files needed to feed the (chip) fab. The different between hardware (chips) and software is what happens with the build result.

So I would expect that CM for the design process of chips would be similar or even identical to the design process of software. Well, in my present experience it is not! CM for chip design is as we did it for software in the 80-ies of the previous century, which is 25 years ago. There is hardly any parallel development and the only controlled versions are the current versions (/main/latest) and the baselines (tagged versions).

From a software perspective, absence of parallel development is hard to imagine. How come that chip design can do without, and still develop multiple product variants at the same time? The answer is: reusing block designs. A chip consists of a combination of (more or less) standard blocks. These can be high level blocks (e.g. an ADC, or a Bluetooth controller) or low level blocks (e.g. a transistor, an amplifier or a FIFO). These blocks are used to compose a chip design. The challenge is to combine as many blocks as possible, on a chip as small as possible, with the best performance as possible (e.g. low noice levels, minimum power dissipation, largest temperature range, etc.). The cost of a chip is determined by the size, but the market value is determined by the functionality (maximum number of blocks) and the quality (best performance).
One of the biggest challenges of chip design is how to place and connect the blocks and get still get the chip within spec. This is a 3-D problem - because a chip consists of multiple layers - and almost all changes in the design has impact on the complete chip. Therefore, you cannot change one part of the chip in one team, which another team works on another part, and therefore there is not much parallel development.

Development of those reusable blocks (e.g. making a smaller ADC using less power and with better performance) is done separately from the chip development. These blocks are called IP blocks. The designers of an IP block don't really care about placement and connection of the block on the chip; they care about the internals of the block, making the design possible. The only reason they care about other blocks on the (test) chips is interference: for example, what is the effect if we place the ADC next to a power management block?
Since almost all changes within an IP block have impact on the whole block, there is little use to designing one part of the block in parallel with another part of the same block. And if that is feasible at all, it is more useful to make them separate IP blocks which can be used (and designed) independently.

Now let's go back to configuration management. We have seen that chip design and IP block design have little use for parallel development. So CM does not need branching or streaming. If there is a need for (for instance) product variants, it is easy enough to just design them as separate product types, reusing the ideas of one product type for the other one. It may even be sensible to design them sequentially where the first product type takes several months to design and the next one only a few weeks after it.
If we look at software development, we may notice that the use of standard blocks is not "common practice". Designing a software system involves (1) designing the software blocks and (2) integrating them into a system. So what chip design does in two separated processes (usually also separate projects), is combined in a software project. This is possible because in software you have infinitely more freedom in interconnecting "blocks" and infinitely higher speed of changing the characteristics of a blocks. If a software designer has a block that "almost" fits in a system, it is often cheaper to change to block itself than to change the system around it to make it fit. In a modular design changing the block internally has less impact on the whole system than changing the environment of the block. And therefore, software blocks are often developed in separate teams that work simultaneously, using a (more a less) fixed interconnection called the interface architecture. Variants of blocks can - and do - exist simultaneously within the same system, where at compile-time, link-time, install-time or run-time is it decided which variant of a block is actually used.

The simultaneous and concurrent existence and design of software blocks, and the dynamics of integrating those blocks into a system is so much more complex than for chip design, that it requires a lot more complex configuration management approach. The SCM approach requires parallel development in branches and streams, both on block level and system level. It also requires a lot more flexibility of dealing with integration scenarios, variants and circumstantial differences. And last but not least, chip designs require an (expensive) manufacturing process that is very expensive to change once it is established, while software is the final product after the build. Consequently, the dynamics of change in software systems is much higher then for chip designs.

In summary I would say that although the design processes for chip design and software design look very similar, the configuration management requirements are of completely different magnitudes.

CM Platform in the Netherlands

2007-10-31T07:21:00.000+01:00

In the Netherlands, there is a new configuration management initiative called CM Platform [no link to a website yet]. The initiators are from Thales and KPN. Although it is still in its early stages of exploration, there is a clear need for more and better collaboration and sharing of the configuration management knowledge.

Other initiatives in the Netherlands are:

Dutch Rational User Group (HRUG), initiated by Bosch Security Systems and TOPIC Embedded Systems
CM workshop organized by TOPIC Embedded Systems and Philips Applied Technologies

Software-as-a-Service (SaaS) for CM systems

2007-10-30T21:33:00.000+01:00

In a podcast on IBM developerWorks, Dave Michell explains about Software as a Service (Saas):

the customer does not take ownership of the software, but they're going to rent this solution in a subscription model, and it's delivered remotely. And that's very different from the ASP model. In the ASP model, or the application hosting model, what the customer is doing is they're buying the software.
[...]
In the Software as a Service model, again, the customer does not own the software. They subscribe to an offering and they buy that offering in a subscription model per user per month. So there's no software purchase to be made.

And the other key point here is in the Software as a Service model, the customer really has no say over what the infrastructure is. They don't get to decide what the hardware is or the middleware or the database — and more to the point, they don't really care.

So in the SaaS model, the customer says "I want to buy that application functionality. I'm willing to pay this much per user per month," usually is their typical model. "And the service-level agreement meets my needs. So I'm going to acquire that application that way."

Considering a configuration management system, such as ClearCase, many customers struggle with configuring the system for optimal performance, setting up and configuring servers, network and client parameters. In many cases, the users don't really care whether it is ClearCase, Synergy or Subversion behind the scenes, as long as that can do version control, baselining (or labeling or tagging), parallel development (or branching or streaming), delivery, rebasing, releasing, status promotion, structuring, setting attributes, and all the other CM stuff. Users don't care about sufficient licenses, disk space, replication across sites and other IT issues; they just want the system to be available and to work properly to their needs.

So, the CM system seems a perfect candidate to be deployed as Software as a Service. Even more, if the CM service is offered as a Web 2.0 application, the internet will be the platform allowing local and global accessibility.

If in addition there would be a standard set of CM service features, the CM back-end could be supported by just any CM vendor that complies with this standard. The front-end could even be of a different vendor or proprietary to the customer, e.g. as a dedicated integration with other systems. Customers could then focus more on the tool-vendor that suites best with their organizational and IT needs, and users could better focus on dealing with true configuration management issues, rather than being hampered by infrastructure and IT issues.

Why wouldn't a product like ClearCase be offered an SaaS model, if IBM is such a promotor of SaaS?

2007-10-27T09:04:00.000+02:00

There are many definitions of configuration management, most of them containing four basic elements: identification, control, status accounting and auditing. Although formally correct, the translation into practice is far from easy for many organizations. I wonder why this is...

Let's have a look at a car for a minute. From a user perspective, a car is a way of transportation from point A to point B. From a technical perspective, a car is an system where you can put people and luggage in and that allows a controlled way of acceleration, deceleration and steering. Given the technical view, there is no way to define that a car brings you from any particular point to another point.
Now let's go back to configuration management. In fact, identification, control, status accounting and auditing are the technical view on CM. But what is the user view on CM? Why do we need CM?

I think that the main and possibly only reason why we need CM is that we need to communicate and share. The effectiveness of communication depends on the integrity of the information we communicate and the effectiveness of sharing depends on the integrity of the objects we share (work products). If the information and work products would be static, a (simple) library or stocking system would be enough. But in practice the information and work products are not static; they are evolving in a planned way (if the planning is followed). The integrity (or validity) of the information and work products also constantly changes.

Now because the information and work products are constantly changing, we need some guidance in determining what is correct and what is not. That's why we need concepts like streaming or branching to facilitate parallel development, we need the concept of tagging, labeling or baselining to determine the status of a particular configuration, we need the concept of promotion to visualize the state of evolution.

Communication of information, sharing of work products, and assuring the integrity of the whole while it is constantly changing, is the main challenge of configuration management. Hopefully, it is easier to understand configuration management from this angle than from its formal definition.

Is CM about maximizing change or about minimizing change?

2007-10-12T22:04:00.000+02:00

"Not every change is an improvement, but an improvement is always a change"

Configuration management is about managing change, assuring the integrity of the business assets during their lifecycle. This implies that the work products of a project are protected against loss or damage. Every change is a risk of introducing bugs, damaging the existing functionality or degrading the system's performance. A good way to assure the integrity is to minimize the amount of change: if you don't change it, you can't break it.
This is precisely what a CCB (Change Control Board) is doing. Every change request is discussed and only when the business value of the change is high enough, the change is accepted for implementation. Other changes are rejected. Thus, the system will undergo minimum change and minimum risk of degradation. A positive side-effect is that this approach leads to minimizing costs and to minimizing time-to-market: if you don't change much, it does not cost must money or time.

On the other hand, especially in a consumer market of retail or professional products such as mobile phones, audio and video equipment, medical diagnostics and treatment systems, transportation or manufacturing, the competition is tough. The game here is to maximize the amount of functionality, to maximize the level of quality, but at the same time to minimize the costs and to minimize the time-to-market.

Now what should configuration management aim for: minimizing change or maximizing change?

Well, in fact the answer is quite simple: that's not up to configuration management. Regardless of the amount of change being high or low, configuration management should manage the work products and their changes, assuring their integrity. The decision to minimize or maximize change is a business decision. This may be different for different businesses, but also for different projects within the same business. It may even be different depending on the time of the year (e.g. Christmas season). But of course, the CM approach must be different in both cases, so it must be aware of the business situation.

This implies that there is no single best CM approach; there is no one-fits-all solution. To find a common solution, we need to focus on the one thing that both have in common: change will happen! Any change may be an improvement or a degradation (or both). We must avoid that changes that we don't want are slipping through to the customer, and we must assure that changes we do want are actually brought to the customer, with quality and in time.
This requires at least a proper level of visibility, which bring us to the four pillars of CM:

What changes do we want, and what changes don't we want? (Configuration identification)
What solutions do we have, and which ones don't we have? (Configuration control)
At what stage is every change? (Configuration Status Accounting)
Are we sure about that? (Configuration auditing)

The most important job of configuration management is to achieve a maximum speed for propagating desired changes, for instance storage when the change is available, promotion when the promotion criteria (e.g. quality criteria) are met, distribution to the teams for the next processing step (e.g. verification) and communication for visibility (e.g. to enable project monitoring and control). But at the same time configuration management is to detect undesired changes as soon as possible (preferably before someone is working on them), and stop the propagation of solutions of undesired changes when they slip through or when we change our minds about desired and undesired changes.

So it is always a balance between speed and control, between volume and quality, between maximizing and minimizing change. Moreover, it is a constantly change balance too, which makes the profession of Configuration Management a challenging and interesting one!

Our iceberg is melting

2007-10-07T18:54:00.000+02:00

Last week I was one of the speakers at the 4th CM workshop organized by TOPIC Embedded Systems and Philips Applied Technologies. I spoke about how Web 2.0 technology will have its (change) effect on configuration management. As a speaker, we received a nice presents, a book by John Kotter and Enter Rathgeber:

Our Iceberg is Melting

Most of you know how I hate reading books. So at first I forgot about the book, leaving it in my suitcase for over a week. Today I started reading it, and finishing it! And I love it!
It reminds me of the book Peopleware by DeMarco and Lister which I also read in a single breath, and loved. Peopleware and Our Iceberg is Melting are the only books I read in the last decade that I absolutely love - and finished.

Now you probably wonder what is so special about these books. Well, first of all you should read them yourself. Both books are about people, in case of the Iceberg in the form of a fable with penguins. I had no difficulty whatsoever to project the story on a real life situation at work and real people from work.
Quite often I encounter people like Fred, Alice, the Professor, Buddy and of course NoNo. Unfortunately, I hardly ever encounter talents like Louis, a respected senior manager who knows how to manage how to manage people.

Anyway, take a look at The Iceberg is Melting, it is worth it.

Lean configuration management

2007-10-04T21:01:00.000+02:00

Jens Norin has written een article about Lean configuration management. There is a lot that I disagree with, but it also gives a lot of things to think about.

CM certification - sense or nonsese

2007-09-27T07:05:00.000+02:00

During a Configuration Management workshop in Mierlo, a little town near Eindhoven in the Netherlands, I had an interesting discussion about CM certification. The concept of certification is simple: if you comply with an amount of selection criteria, you get your certificate.

The discussion was what the added value is of CM certification. In my view, the may be - at least - two reasons why you need certification:

The distinction between professional and amateurs is difficult to make
The industry is using certification as a selection method

Currently, there is no common, generally accepted, understanding of what a configuration manager is. So if a certification institute defines certain rules and criteria for certification, it is arbitrary. There will be lots of good CM-ers that will fail and bad CM-ers that will pass, depending on whether your knowledge and work experience complies with those criteria. The result will be that within the crowd of certified CM-ers there will be good and bad ones, and within the crowd of non-certified CM-ers too.
In addition, the community of CM-ers is a small world. Bad CM-ers are easy to pick, and if someone is completely unknown within the CM community, it might be a reason to some extra screening when he or she applies for an assignment as a configuration manager.

So my argument was that the added value of certification of individuals within the CM world is too small. This does not justify the investments to set up a certification institution, not does it justify the individual investments to get certified.

I think CM certification is nonsense. It is useless to strive for a certificate unless it clearly boosts my career if I do, or damage my career if I don't.

Some links:
Institute of Configuration Management
International Certified Configuration Manager

IBM developerWorks CM space and wiki

2007-07-11T23:06:00.000+02:00

Recently, I have created a Configuration Management space with an underlying Configuration Management wiki on IBM developerWorks. Initial focus will be on IBM products (ClearCase, ClearQuest and UCM) and on CM concepts and practices. Later, it is my intention to extend it to other CM products too. The space and wiki are an extension to the existing discussion forums on dW.

The content is still in its initial stages, so bear with me to let it grow. For that purpose I am still looking for co-editors who are willing to put more content to it. Although wiki's are intended for open collaboration, I want to be careful with making it completely open for modification to the world to assure proper structure and quality.

For new events or other news and changes on the CM space portal, feel free to contact me.

Collaboration technology is coming

2007-07-07T08:19:00.000+02:00

Recently, I attended the IBM Rational Software Development Conference (RSDC2007) in Orlando, Florida. Apart from the typical presentations about the products, there was a lot of attention for Organizationally Distributed Development, or Globally Distributed Development (GDD). ODD/GDD is about crossing the organizational boundaries, which many people find scary.

At the RSDC they showed a prototype of a product called Team Concert, a tool to support collaboration between people to build software. It is based on the Jazz technology, which is

Jazz is a joint project between IBM Rational and IBM Research to build a scalable, extensible team collaboration platform for seamlessly integrating tasks across the software lifecycle.

New and exciting is that the Team Concert product is developed as a commercial product in an open source manner - see the press annoucement. People from the global community can join in to the development team. Thus, the project is deploying the potential of the global community.

Another exiting thing is that the Team Concert is a collaboration product, creating full transparancy and integration of technical and control information. And since this is a collaboration project, they use (pre-released) versions of Team Concert to support the development (globally distributed). So they are using the product that they are making.

But this is not the only thing that illustrates that IBM is taking collaboration technology seriously. On IBM developerWorks they have introduced spaces and wikis, next to the discussion forums that have existed for many years. For company communication this is not new, but what is new is that they also allow non-IBM people from the user community to create a space. The Configuration Management space is the first one.

Coincidently, at NXP Semiconductors (formerly Philips Semiconductors) there is an initiative to create a Common Collaborative Core (C3), a set of applications (e.g. wikis, forums, website, IM) to support the - internal - community with collaboration, sharing and building knowledge and competence. NXP happens to be the customer that I am assigned to currently.

Apparently, both NXP and IBM recognize the same thing - unleash the power of the mass instead of trying to build competences with the (small) recruited crew.

Transparent collaboration across organizational and geographic boundaries is a necessity to survive the ever growing technological and organizational complexity.

Nightmare of component based development (4)

2007-05-21T23:47:00.000+02:00

It has been a while since I posted about the nightmare of component based development. But, I promised to revisit, so here is another one.

Component based development may be a blessing to some product developments, but it can also be a nightmare to others. In part 1, I discussed the problems of finding a stable baseline as a reference for new development when developing multiple components simultaneously. Part 2 discussed the issue of reducing scale which resulted in both early and late integration. Part 3 focussed on the issue of ownership when developing multiple incarnations of a component simultaneously.

As the title says, component based development can be a nightmare. Complexity of systems and products continuously increase, and functionality originally designed and marketed as separate products, is being integrated. For example a camera in a mobile phone, GSP tracking in car navigation systems, medical monitoring in watch integrated with cellular communication, and much more. What originally was designed as a product becomes a component within other products. Components may be split or merged into other components. And what originally was marketing by company A may becomes an integral part of a product line for company B.

Even though component based development may be a nightmare - if not done properly, the need for componentization and flexibility with components is growing. It seems unavoidable that some day we have to face the problems of component based development anyway, whether we want or not. And this day will probably be sooner than we may expect.

Trying to integrate different products and components, that were designed with different architectures, is a challenge by itself. If there is time to do it properly, we may come with a proper solution, a new architecture. But there is never enough time to do it properly, so we need a way to at least control it in a proper way. It may even become worse when the need for integrating existing products and components exceed the need for new functionality. That may lead to a completely different approach to systems design and may redefine the term "reengineering".

Now what can we do?
Well, we cannot make a chaos-beyond-control first and then hope for a generic solution to regain control over the chaos. We don't have time to do that because the competition will beat us in the meantime. it must be a controlled evolutionary path.
This means that configuration management will become more important to control product development, and it may well become the most important control discipline. It will not only control the work products (inputs, intermediate work products and outputs), but also strategic roadmaps information and the information and knowledge of the company that is required for product development. It will be too difficult and too extensive to oversee all information by a single person or even by a team of people.

The "art of integration" will be a combination of product architecture and configuration (and knowledge) management, and these two will become even inseparable and indistinguishable.
Configuration management may even become more an integration of product architecture and project architecture (or more general, the architecture of an organization and its processes).

Writing a book like developing software

2007-04-20T22:13:00.000+02:00

In the article Writing a book is like developing software, Roy Osherove compares writing a book with writing software. Now let's assume that we would write books like we develop software.

Most books are written by a single author. Take for instance The Lord of the Rings by J.R.R. Tolkien. Suppose we would take up the assignment to write a sequel of this bestseller, but develop it like a software product. Suppose some of the requirements are

It must appear on the market in English, Spanish and Russian simultaneously
It must appear before Christmas 2007
It must equal or exceed the success of the current books

Given the short timeframe and the limited available of talented and experienced writers (scarce resources), we decide to write the book in as multisite project. We set up and English team in the America, a Spanish team in Europe and a Russian team in Asia. Given the global distribution, we can work round the clock.
To reduce intercontinental communication across timezones, we will assign different parts of the book to each team. Each team will write in its native language to assure the highest quality of writing. When one team finishes a part (or a preliminary version of it), it will be sent to the other teams for verification and translation.

The verification process will compare the story with the requirements. Which requirements? How do you make "exceed a previous success" SMART, if you cannot sell the book before finishing it? This is a job for marketing. They have to verify if the book will sell good enough.

We were talking about assigning parts to different teams. Which parts? If we divide the book into chapters, we can assign a chapter to a team. Which chapters will we have if we don't have the story yet? But the story is to-be-developed by the team. To divide into chapters we need the overall plot, in abstract form. But, who is responsible for the overall plot?

Okay, division into chapters seems to be a bad idea. Let's divide into characters (persons in the story), and assign different characters to each team. May be the cultural background of each team may even be an advantage for writing and for the overall result. But how can you write a story of characters in separate teams, if there is not plot that connects those characters? Characters need to interact in the story. Furthermore, different teams will be writing simultaneously on the same part of the story. So we need to integrate parallel updates, and we need to review the different story elements before integrating them.

Another issue is that during the story, we build up a history. If for example two characters meet in the beginning of the book and become friends, they cannot be complete strangers and enemies lateron.

Sigh! We need a story architecture that defines the development of characters and the development of time (history) across the whole book. It also defines the characteristics of the characters, the landscapes they visit, timing constraints (e.g. you cannot be at two different places in the same timeframe).

And we need configuration management to assure that the correct versions are reviewed, verified and translated. Especially translation is a dangerous one: if you translate an old Spanish section to Russian, the English and Spanish teams will not discover it because they cannot read Russian, except the people who translate from Russian. But why would a Spanish translator be bothered with reading a section that was originally in Spanish? So, CM must assure correct version and status handling.

I can go on and on, but probably you have lost faith that a book written this way will (1) be ready before Christmas 2007 and (2) exceed the success of The Lord of Rings. Yet, many companies develop their (software) products in multisite projects, with teams in America (US, Canada), Europe (UK, France, Germany, the Netherlands), Asia (India, China, Singapore), and without proper configuration management - except branched version storage and multisite replication.

Is multisite book-writing a good idea? And multisite software development?

Kathy Sierra blog - excellent!

2007-04-02T22:35:00.000+02:00

The blog of Kathy Sierra is really a recommended read when you want to get excellent insights in user community building and how this influences user's experience and perspectives.

For example, her blog entry about ultra-fast change explains how extremely frequent updates (of a product or service) help create user satisfaction because the user doesn't even get enough time to get upset about a broken feature. Due to the fast pace of changes, the fix or rollback is already available before anyone gets really upset about it. That's an enormous reassurance to the users.

Another one I like is Creativity on Speed. It explains how the best creativity comes forward when people have the least time to be creative. She is not talking about unrealistic deadlines (which kills creativity) but about needing a solution and needing it quickly. Under this pressure, people tend to rely more on their intuition and other subconscious parts of the brain, rather than rationalizing and trying to link logically.

I haven't read all, and I don't like it all, but her blog struck me.

Deliverable planning and control

2007-03-30T22:40:00.000+02:00

For many people Configuration Management is little more than controlling the versioned storage of work products, sometimes extended with Change Control which is little more than controlling change requests and problem reports. But both boil down to something like an sophisticated database with a sophisticated tool, sometimes not even sophisticated.

But the real added value of Configuration Management is that it helps manage and control the project. Let's have a look of a project in general first. In short every project is an enterprise, a journey, to establish a particular result of a particular quality, within the limits of particular resource constraints (typically money, time, people, technology, methodology, etcetera).

Every project starts with planning. Planning the result means expressing the results in items that will be delivered - if the project is executed according to the plan. Those items need to be identified (Configuration Identification), controlled (Configuration Control) and must be of a certain quality level expressed by a status (Configuration Status Accounting). So the first order planning of - the result of - a project already involves configuration management.
Secondly, these resulting items don't fall out of the sky; they need to be developed. So every item will require at least one task in the planning that produces the item. Some tasks may even product multiple items, that's OK. But every task needs input. So there we have a second order of configuration items.
Thirdly, these second order items need to be produced also, or they are inputs to the project from an external source. These can be requirement definitions, architectural definitions or even complete subsystem implementations from another project or a previous project.

Anyway, project planning strongly involves configuration planning, which is a responsibility of configuration management. In other words, configuration management is part of project management, at least during planning.

After the planning has been built up, which involves a lot of other things to be planned as well, the project is executed according to the plan. The tasks are being executed and the (planned) items are being produced as the result of the tasks. Some items may be produced iteratively, thus producing multiple versions of it. Anyway, these items (i.e. the versions) are stored in the CM system and status is assigned to indicate the progress of the item (how far is it "ready"? which is a quality attribute) and the maturity (how good is it? which also is a quality attribute). But controlling the versions and their status - and even the status of integrated items, which is a different thing than the status of the individual parts. This is all Configuration Management, which contributes to the Project Monitoring and Control of the project.

All I am saying is that the deliverable planning and tracking processes are both part of Configuration Management and of Project Management. That's why we should not consider CM in terms of the tools, databases, licensing issues, disk or network performance issues, branching issues, access control, etc. Those issues are not configuration management, but they are IT systems management issues. Configuration management is a project management discipline that is concerned with managing the physical work products of the project.

Behind Closed Doors

2007-03-22T07:35:00.001+01:00

Although I don't really like reading books, I started in Behind Closed Doors of Johanna Rothman and Esther Derby. It really is not a book about management, but about working with people as a manager. Easy readable and for a slow reader as I am - especially with the distractions that I have while reading - my progress is reasonably fast.

The previous book I read so easily - and finished - is Peopleware by DeMarco, a classic in management books.

Both books are about people and working with people.

Update 15/3/2007:
I have read the second chapter. It certainly is not my favorite - in other words - I don't like it. It's about matching roles and people. It assumes an amount of freedom to mix and match that - at least in my work environment - seldom exists.

Update 18/3/2007:
The third chapter about building your team started familiar with jelling teams. I immediately felt the connection with Peopleware. It was convincing until the subject of feedback was touched. Especially ending the chapter with the option of firing someone ruins the whole atmosphere needed to build a team. Overall, I was left with a very disappointed feeling.

Update 13/4/2007:
The chapter about managing day by day was about setting personal goals. A great deal of the people I encounter, especially bosses, talk about setting personal goals. "Where do you want to be in 5 years time?" or "What do you want to have finished by then end of the week?" It is a clear chapter (for those people) and may be an eye-opener for many. But for me, living to a goal has always been a struggle. I'd rather be focussed to a direction and a vision, instead of a goal.

Update 14/4/2007:
The chapter about discovering lurking problems is not about discovering lurking problems. It's about discovering the difference between an individual problem (for an individual person or an individual team) or a group problem that exceeds the scope of control of the individual (person or team). It is well written, from a practical angle rather than the theory. I liked it very much, as it appeals to many situation I encounter in my work.

Update 14/4/2007:
Building capablities is the chapter I am still reading. This is one of my favorite chapters as it addresses the human side of management, such as trust and appreciation. I find it very interesting what makes people "tick" and how to really connect to people as individuals. I have not finished the chapter yet, but I think it may be the best chapter in the book.

Update 27/5/2007:
It's now one and a half months later than the previous update, and I finished the book. Looking back, I wasn't thrilled about it as I hoped I would be. The style did not grab me like Peopleware did, and the secrets are nothing more than common sense in dealing with people, as a manager. To me it's a no-buyer, but fortunately I got it for free.