eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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.
Next page: Security on a need-to-know basis.
Page Two
The need for distributed enterprise teams to secure both their process and content arises, perversely, at exactly the same time that developers are more likely to be working on wireless laptops in a number of locations. This makes it all the more essential to decide on the optimal extent of needed protection—not merely of code but also of project objectives and timing that may be highly sensitive information—and the means of achieving such protection.
VPNs should be used on all remote clients, wireless or otherwise. In addition, encrypted file storage on portable computers is not an excessively paranoid measure, considering the frequency of laptop computer theft or misplacement.
As always, though, the best security is limiting access to those with actual need to know—even though this means putting more effort into defining roles and administering access permissions using technologies such as Sun Microsystems Inc.s Java System Communications Suite. New security features in that offering, including role-based administration and end-user message signing and encryption, were unveiled at the RSA Conference in San Francisco last month.
Another irony is the need for scalability, a word thats long been a mantra for applications themselves, but that must now also become a key consideration in the processes that build them. Collaboration systems may easily grow in an ad hoc manner—for example, between two major development sites for a single project—only to become hopelessly unwieldy when the number of entities and locations increases, perhaps to half a dozen or more. Management tools that worked at small scale—a weekly teleconference, an e-mail distribution list—may fail to meet the needs of multiple projects and of participants with varied and specialized disciplines and interests (not to mention widely separated time zones).
Long-range results will be much better, even though initial efforts may seem excessive, if a collaboration environment is built on the assumption that collaboration will quickly become the norm—that team-based development will quickly spread to address an ambitious slate of projects involving different and overlapping sets of resources on intersecting (or even colliding) schedules. Collaboration management systems should be designed to permit the convenient definition of new projects, giving each its own work space for sharing work products and communicating plans and activities. In principle, this should involve no more effort than giving a new employee a user account and e-mail address upon joining a development team.
The system must also anticipate and address orthogonal requirements—that is, the need to allocate a developers time among more than one project as well as integrating that developers availability and effort into the schedule for any single project.
Any development manager should consider the impact of cultural differences among collaborating teams that are based in different countries.
In one study performed in 2002 by researchers in Japan, an electronic bulletin board (dubbed TransMail) enabled developers to post messages in English, Japanese and Korean, with automated translation services in the background seeking to make the differences transparent to participants.
A brief transcript from the resulting published paper, “Open Source Software Development with Your Mother Language: Intercultural Collaboration Experiment 2002,” suggests the awkwardness that can arise—and the information that gets lost or, worse, distorted in translation—despite state-of-the-art translation technology.
Even accurate translation of what is said may fail to reflect what is meant. An American manager might respond, for example, to the Japanese speakers statement during the excerpted exchange reproduced on Page D4—”It is very difficult”—with a comment such as, “Well, what are you waiting for? Get to it.” This would miss the nuance that the Japanese equivalent of “it is difficult” often is intended as a polite way of deflecting a request as one that cannot be granted.
A system thats designed to aid direct communication among team members may fail to achieve its goals when different cultures favor different degrees of directness. Building the tool set is therefore only the beginning of building a collaborative process.
Technology Editor Peter Coffee can be reached at [email protected].
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.