Atomization of Software

One of my web acquaintances, Dave Pollard - author of the How to Save the World blog, recently posted an entry titled The Atomization of Software. His entry has spurred me into writing down my own thoughts which have been gelling in the back of my mind the last few months. A number of things have been coming together lately that are significantly changing the way software is used and, hence, developed.

To summarize, Dave suggests that software will atomize into 'microapplications' where businesses and their customers will co-design and 'peer produce' applications that build upon other microapplications. Google and Amazon are the archetypes of this philosophy with their highly successful webservice APIs. In fact, a whole new round of internet businesses are taking those examples and creating highly compelling desktop-like browser-based applications.

Why do I think that these changes are significant and not just an illusion? First off - because my 'gut' says so :-) Many software developers chide me on making such non-rational judgements, but I don't care since my gut has taken me on an interesting journey so far (early Java, web-server-based applications, and Jini adopter). In addition, I've seen software, blog entries, and articles where the authors' excitement to describe their thinking has resulted in new words : Ajax, web 2.0, semantic web, web services, mashup, social software, etc. I love the word 'mashup' - it's richly suggestive of alchemists (or cooks) messily throwing a bunch of stuff into a pot and out pops something magical.

Software As Services

Dave focuses in on standards and protocols such as Ajax as to what is leading this sea-change. I differ slightly with his opinion in that the biggest revelation is developers seeing the importance of 'software as services'. Tools, standards, and protocols have existed for some time to support this way of developing software. In fact, software as services is the critical piece making Ajax useful.

However, this is not how software is usually developed. Most software has been written as all-inclusive applications where the client interface is tightly coupled to the server interface(s). This means that each of the parts are useless without the whole. The crux of the problem is that software designers have spread "state" - what the user is doing - through all the software layers.

Over time, the best designers recognized solutions to the coupling problem and learned the importance of atomizing service requests. What this new crop of Ajax applications does is give more developers a view into the patterns that the best software architects discovered decades ago. In other words, only recently have the majority of web developers had exposure and the ability to learn from this model.

Although an example of the "layering microapplications to create more complex applications" pattern already exists in Unix command line piping, the purpose of most applications has been simply to capture and manage large amounts of information that didn't need to be shared. However, the need for data management is getting to be less and less important while sharing data is getting more and more important. This situation is true in general but even more so with web applications.

Conclusion?

Being a Jini-head for a number of years has given me the opportunity to discover the importance of 'software as services'. However, those Jini-based systems that I've architected were never really intended to be shared. The extension of sharing and layering to the software as services concept is bringing out some very exciting ideas (albeit in a different technology stack than Jini.) Which makes me wonder... what would happen if the web becomes more Jini-like and Jini becomes more web-like?