Yet another gem from Jon Udell on the architecture of participation and open source. The traditional assumption of open source assumes – as Udell puts it “that the essence of software is source code, and that participation means hacking it.” He correctly highlights the fact that with the emerging services model, that’s no longer the only avenue of participation.
And this is why I think architectures such as our COA are so important. Because if we can begin to think about requirements as particular manifestations of services, all of a sudden a host of new participatory mechanisms are possible.
For example, as a systems integrator I used to conduct a lot of customer references as part of the software evaluation process, meaning I called up or interviewed users of particular applications to get a reality check on vendor claims. Pretty standard practice. In a few cases, these customers were willing to provide us with some FYIs or tips on the application implementation, some of which ended up being helpful.
But if instead we’d been able to discuss his application not in the traditional sense of a siloed packaged application, but instead in terms of services and which he implemented, and using what requirements, then I would really have had something to work with. SEC compliance would be expressed not in terms of implement application A, but instead deliver these services (access control, backup, disposition management, retention, etc) with these requirements (n years easily accessible, etc.). It’s by no means a panacea for application development, but it beats starting from scratch, or becoming dependent on a single vendor.
The architecture of participation is obviously an important concept already, and as firms increasingly explore services based architectures, I expect it to become even more so.
