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

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.

Second Life, a hype

I am reading a lot about Second Life lately. Various companies are looking into it as a way to promote their and show their new products, even to have them tried out, yet withou really understanding or even visioning the business value that it might bring. I wonder what they are really looking for.

IBM for instance is planning to have meetings, lectures and trainings in Second Life. Recently Grady Booch announced that his virtual self is giving a virtual lecture in the virtual world. But I don't see my virtual self sitting in a virtual classroom looking at and listening to a virtual speaker and virtual peers. Not if there are non-virtual (first life) video conferencing applications available that show real people with real voices and, more over, real expressions. I don't see myself watching a movie sitting (virtually) in a virtual cinema - and sitting behind the computer in reality - if I can see the same movie in much better quality and performance using Media Player applications.
I don't even see my try out new Nike shoes just by looking how well they fit my avatar, if I can't try them on at my own real feet. Haven't you seen the fancy flash applications of cars, where they show intereriors, exteriors, engines, safety features, in-car entertainment systems. You don't need a complete virtual world where you can travel between islands to show those products.

Second Life is typically an application to build virtual communities: build social networks and interacting with people within your network. From that perspective it is nothing more - and nothing less - than an ordinary chatroom with a (3D) graphical interface.

IBM and other companies are going to invest in Second Life to explore the business potentials, but they hardly invested in exploring the potential of previous social networks. Take for instance the IBM DeveloperWorks "community": it's just a newpaper-like publication board with discussion forums. The community building primarily comes from the people who contribute to the discussion forum. Originally discussion forums were just Q&A forums, where a user could post a question and many users posted answers to the question. But already in the Rational days there was the Rational Developer Network, a thriving community where people not only posted questions and answers, but also shared knowledge and experience. And not only on the product specifics, but also more general about professional interests, such a configuration management, process management, modeling, etcetera.

In 2003, Rational recognized the value of user communities. They formed a group volunteers (called Discussion Facilitators) to foster the user community. The social community would be a (low-cost) extension of the support service, and at the same time be a promotional instrument more powerful than the sales force could be. There were plans to create a real user community, where people feel the social connection and support. And then IBM took over and the focus was completely turned to sales. Rational lost its position as methodology leader, products lost their top class position and the community slowly degraded into a simple Q&A forum and website.

And now there is Second Life, a virtual world where social networks are primarily build around dating and gambling. Like many 3D MMORPG (games) I think there is a future to it, as an entertainment platform. Some people may get rich from Linden Dollars, but as a business platform I think it's just a hype.

It's all a game

In a blog, I read how IBM enters the gaming world and this brought me the idea that there may be more commonality between software development and online gaming then we might expect, such as

• Team game
• Strategic approach
• Online community
• Common goal
• Common set of rules
• Computer infrastructure
• Continuous learning

One of the nice things about strategic games is that the game vendor has created a virtual world that contains almost every capability to face the game challenges in order to achieve the ultimate goal of the game. You can give instructions, set assignments, get status report of all kind of aspects, do what-if analysis, and much more. Everything is represented in colorful, 2-D or 3-D graphics, accurate reposiories of artifacts, drag-n-droppable, interactive, on-line multiplayer and joyful to do. And how much does this game cost? A few dollars or euros. How much time to install it, get it working, learn it? A few hours, or may be a day or two.

Compare this to the software development environment that an average software development organization provides to its developers and the costs and efforts that are involved in setting this up, determining the rules of the "game" (procedures, practices, workflows, quality criteria, etc.). Expensive CM systems, SDE tools, a lot of in-house made scripting to achieve automation and reporting in spreadsheets and intranet sites.


What if we would create a software development environment à la Command & Conquer or Pharao? What if we would make an interactive, on-line multiplayer game for software development? My first intuition says that it can't be done or else it would have been done before. My second intuition says that if we spend billions on movies and games in the entertainment industry and find millions of people enthousiastic about it, then apparently that's the way to get people moving.

IBM Rational Discussion Facilitators

Marc Siegel, IBM Rational's community manager, has introduced the IBM Rational Discussion Facilitators in an article on IBM DeveloperWorks.

Many customers may have noticed that since Rational has been taken over by IBM some years ago, the communication between the customer (including the responsible IT and Development managers, and the actual users working with the tools) and IBM Rational (including sales and support) has changed considerably, not for the better in most cases. User to User communication is an emerging (support) strategy for customers, and it has proven its effectiveness for open-source software for many years.
However, User-to-ToolVendor communication has been difficult in the past and will become more difficult in the future due to cost-saving on service organizations. For that reason, I think that IBM has made a smart move to institutionalise the use of Discussion Facilitators for direct communication with Product Management, as they are not on the payroll of IBM (i.e. they are ordinary customers themselves) while they provide a bilateral service to the user community.

The IBM Rational discussion forums are the discussion forums for users of Rational products. The IBM website, including the DeveloperWorks website, are rather difficult to navigate through so you'd best go to it through the direct link.