While the definition of Web 2.0 has barely begun to settle down, applications must start to react. Web 2.0 is, from a technology viewpoint, mostly a combination of collaborative web technology and application web interfaces which mimic their native client counterparts. From a social viewpoint, it's a communication and information transition: Blogs, "Face Books", Integrated Chat and Meeting capabilities - while creating a WebBase of knowledge - so that anyone can search for anyone or anything and communicate or contribute to the subject matter. From a CM/ALM perspective, there has always been a need to have a base of knowledge, of data, and of people. The success of CM depends on it. So how really does Web 2.0 play into the next generation of CM?
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, it's more 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; it actually can be used to connect people.
So 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. That was actually quite an advanced interface.
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... it's come a long way in supporting collaborative development over the web. But be sure that 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 lets face it, collaborative capabilities are only going to be as good as the processes underlying them.
(5) Blogs, forums, chats and even email become