Jazz platform magazine

To collect articles on the IBM Rational Jazz platfrom, I am using  a Flipboard managzine. See http://flip.it/qwdPG

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