SCM tools are not configuration management tools

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

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

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

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

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

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).

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

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?

IBM developerWorks CM space and wiki

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.

SCM Best of breed for embedded software development?

The "Forrester Wave(tm): Process-Centric Software Configuration Management, Q4 2005" [PDF] reports in its overall conclusion:

IBM Rational ClearCase is both the strongest overall solution as well as the most widely used.

Although this may be true for corporate IT shops, I doubt that it is true for shops developing products with embedded software. The reports states about Telelogic's Synergy that it

has always been strongest among telecommunications, automotive, and aerospace and definese companies building products with embedded software.

Although it does not say that IBM does not focus on this area, it is my experience in the field and in communication with people of IBM that they don't.

In the technology markets - which include product development with embedded software and component development for multiple disciplinaries (software, hardware, mechanical, electrical, (nano)optical, etc.) - projects have some specific challenges that are quite different from the corporate IT projects, such as:

• Exponential growth of consumer products and professional products with embedded software
• Exponential growth of volume and complexity of embedded software
• Excessive pressure on costs (price), quality (safety, health and security), and the time-to-market
• Extreme competitiveness on new products and new features
• Increasing demands for integration and connectivity between heterogenous products

This brings on increased demands for the configuration management solution, for example:

• Transparant integration of within product lines and across product lines for different application domains (e.g. medical equipment and telecommunication), with different and evolving architectures, different CM policies/strategies and different product lifecycles
• Integration, collaboration and seamless bilateral exchange of data and assets across different organizations crossing company borders, not only as sub-contractor but also as partnerships, with appropriate protection of IP (Intellectual Property) and proprietary information and assets.
  
• Sharing through open-source and inner-source (i.e. open-source approach within an intranet) of components with appropriate CM control.
• Integration or interconnection for CM solutions of multiple vendors
  

In my experience, there are no tool vendors that seriously dive into these issues, not from a methodological angle nor from a technological perspective. These are challenges that are less likely to emerge for corporate IT solution than for product development. The Forrester report shows that IBM has the highest scores on R&D (5.00) and Product strategy (3.68), but the report does not take any of the above considerations into account for the evaluation.

Nevertheless, these are the challenges that product development companies will have to face somewhere in the future to survive the competition (or to collaborate with the competition and partners). It will require overcoming methodological (process definition) and technological (tool implementation) barriers. And since it involve collaboration with other parties across the boundaries of corporate responsibilities and authority, I seriously doubt those companies will succeed on their own.
But if they must, I think they will use a low-cost, possibly open-source CM solution (e.g. Subversion) as platform to jump off, unless a commercial CM tool offers the methodological and technological CM solution out-of-the-box.

IBM has the best cards on R&D and Product Strategy, but has no focus on this issue. Telelogic has the best focus, but doesn't do much on R&D. The Open-Source community (e.g. Subversion) has the best availability, price and simplicity, but lacks the necessary product characteristics (e.g. process support).
Which way it will go, I don't know. But my expectation is that the growth on product development will exceed that of corporate IT solutions, e-marketing and webdevelopment, and that IBM will lose the battle of "best of breed" with ClearCase if they don't jump in.

See also the discussion Will IBM Replace ClearCase with a New Product on CmCrossroads.

Update 14/4/2007:
Added labels.

Changing CM systems is more difficult than you think

Some days ago I was talking to a former development manager of a big technology company going through the transition to another CM system. His statement was that during the time he was development manager he encountered a transition to a new CM system twice. But times, this transition almost led to a disaster for the (software) development department.

Now, with the third transition it's the same story; the company is almost facing a disaster for the development department. Apparently, going to another CM system is a very risky project that should not be taken lightly and requires specific expertise to do right. I am not surprised by this conclusion, but I always have a hard time explaining it to my customers.