First of all, let's realize that doing CM over the Web has been a practice for some time, especially within Open Source projects. It's not the doing of CM that needs to evolve, but rather the shift in web-based CM technology and goals that need to take advantage of the Web 2.0 mindset.  There's really nothing today that web-based technology could not have delivered at the turn of the century, but the expectations and the targets have changed.  The idea is that the network doesn't just connect computers, but actually can be used to connect people.  That said, the focus of this article is really how I believe CM needs to evolve in a Web 2.0 world.

The first advanced CM tool Web interface I used was in the late '90s and early '00s.  You could expand and navigate the source tree.  A right-click menu on the source tree had all of the necessary options.  You could access problem reports, requirements and customer requests through the same interface, and the menus were object-oriented.  You could zoom in to information that you needed.  It was actually quite an advanced interface.

The thought that first comes to mind is that with a Java interface you could really do some impressive things.  The only thing was that the technology was just plain HTML/DHTML technology, with a bit of CGI and JavaScript thrown in.  Java might have been a wiser solution space, or perhaps not.  The point is that the technology to create effective applications, even for CM/ALM, has been around.  So what does the Web 2.0 tag have to do with advanced CM?  Again, it comes down to expectations.

My Expectations
Here are some of the key capability expectations that I see necessary in a Web-CM 2.0 world:

1) The user interface must mimic the native interface or, if none, at least what the native interface expectations would be.  That first tool I used did a reasonably good job of it.  The web interface was sufficiently similar to the native interface that trained users could directly transition to the web interface when necessary.  If one uses an object-oriented interface, why shouldn't the other?

2) The functionality must span ALM functions.  It's simply not good enough to have simple version control and problem tracking through the Web interface.  While it might very well be OK to confine the CM Manager to a non-Web view of things, the general user must have access to source code, change packages, problem reports, tasks and/or feature requests, documents, baselines, releases and build records.

3) Customization is vital to any CM/ALM interface.  It's no different for a web-based interface.  It must be easy to customize the user interface.  That is, the customer must be able to customize the web interface so that individual roles will see only the appropriate operations and information.  In an ideal world, the customization of both native and web interfaces would be controlled through the same customization parameters/files/operations.

4) The user interface must support collaborative CM activities.  Look at CollabNet, for example:  it has come a long way in supporting collaborative development over the web. B e sure, though, there is a much longer distance to go.  Collaborative web interfaces are especially good for meetings, especially if the meeting can be captured and viewed later by those who couldn't attend.  They're especially good for document reviews, and, of course, for source code change reviews, at the Change Package level if you please.  But let’s face it:  collaborative capabilities are only going to be as good as the processes underlying them.

5) Blogs, forums, chats and even email become an important part of project design.  It's not sufficient to support these through the Web interface.  They must also be tied back to the architectural components, tasks/requests or related technical areas, documentation.

These are a few of the capabilities/requirements for an advanced Web interface for a CM/AlM tools, but there are other considerations.  Status information needs to be updated frequently, just as in a native client.  It may be sufficient to update in response to a user action, but it would be even better to have an active status update capability so that I can be made aware when a new problem report heads my way.

Web access to CM/ALM, does not necessarily imply that this is in preference to fat clients.  The key benefits of a Web client are the global accessibility and the lack of client-side installation.  But there are plenty of native interface tools that share these same benefits.

That's a first cut at next generation CM/ALM Web interfaces.  Maybe as Web 2.0 concepts become more coherent, we can re-visit some of these requirements.  It might be interesting to visit all of the current CM tools from a Web-client perspective. I'm certain that at this point, we'd find a high level of diversity.

CMII World
On another note, I was in Orlando this past week for the 21st annual CMII World conference.  CMII is a CM Process Model taught by the Institute of Configuration Management.  The CMII World conference is a gathering of CM professionals, with typically a stronger focus on hardware/system development than on software-only systems. Though there was only one CMII Certified SCM tool on display, there were plenty of CMII Certified PLM tools.  The talks were of high quality and I was impressed by the caliber of the attendees.  This was my first visit to CMII World and I expect it will not be my last.