Configuration management: Concepts and capabilities

Complexity is one of the biggest challenges facing software and systems engineering teams today. Software applications are built by integrating many software components, each with associated artifacts such as requirements, designs, source code, and test plans. Teams often work on several versions of an application at the same time. Changes to specific artifacts must be incorporated in a controlled manner to prevent errors and maximize reuse.

Similarly, system engineers design products that are built from hundreds or even thousands of individual components, which can range from physical objects to software. Related products are often produced from a common base or architecture and grouped into a product line.

Product lines can contain dozens of closely related products, also called product variants. A variant is identified by a specific set of characteristics that distinguish it from other artifacts or products in the product line. And behind each product variant is a specific set of artifacts, such as the requirements, designs, source code, and test plans that were used to formulate it.

Configuration management capabilities in the Rational® solution for Collaborative Lifecycle Management (CLM) help teams manage this complexity.

Before your team can use configuration management capabilities, an administrator must read the considerations before enabling configuration management, and then obtain an activation key:
  • For pilot environments, generate an activation key at
    Note: Configuration management capabilities of RM and QM, and global configuration management is an added service for IBM Collaborative Lifecycle Management on Cloud and IBM IoT Continuous Engineering on Cloud customer environments, and should only be enabled by the SaaS provider. Software configuration management (SCM) in CCM is included in Cloud offerings at no additional cost.
  • For production environments, discuss your plans with your IBM® Client representative or contact IBM Support.

See additional learning resources at the end of this topic.

Configuration management concepts

Teams use CLM tools to develop wide-ranging applications, such as banking software or medical devices. As part of the development process or engineering design, teams create a variety of artifacts, ranging from stakeholder and system requirements, to source code, to test plans and test cases.

A component represents physical or logical pieces of the software or system your team is working on. For example, you might create a component for a physical piece, such as a heart monitor, or a logical piece, such as the server. Each of these components can have several configurations.

In the CLM tools, you use configurations to group a set of versioned artifacts in a project area. Configurations commonly identify one version of each artifact in the set. For example, a team might group all the requirements for a component into a configuration, making it easier to identify and work with all the requirements associated with that component.

Image shows an example of a configuration, showing three artifacts, each with different versions

CLM tools use two types of configurations:
  • Streams are modifiable configurations of artifacts from one or more components. Team members deliver their changes to a stream when they want to make their changes visible to other team members.
  • Baselines are frozen configurations of artifacts (cannot be modified) from one or more components. Baselines are useful for enabling a team to work with a known configuration, or as an initial state for some new stream of work.

    IBM Rational Team Concert® makes a slightly different distinction for source control management (SCM). Baselines of components are the same, but snapshots represent a frozen state of a stream that contains component baselines.

Artifacts in a stream can be modified, and the stream always presents the artifact version that is currently selected by that stream (other streams or baselines can select other artifact versions). By maintaining the artifacts for a project in a stream, teams can share their work and ensure they are working with the artifact version that they need.

When the work on a set of artifacts in a stream is complete or has reached some milestone, you can create a baseline of that stream to capture the specific artifact versions selected by the stream at that time. The artifact versions in the baseline cannot be modified, nor can the set itself. In the future, the team can use the baseline to create a new stream for its work.

Configurations enable parallel development

New features in this release enable parallel development.

  • For software applications, the current stream might be used for the next version of the application or product while a new branched stream is used for the first maintenance fix pack. Changes in the maintenance stream can be delivered to the current stream, so the next release includes all changes from the maintenance fix pack. For many years systems and software development teams have used configuration management in this way to develop parallel releases.

    Image shows a baseline with two branched streams created from the baseline.

    To branch a stream, first create a baseline of it; then, create a new stream from that baseline

  • In a product line context, the initial stream might hold all artifacts associated with one product while the new stream holds the artifacts and versions associated with a new product variant under development. Several variants can exist at the same time. This is how teams manage versions and variants.

    Image shows a baseline with a stream for an initial product and a stream for a variant product

In the new stream, artifacts are reused by reference, rather than being copied. Only new or modified artifacts have versions unique to the new stream.

Assemble configurations to represent a specific version of a component or product

You can assemble configurations that contain other configurations from one or more CLM tools. Assembling configurations offers teams two main benefits:
  • Provides your team with a holistic view of the artifacts (requirements, test artifacts, source code) for a specific version of a component or product. The view enables your team to develop multiple versions of an application or product in parallel. As you work within and across CLM tools, you see only the artifacts relevant to the version of the component you are working on.
    Note: For more information about the technical vision for this capability, see the developerWorks® “Strategic reuse and product line engineering” paper at
  • Creates a hierarchical component structure that reflects the system under development and enables subsystems to be updated independently. By grouping multiple configurations from different tools, you can represent the artifacts associated with a complex and aggregated subsystem, such as an engine, or complex component-oriented applications.

    Image shows a configuration made up of a requirements configuration, a source code configuration, and a test configuration, with each configuration containing native artifacts

In CLM tools, you can create multiple components to represent pieces of your product or system. You can then create configurations of these components and contribute them to globally-managed configurations by using the Global Configuration Management (GCM) application. Globally-managed configurations are called global configurations to distinguish them from locally-managed configurations, or local configurations, created in components in CLM tools. Global configurations can contain global configurations, local configurations from CLM projects, or both. Local configurations contain artifacts from the CLM tool where they were created.

Image shows a global configuration, which contains other global configurations and local configurations

This release and the OASIS Open Services for Lifecycle Collaboration (OSLC) specification use the term “global configurations” to distinguish them from the local configurations that contain only artifacts. Any tool can contribute configurations to a global configuration if it supports the OSLC configuration management specification.

