Making use of the world-wide services cornucopia
With heavy, rigid, and too technical methods for weaving together systems and processes seemingly on their way out, it's sometimes easy to forget there are many inherent compexities in connecting systems to each other. But one of the promising concepts of Web 2.0 is the idea of small pieces, loosely joined. This encourages and even enables secondary, unintended uses because smaller and simpler pieces aren't too specific or specialized to be of general utility. This can greatly reduce the complexity of applications at their seams and sets the stage for low-effort integration at those very same seams.
The steady rise of the mashup is proof that this model for integration delivers real value and improvement today. I'm frequently amazed by the hundreds of open APIs currently available for reuse and integration into new Web applications. And such integration really does make the whole more valuable than the sum of the parts. We even now have simple, elegant composition services like Marc Andreesen's Ning and others to let just about anybody connect these pieces together into new software.
One of the premises of Enterprise Web 2.0 is that not only are these "remixing" techniques valid and viable within the organization, but that the blurriness between the boundaries of your systems and others - and your organization and others - will only increase over time. I won't go into the governance issues that come out of this in this post, but it's even clearer that many of the enterprise software concepts of years past: SOA, EAI, and BPM, were terrific ideas that can solve many of these issues. But until now they just didn't have the proper tools to fully enable them. It's not to say that these tools were always bad, but we had to use them, whether they were the right ones or not.
And don't get me wrong, I am fascinated by the big Web services stacks and ESB products, and by the dozen or more protocols wrapped up in them. But as MomentumSI's Jeff Schneider pointed out to me last year, there is a tolerance continuum that these heavier types of products fail to serve. And I would suggest that this is the space where most of the deliverable value likely is.
In fact, one of the original creators of the concept of BPM, Ismael Ghalimi, is doing just that with a Web 2.0-style named offshoot which he refers to as BPM 2.0. BPM 2.0 emphasizes simple, inexpensive tools, true end-user wiring together of business processes, dynamic executable languages like BPEL, and many other Web 2.0 style-techniques, including zero-deployment footprint BPM clients enabled by Ajax. Ismail's company Intalio, where he is CEO, has recently released a product that actually delivers on this and he goes on to describe the mashup possibilities that can be explored with straightforward tools like his.
This bring us a new vision for BPM, just like Web 2.0 and mashups have given us a new perspective on service-oriented architecture. I do feel that the acronyms and buzzwords of technology of generations past can be annoying. So instead of adding the 2.0 to suffix to everything or coming up with a new term, I will posit here that BPM 2.0 will become an aspect of something I simply call guided interactions. Pure-play mashups already facilitate unguided interactions with a set of underlying services (meaning you don't have to go to each service manually and interact with it individually, a tool or mashup does it for you). BPM-style mashups merely facilitate guided interactions that enable entire business processes in the same way, on the Web or behind the firewall.
I'll explore enabling tools like Intalio's BPMS 4.0, Ning, and others to enable lightweight service composition and process automation, Web 2.0-style, in upcoming posts. I think you'll find it as filled with potential as I do.