Peer practice makes perfect
by CBDi Forums Limited
Last week we commented on the continuing saga of failing projects. We suggested that a service oriented approach could bring sanity to "impossible projects" by providing clearer definition of scope, which could be used in creating collaborative activity, incremental application rationalization and delivery, and more manageable contractual frameworks. We revisited the notion of the Service Bus as an essential backplane for organizing collaborative activity.
We received quite a lot of feedback on this commentary. It seems that many people are suffering the pain of impossible, death march projects, and are looking for alternative approaches. I spoke with one person, from a well known, and highly reputable financial sector organization that better remain nameless, who said their project activity stumbled from one crisis to the next, in a sea of complexity. As we suggested last week, many are on the edge of chaos, neither ordered nor completely chaotic. In this situation making change can be really difficult.
Another correspondent points out that all natural systems will tend to be on the edge of chaos. That's where you get the maximum variety of behavior. Throwing money (and resources, remember Fred Brooks) changes very little; you need to alter the structure of the system rather than its inputs.
Peer based system structures
Another correspondent picks up this theme and suggests that we may be able to learn lessons from the open source software movement and references work by Yochai Benkler addressing the fundamental nature of how we organize activity in a digitally networked environment. In his paper, Coase's Penguin, or, Linux and the Nature of the Firm, Benkler comments on the open source phenomenon -- "which has seen the emergence of a vibrant, innovative and productive collaboration, whose participants are not organized in firms and do not choose or manage their projects on a commercial basis." Benkler goes on to explain that while free software is highly visible, it is only one example of a much broader social- economic phenomenon which he calls commons based peer mode production. He gives interesting examples of academic activity and scientific research where thousands of individuals make contributions and collaboratively manage their quality systems. The central characteristic of these cases is that groups of individuals successfully collaborate on largescale projects following a diverse cluster of motivational drives and social signals, rather than either market prices or managerial commands.
Peer systems (and we should consider them as systems) are inherently distributed. The declining price of computing and increasing power of personal computers has profoundly altered the base assumptions underlying the investment costs of information based systems. What peer- production does is provide a framework, within which individuals who have the best information available about their own fitness for a task can self-identify the best person for the job. Also practically all successful peer-production systems have some robust mechanism of peer review for weeding out contributions from agents who misjudge themselves.
Beyond open "source"
The interesting point here is that peer systems are not only focused on open source code, this just happens to be the most visible example at the moment. We don't have to look very far for examples of peer production systems at work, or various organizing models. There are good examples in the W3C, OASIS, FinXML, XBRL, Accord, OAG and many more. And several correspondents have told us about their activity internal to their own enterprises around XML, particularly at the semantic level, forging agreement on document standards and enterprise level ontology.
So where next for the peer model? Last week I suggested that the Service Bus was an essential backplane for addressing complex, multi-user application rationalization problems and..."this is equally applicable to the provision of common services into a complex marketplace, where "providing" organizations can offer standard services based on agreed XML schemas, and "consuming" organizations can plan to acquire services that do not need to be organization specific, by upgrading to the common API."
Today many people are seeing services as simply a better form of EDI. But right now is the time to be planning how your entire portfolio moves to a service basis. So how do you organize around this objective?
From a user perspective a service provides some interesting advantages over and above open source code. The specification is a higher level articulation of the requirement and delivered functionality, and provides a basis for agreement at a business process level, not at the code level. The specification and meta data are published along with the executable. Whilst open source code can be modified, it also creates a potential versioning, maintenance and cost issue. Whilst the service executable by definition cannot be modified, consumption of the service can be modified by selection or customization using run time rules.
Let's consider the life cycle of a service, the participants and processes:
Service specification: Peers develop the open specification with wide reviews, improving the open source process by focusing attention on the interfaces and business process level, instead of source code.
Service implementation: Peers constantly improve the implementation (source code) through peer group review, and provide new services (extensions), and then publish them as services. Publishing could be centralized or distributed, and be standardized or incorporate extensions.
Service consumption: Instead of downloading/compiling/etc., you assemble applications by using the open services. Again group standard services can be extended, but only by selection, run time modification or by situation specific collaborating services. Consuming applications could equally be made available to the wider peer group as open source and or open services.
The peer groups for specification, implementation and consumption are potentially different, but would be expected to have significant overlap.
Application of peer systems
Not everyone can or will collaborate on services in this manner. However there are a vast number of possible application areas including public and governmental services as discussed at length last week, and probably the most widely applicable, the internal organization and B2B application areas.
The internal application area is strongly reinforced by IBM's recent moves to broaden the web service concept into an enterprise wide, protocol independent view. In our recent report on IBM's New Tools and Technologies we report on how IBM is bringing service architectures to CICS, IMS, Java stateless session beans and COM. We report on the set of IBM products that are quietly bringing a service based revolution to the internal enterprise application space and illustrate the evolving enterprise service architecture.
However tools and technologies alone are not sufficient. What's needed is a pretty radical change in process and culture which enables organizations to develop common services in a peer production system. We can learn from the open source movement, but it is probably more instructive to examine a broader set of peer models, that support collaboration throughout the life cycle, rather than purely production.
In a throw-away comment last week I made the point that this is the new RAD. In the early days, rapid application development practices created tightly focused scope for project delivery and was widely successful -- because it delivered something! Anything perhaps was better than nothing. Before long it was realized that this was a very short term approach and some architecture was needed. But no one really ever came up with a convincing definition of precisely what form of architecture. But the Service Bus provides us with a simple and effective mechanism with which to scope and forge agreements on related services, and to have an agreed, layered architecture that allows participants to collaborate in a highly effective manner.
There is no reason why anyone should be running large, impossible projects any more. As service oriented technologies mature we need to turn our attention to the big issues of how we manage production and delivery, and peer based systems as an underlying principle that extend and improve open source techniques seem to be highly relevant.
Thanks to the many correspondents this week, in particular Leon Benjamin for his thoughts on peer production. Please send your feedback to firstname.lastname@example.org.
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For More Information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.