New capabilities in this release

Starting in CLM version 6.0, these significant enhancements to configuration management in and across CLM tools are available:
  • Improvements to the configuration management capabilities that were introduced in Rational DOORS® Next Generation with Configuration Management version 5.0
  • Introduction of configuration management capabilities in IBM Rational Quality Manager
  • Introduction of global configurations, which now offer the possibility of grouping configurations within and across tools

Until now, not all the CLM tools used configurations to group a set of versioned artifacts. For example, a team might group all the designs for a specific component into a configuration to make it easier to identify and work on the designs for that component. Although teams could access application or product information in different tools, and view progress and important data in Jazz™ dashboards, they could not assemble a view of all the artifacts used in an application or product from across all the CLM tools.

These enhancements help teams:
  • Work in parallel development streams
    • Create the components that teams need to represent the pieces of their project. Teams then work with specific versions of artifacts in the streams and baselines of each component
    • Create and reuse otherwise unrelated configurations of artifact versions, within or across tools
    • Start design and analysis for the next release while developers are still using the artifact versions they need for the current release
  • Incorporate changes to artifacts in an isolated environment; then, after they are approved, finalize and control where they are delivered. You can compare changes to see what has changed since an earlier milestone, or to see changes across streams. When you are ready, you can deliver your changes to the appropriate stream.
  • Link and navigate across tools.
  • Create cross-product baselines that capture the versions of artifacts at a particular milestone or in a specific product version or variant. When you select a baseline configuration you recreate your development environment. You can determine, for example, which type of artifact was the source of a defect reported by a customer: Is a requirement inaccurate? Did a test case miss an essential capability or misinterpret the requirement? Does the source code contain the defect?
  • Create a branch from an existing product or library of core assets to create a variant.

An example of configurations in practice

Suppose your team is building Version 2.0 of a medical device application or product. Your team's requirement configurations are in Rational DOORS Next Generation; the source code configurations are in Rational Team Concert; the test configurations are in Rational Quality Manager. Each CLM tool contributes a configuration (a stream with the correct artifacts) to Version 2.0. These local configurations together form a global configuration named Medical Device Version 2.0 (Image shows yellow star, which symbolizes the Medical Device Version 2.0 configuration, in the following image), which a configuration lead has assembled using the GCM application.

The following concepts are specific to the GCM application.

Image shows the Medical Device Version 2.0 configuration, which contains Requirements, Source code, and Test artifacts streams

As your team works on Version 2.0, team members realize that they need another variant to address unique regulatory requirements for a specific market, such as Europe (and potentially other markets as well). The team must also develop new code, and create test cases and plans.

The team creates a baseline of the Version 2.0 stream that contains the configurations and artifacts they will need, and then creates a stream from it for their new work, called Version 2.0.1 EU.

The team will work on both products in parallel.

The parallel stream is typically created by a team member with administrative privileges who is designated as a configuration lead. In this example, assume that you have been assigned those permissions.

  1. Before you can branch Version 2.0 to create the stream, you must create a baseline in the relevant CLM tool for each configuration that contributes to the Version 2.0 stream. Each baseline captures the artifact versions that the Version 2.0 stream is using. This example has the following baseline names:
    • Version 2.0 (requirements)
    • Version 2.0 (source code)
    • Version 2.0 (tests)

    Image shows streams from the contributing CLM tools, which are configurations

  2. Branch the Version 2.0 stream to create a stream across all three CLM tools for the team’s new variant work:
    1. In the global configuration application, copy the Version 2.0 stream and name it, such as Version 2.0 Milestone.
    2. In the Version 2.0 Milestone stream, replace the contributing streams with the baselines that you created in the CLM tools.
    3. Convert the Version 2.0 Milestone stream into a baseline. It is important to make it a baseline so you know which set of configurations to start with. The baseline freezes the milestone release but keeps the Version 2.0 stream open for more work.
    4. Create a stream from the Version 2.0 Milestone baseline and name it Version 2.0.1 EU. This action branches the stream so that you can start working on the EU variant.
  3. In each CLM tool, create streams from your baselines from Step 1. Remember that you created the baselines to freeze artifact versions, so you cannot modify them. You’ll want to modify some artifacts in these sets, so use the relevant CLM tool to create a stream from each baseline.

    Image shows the baseline from which to branch off into the new stream

  4. In the Version 2.0.1 EU stream, replace the baseline configurations with the new streams from the CLM tools.

    Image shows the Version 2.0.1 EU stream with the updated streams from the contributing CLM tools

Now the team can make the changes for Version 2.0.1. They update the necessary requirements, source code, and test cases, and then deliver the changes to the Version 2.0.1 stream.

Changes made in one stream are isolated and do not show up in the other stream. For example, if you change a requirement artifact in one of the streams contained in Version 2.0.1, the change is isolated from the other stream until you deliver your change.

Image shows the two isolated streams

As you use links to navigate to different products from a global configuration, you remain in the same context. This ensures that your work is completed in the correct stream, isolated from other streams and baselines.

At a significant milestone, such as the completion of a sprint, you can create a corresponding baseline from a global configuration to freeze the artifact versions. Use the baseline to start a new development stream or to base other work on, such as a fix pack. You create a new stream from that baseline.

By using the new capabilities in this release, your teams can reduce the complexity of parallel development, control and isolate delivery of changes, and understand how artifacts are grouped and used across application and product versions.

video icon Watch videos

CLM playlist channel
User Education channel

learn icon Learn more

CLM learning circle
Agile learning circle
Learning circles

ask icon Ask questions forum
developerWorks forums

support icon Get support

Support Portal
Deployment wiki
Support blog