Noel: What's the primary CM tool you're working with, and how long have you been working with it?
Joe: I have been working primarily with Neuma's CM+ for the past twenty-four years. CM+ has supplied all of our needs in the areas of: version control, build and release management, change control, requirements management, document management, test suite management, change request management, problem tracking and project management.
Noel: What tools do you have past experience with, and what made you switch to your current favorite?
Joe: In the past I have worked with SCCS (Unix), CMS (DEC/VMS), PLS (Nortel/BNR proprietary), SMS (Mitel proprietary). I am familiar with, to a lesser extent, various other tools including ClearCase (IBM), and Subversion (Open Source), but have not used these on any projects. In my case, CM+ is my preferred tool because we have been able to rapidly expand its capabilities both as a user and as a vendor.
Noel: What allows a tool to be scalable or adaptable to other organizations/companies?
Joe: Scalability and adaptability are two separate issues. For scalability, there are two key issues: performance, and resource requirements. Efficient SCM/ALM tools such as PerForce and CM+ can support hundreds to thousands of users with little regard to performance tuning or to the level of hardware hosting the CM repository/server. Other tools, such as ClearCase (IBM), or Dimensions (Serena), are what I call "Big-IT" solutions. They require that you manage your hardware if you wish to scale up the solutions to hundreds of users, and they typically require performance tuning both in the hosting repository and in the SCM/ALM software. With CM+, for example, you can scale up from 1 to 2000 users without worrying about performance issues or the level of hardware you're using. Hardware improvements have reduced scalability issues over the years, but when you end up managing millions of revisions of things, it still makes a big difference. "Tagging" operations can be onerous on some systems, but fast as lightening on others. This has to do with the architecture of the solution, and of its underlying repository capabilities.
Most CM solutions rely on the use of relational databases, because that's the norm in the database world. But these are not well designed to support things like large objects (such as files), revisions of data, hierarchical data such as you find in org charts, source trees, bills of materials (BOMs), and Work Breakdown Structures (WBSs) and traceability links, especially when these are not one-to-one relationships.
This gets us to the second part of scalability, which is in regards to resource requirements. Obviously, if you can set-and-forget your repository, you'll need fewer staff to maintain it. And maintenance is a huge cost in some CM solutions. Many CM+ shops allocate zero persons to maintenance, as do we do here at Neuma. Scalability doesn't just mean that I can move from 10 to 100 to 1000 users, or from 10,000 to 100,000 to 1,000,000 files. It means that when I do that, I don't have to move from one-person support to 5 to 50 as I "scale" my solution. And unfortunately, that is the case with some second-generation solutions. It is also important that productivity and ease-of-use scale well with a growing user base and a growing code base. It's just not acceptable to have a slower system as more systems and files come on board.
The second area of the question was with respect to adaptation of the solution. Here we have a wider scattering of capabilities among tools. First of all, recognize that some tools are very point specific. Subversion, for example is a first generation version control tool. Yes, it's much more advanced than CVS (another 1G tool which it has largely displaced) but it does not come close to a 2G tool. ClearCase is a 2G CM tool - not just version control. It supports build management and a few other basics of CM. However, it requires ClearQuest to help move it to a full CM solution, which supports problem reports/activities and change packaging as well.
Subversion can be tweaked here and there and used in different ways to adapt to an organization's process. But then we're only talking about version control, and at a command line level as well - not very user friendly, so we're talking version control only for the software techies - not for documentation or requirements personnel. ClearCase/ClearQuest can be customized extensively. However to do so requires an army and deep pockets. IBM's JAZZ and Rational Team Concert (RTC) have much easier and extensive customization capabilities. And ease is important when we're talking about adapting solutions/tools. The other thing is the level at which you're doing the adapting. Don't hand me a compiler and tell me it can be done. Instead, give me tools so that I can create a specific Problem Review Board (PRB) meeting dashboard in a few minutes of my time. That's high-level adaptation - customization, configuration, tailoring - whatever you want to call it.
And this is the most critical part of any solution. I've got a dozen or so roles out there - not just programmers. There's documentation people, requirement staff, project managers, CM managers, product managers/owners, verification personnel, executives, etc. Each one wants the solution specific to their role. On top of that it has to conform to the project’s and organization's process requirements. If it can't be adapted easily and quickly, it won't be done. Or worse, it will be done once, but will be hard to maintain or change - and a whole new department will spring up just to manage the tool's process.
Noel : What do CM tools need to be equipped with to be able to be implemented on an agile project?
Joe : There are a number of key components for CM tools to support agile projects.
1. Easy, priority/iteration based story/activity allocation. This allows the product owner (i.e. manager) the ability to rapidly and iteratively change plans, typically for the next and future iterations and releases, but also, during an iteration if the unexpected occurs.
2. The tool needs to be able to easily define new stories/activities, and these need a title, descriptive notes, priority, assignee and owner, status, release and iteration fields. User-friendliness is key here.
3. There needs to be a simple interactive query tool that can summarize and zoom in on the data: from the title to a full description, from release to iteration to priority to a drill-down list of contents at each level; assignments for each user; rapid status reporting on the state of an iteration in progress; charts for burn-down rates.
4. There needs to be an interactive manner to go from story to the creation of a change package, so that the tool can automatically capture the traceability links. When changes are created and later linked to the story, the data tends to deteriorate. If the user has to right-click or otherwise select the story to create the change, then traceability information is captured automatically and the CM tool and data becomes much more effective.
5. The CM tool for agile products must make it easy for developers to see the work assigned to them, and wherever possible it must capture the context of their work (e.g. product/release/iteration) to minimize input and focus output to areas of interest. In particular, as work is completed, project status must be automatically updated, without forcing developers to perform administrative status updates, which often are forgotten or otherwise omitted.
6. There must be a clear problem tracking capability that fits well with the agile-based priority driven assignment to iterations and developers. It is important to identify and report problems, to prioritize and assign them, and to track them to completion. This must be a natural part of iteration planning, handled similar to, but separate from, story/activity management. Again, if implemented correctly, tracking progress should not require administrative actions. The tool should be able to infer progress from normal problem fixing actions.
7. An important part of the agile philosophy is reviewing and correcting the process so that it runs more smoothly in each iteration. The CM tool helps here by providing all of the metrics, interactive categorization and drill-down capabilities to review past iterations as well as future plans. The more easily information is available and summarized, sliced and diced, the more effective and productive the reviews will be.
8. Product owners need clear backlogs on a product, release and iteration basis, with the ability to quickly navigate among these. These are also crucial to customer negotiations, and must yield customer-viewable reports, dashboards and other summaries as might be found desirable. Backlogs should be clearly separated into stories (features) and problems (non-conformance).
9. Continuous integration is important in agile development to help ensure high quality product is maintained through the development cycle. The CM tool must facilitate automation of both builds and testing, meaning the CM tools must manage sufficient information to ensure it can support this automation. As changes are checked in to the software base, corresponding automated test cases must be added to the automated test suites. To do this, there has to be clear traceability between the stories/problems and the test cases that cover these. Whether the verification team or the developers themselves create these test cases—they have to be easily captured, and linked to the corresponding stories and/or problem reports.
If a CM tool covers these requirements, it will do very well in the agile environment, and will be admired by its user base.
Noel : What future capabilities do CM tools perhaps not have today, but would be nice to have in the future?
Joe : This is a difficult question to answer. Not because the capabilities are not known, but because of the scope of tools. Subversion is a version control tool. If I said it should handle traceability and test suite automation better, well, it's just not designed to tackle those areas. Never was and likely never will be. And then some tools simply do things better than others.
I'll speak about tool generations. Most tools today are 1G or 2G tools. And there are a couple that are at the 3G/4G level. The real reason the industry is stuck at 1G or 2G is because it keeps spinning its wheels. ClearCase is too expensive to run, so let's build Subversion and make it free. So great, we regress from a 2G to a 1G solution because of cost - a great reason to switch. But why not look more closely at the technology - how can we move technology ahead.
If you want to know what future capabilities CM tools should have, here's what to do: run a showcase competition. Put the tools all out there and first let them show off their cool and unique features, and upcoming features, and then put the solutions up against one another. Each has 24 to 48 hours and a small team to produce a couple of dashboards, some reports and graphs, or load in some source trees and demonstrate how well they flow into the change cycle. Whatever the tasks, it doesn't really matter—put the solutions up against one another. That has never been done in the CM industry. The closest is various reports, such as from Ovum, or Forrester, that compare sales, a few features, etc. That's fine and somewhat useful. But it won't tell us where CM solutions have to go.
CM solutions have to cover the entire ALM spectrum on a single repository, with a single administrative interface, with a single user interface paradigm, a single customization capability, a single process definition capability, etc. Not a "backplane" that lets you plug in various point solutions so that they can exchange information, etc. These are naturally limited and complex and have different ways of handling multiple sites, customization, administration, etc. Let's steer the industry away from the "look how fast and free I can get version control going" attitude. That's just creating bigger problems.
What else? I want to manage Software CM and Hardware CM in the same CM repository. Bring the SW and HW teams together.
Next, I want to see CM happening in the background for as yet untapped domains: lawyers, accountants, venture capitalists, and publishers. These groups have very specific and well-behaved CM requirements. But they never think of "CM". And CM can be a tremendous help to them, if they don't need to learn some technical acrobatics such as learning Subversion or GIT. Their CM has to happen naturally as a part of their normal day-to-day operations. And then maybe the software world will wake up and ask, "Hey, why can't we do that too?" Granted, SW development is much less well behaved.
I want global development to work as if everyone was at a single site. Users should be able to move from site to site and continue working. Permissions should be user-based, not site based, as should content, with allowable security exceptions. And if networks go down, the system should still work and then automatically recover and restore itself. I don't want to have to plan data partitions and synchronizations based on development sites.
Finally, let's have get rid of administration while improving availability. There should be no need to administrate - the tools should manage that. Similarly, there should be no need to do performance tuning, balancing, etc. The tools should do that. Let the team do development and CM, but not administration. Zero administration repositories, zero-administration tools—always available. The CM tools, servers, clients, repositories, etc. should be always available. The age of downtime (whether for disk crashes, upgrades, server issues or whatever) is past.
I've taken for granted, in this last response, that the CM tools can do CM well, even though most can't. So maybe one last add-on would be to have a tool accreditor that can objectively (to an agreed upon set of criteria/requirements) evaluate the CM capabilities of a tool.
President and CEO of Neuma Technology, Joe Farah is a regular contributor to the CM Journal. Prior to cofounding Neuma in 1990 and directing the development of CM+, Joe was director of software architecture and technology at Mitel, and in the 1970s a development manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS), still heavily used by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in engineering science from the University of Toronto. You can contact Joe at [email protected].
