The power of simplicity at the edge

One of the demonstrations I like to give to show the power of simple services is to use Iridesco's Suprglu to instantly wire together Web services into a new and useful service on the spot.  This is the simplest possible mashup you can create but it does combine useful data from multiple sources into a single view.  You can do it yourself: copy and paste a few feeds from a few sources of interest and you're off and running. 

This visceral demonstration shows the promise of using simple data formats like RSS to let anyone create useful new information sources and services in a straightforward manner.  I say services because Suprglu converts the resulting mashup into yet another RSS feed that can in turn be used and recombined anywhere on the Web.

In fact, service recombination, mashups, and remixing are going to force a lot of us to rethink our existing services to enable a composable Web. So too will the scalability, reliability, feedback loops, and the associated intellectual property issues, of the nascent remix culture.  Rethinking is necessary because so much of our approach in the IT world is still mired in the world of intended uses.  As we all know, most software in the enterprise is designed for specific requirements defined well ahead of time.  While service-oriented architecture (SOA) finally encourages second-order uses of services, I would suggest that this encouragement is just not forceful enough.

Note that Web 2.0 and SOA are primarily concerned about the edges of systems.  This could be the experience edge where the user interacts with with software, typically HTML, Ajax, Flash, etc.  Or it could be the services edge that provides pure information to other systems, such as HTTP, REST, RSS, and SOAP.  What happens inside isn't revealed, nor should it.  This is the separation of interface from implementation that we've tried for so long to achieve.  And since software is increasingly made from pushing these edges together, we should seek to understand the best ways to do that.

Like agile software development discovered, what you think you need up front is rarely what you actually need.  There is even an acronym that captures this concept, YAGNI, as in You Are not Going to Need It.  Yet, trying to a priori determine how services should be offered, we've created sometimes too sophisticated and complex ways to expose them to others.  Yes, I'm talking about WS-* and the big Web services stacks, but even basic Web services like SOAP.  I know many of you have heard the arguments, but small pieces, loosely joined can't be emphasized enough. Why?  Because we keep watching it operate successfully on an impressively large scale on the Web.

Another real-world example is the success of the blogopshere's bustling and massively distributed syndication ecosystem.  This RSS ecosystem is a clear demonstration that simple services which don't control the other end of the conversation, while not perfect, are extremely easy to participate in, scale way up, and have virtually no single points of failure.

The bottom line: Every decision to add unneeded structure or ceremony to the consumption of data in your organization is a tax that reduces the value that data offers.

But what has changed?  Why are we increasingly encouraged to radically simplify services and impose the the least amount of structure?  One is that the pendulum is once again swinging away from centralized control of information resources, maybe permanently.  Another is the sheer scale of use and reuse that is starting to occur.  As a classic example, Amazon has over 50,000 online users of its Web services.  A quick tour of its API shows that simplicity is the model that makes this level of adoption possible.  Also telling, in a real-world REST vs. SOAP debate, Amazon's simpler REST services are reportedly by far the most popular (they offer both.)  From a business case, the $211 million of revenue Amazon derived from these Web services shows the value of offering strategic services in a highly reusable form.

As software everywhere increasingly becomes a matter of wiring together pieces from the services landscape, the ease of which this can be done will be a major competitive factor.  And like Marc Hedlund has been doing recently in his fascinating examination of current best practices in Web development, I'll be looking for both real-world success stories as well as actually using the latest mashup, BPM, and composite application tools to see if they make living on the edge easier.  I will share the results here.

Finally, somewhat reluctantly, I'd like to coin a new phrase: composability impedance.  This phrase describes the inherent tendency of complex, rigid, overly specialized service models and structured data to impede being blended with other services.  Reducing this impedance is clearly a key success factor in any application that depends on other services.