More white papers:
Find out more ...
Neuma White Paper:
CM: THE NEXT GENERATION of Web-Based ALM
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 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, and must become an important part of the product design/business case documentation.
So these are a few of the capabilities/requirements for an advanced Web interface for a CM/AlM tools. And 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 is the global accessibility and the lack of client-side installation. But there are plenty of native interface tools which share these same benefits.
That's a first cut at next generation CM/ALM Web interfaces. Maybe as the 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.
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. Although 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 calibre of all of the attendees. This was my first visit to CMII World and I expect it will not be my last.
Joe Farah is the President and CEO of Neuma Technology . Prior to co-founding 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 in use 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 by email at firstname.lastname@example.org