 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Press and Success Communication
Proves Key to JSR 16 Success
When it comes to leading the JSR 16, Connector Architecture, expert group, Rahul Sharma of Sun Microsystems holds a unique perspective: he considers the experts his customers. Rahul works full-time as specification lead, filing JSRs, offering strawman proposals, eliciting feedback, teasing out common ground, and driving home consensus. He does all this to get approval from his customers, the experts. They, in turn, want to satisfy their customers -- the companies and developers they represent. Those entities, then, live to delight end customers, who demand the most. The customer, no doubt, is always right. At least, when participants fully engage in the Java Community ProcessSM (JCP) program, it seems to work out that way. A Phone and a Strawman A well-specified JSR helps JCP participants grasp the scope and need for a specification. Picking up the phone was how Rahul, his manager, and other architects in his group personally contacted industry partners they'd worked with before -- including IBM, BEA Systems, Unisys, Fujitsu Limited, and TIBCO Software Inc. -- and sold them on his clear and well-scoped JSR.
Rahul also believes that having an initial strawman helped him clearly articulate the requirements of the project in terms of concrete issues and use cases. People were more willing to sign on once they understood the goals and scope of JSR 16: to solve the problem of integrating compelling Java applications with existing and legacy enterprise applications and systems. Then the hard work began in earnest. Face-to-Face Group
Meetings Rahul believed it important to start out in a face-to-face situation, but he felt surprised and gratified when all members showed up for the two-day event in August 1999, at his building in Cupertino, California. Because Rahul held the meeting at his own location, it was easy for him to invite his director and others who worked on related specifications to share relevant information with his own team. Without assuming the experts had prior knowledge, Rahul gave background on each issue. Then experts identified important design issues and provided useful technical inputs. Rahul took meeting minutes detailing the opinions expressed. For each issue, Rahul felt it was important to assign time-bound action items immediately to prevent issues from getting ignored. Rahul identified what action would be taken, who would take it, by when, and for which version of JSR 16. A few months later when the specification had stabilized, a second all-hands meeting took place. Rahul says the goal was "to drive the resolution of each issue listed in the first meeting to a consensus, define the features for the next version, and address requirements from each expert to his or her satisfaction." But consensus was possible only because Rahul listened to individuals. One-on-One Individual
Meetings
In the all-hands meetings, experts listened intently to presentations, but when asked to offer feedback in front of others, many would pass. JSR 16 expert Jon Dart, of TIBCO Software Inc., says, "I'm usually willing to share comments on the spec and suggestions for improvements with the group. Of course, I can't discuss any part of TIBCO technology that involves trade secrets. I also can't discuss product plans or unannounced products. And I'm reluctant to give details of some technology areas in which we have a competitive advantage. But generally I don't think these constraints greatly interfered with my participation in the expert group." Rahul understands the
ambivalence of experts who may not want to share company-specific
information with other experts, but just with the spec lead. "It's
the responsibility of the spec lead to resolve issue on their technical
merit and not be constrained by political or company-specific compulsions.
It's very tricky," says Rahul. Rahul's solution was to draw out individual experts in one-on-ones, during which the experts had plenty of ideas to offer. For experts in Australia and Japan, Rahul set up long conference calls, during which they went through every issue. Experts were satisfied to have had the spec lead's ear, knowing that it is the responsibility of a spec lead to ensure that intellectual property specific to a participating company is never revealed to another expert or expert group. Rahul felt the individual exchanges were more efficient and a better means of consensus-building than group-wide email discussions. Nevertheless, email had its own place in his communication strategy. Email Lists In any email list, maybe a quarter of the participants contribute enthusiastically and persistently to brainstorming sessions and fine-grained discussions. Others may reply to an issue only initially, contribute sporadically, or merely lurk. The challenge lies with those who don't interact. Rahul wonders, "Does a no-reply mean they're satisfied with an issue or don't have time to respond?" No-replies make it practically impossible to drive an email discussion to final consensus. Clearly, email alone is insufficient. As Rahul puts it, "A lot of expert groups assume that setting up email for communication solves the whole thing. But the key is to make an expert group into an effective team through effective communication, good interpersonal relationships, and face-to-face meetings." Communication Pays
Off The participant review closed in May 2000, with public review closing two months later. By October, a final draft was proposed, and it was all over but the shouting, that is, the shouting of thanks by the multiple companies who adopted it. Generally pleased with the entire process, Jon Dart says, "Feedback and discussion within the expert group led to a better design. And I prefer having a structured process. It gives both expert group participants and the larger Java community clear milestones and expectations." JSR 16 expert Pavan Bhatnagar of iPlanet (TM) E-commerce Solutions was likewise satisfied with his involvement in the JCP. Like other involved companies, iPlanet benefits from having an expert in the group. "We get a jump start over everybody else who might go after the standard at some point in time. Speed to market is very important," says Pavan. |
