Enterprise software strategists are struggling to address the expansion and intensification of collaborative development efforts. The growing mass of legacy IT systems, the spreading decentralization of global operations, the multiplying links among supply chain partners and the rising importance of specialized knowledge in crafting robust applications all demand better tools and practices for communicating software developers goals and tracking their progress—despite impediments of time, distance and culture.
It might seem odd to call legacy software a developer collaboration issue, since its often the definition of a legacy system that its developers are no longer available for collaborative discussions. However, for present-day developers to continue adding value to code that was written years or even decades ago, its necessary to understand the intentions and avoid violating the assumptions of those now-absent teams. This challenge is more similar to than different from that of coordinating concurrent efforts by teams in different locations or with different areas of expertise.
These tasks can be aided by software specification methods and configuration management systems. It takes more than technologies, though, to make collaborative development successful. Offshored efforts, for example, often may involve cooperation with remote teams that lack in-house familiarity with an organizations coding habits and conventions. Strategic projects in a global enterprise may need to pool the expertise and effort of business units with different work schedules, different spoken languages, and even different cultural attitudes toward the expression of confusion or disagreement.
A further demand on development managers is the need to engage the understanding and coordinate the involvement of a lengthening list of stakeholders and disciplinary experts. Applications face rising expectations for reliability, usability and accessibility. Unfortunately, these come at the same time that applications must withstand more adverse environments of network exposure (both to accident and to deliberate attack) and undergo greater scrutiny (by both internal auditors and outside regulators).
Clearing all these hurdles demands clear communication of what was intended and what was achieved and must also provide pathways for prompt and understandable feedback thats effectively presented to produce a desired result—rather than generating confusion or resentment.
When all of this has been brilliantly accomplished, the resulting applications become the newest burdens on software maintenance and legacy system integration processes—and the cycle begins anew.
Enterprise development managers may be tempted to look at the open-source community as an exemplar of collaborative practice and as a source of affordable, often well-polished distributed development technology, including the GPLd TWiki (www.twiki.org), Project Logger (projlogger.sourceforge. net) and phpCollab (www. php-collab.org/blog).
Theres merit in that notion of using the open-source community as an inspiration and an arsenal, but that idea can be taken only so far. A proprietary enterprise project is not the same thing as an open-source project thats meant to take place in public and thats managed by consensus rather than by formal authority.
An enterprise collaboration environment must have fine-grained control of privileges, including the right to see work, to request changes to work and to make those changes. It should not rely on participants to document what theyve done but, rather, should generate automatic notifications as needed to keep managers in the loop and to provide a reliable audit trail.
Policy enforcement tools such as CM-Logic Ltd.s CM-InPractice, which builds on the foundation of IBMs Rational ClearCase, address this need. Microsoft Corp.s forthcoming Visual Studio Team System also adds this kind of "life-cycle management" in the next generation beyond the companys popular Visual SourceSafe.