I’ve been pondering the recent spate of comments and discussions about the State of the Software Nation.
Enterprise Systems seem to be broken by design. As SvN declares: Enterprise Software Sucks because the buyers aren’t the users. Khoi Vin recently detailed some of the issues and Sig at Thingamy has been talking about the philosophy of contemporary business software for a couple of years, so none of this comes as much of a surprise.
However, the problem is much deeper and broader than the amorphous cloud of “Enterprise” applications. Lots of consumer-level software has real problems. Jeff at Coding Horror has been posting recently about the troubles with consumer software (Are Features the Enemy? and Why Does Software Spoil?) .
Small, Light, Vertical
———————————————————–
Web 2.0 is a terribly misused term, but the broad sweep of the “philosophy”, rather than the marketing hype is what I am referring to here.
The core ideas underpining Web 2.0 is that the web is a platform, driven by data and enabling systems and sites to be composed by pulling together features (http://en.wikipedia.org/wiki/Web_2).
At the moment we’re seeing the effects of this vision largely in social and personal applications - Flickr, Facebook, Twitter.
But
One of the most interesting recent developments is a slew of small, light, and tightly-focussed applications targeted toward very specific functions. One of the most well-known examples of such an application is the Basecamp Project Management tool.
Although most people seem to associate sites like Flickr and Facebook with Web 2.0, I think the real revolution is in these small vertical applications - common focussed on perfoming a single business function incredibly well. Coupled with elegant, sophistciated interfaces, most of this class of application also offer open access through an API.
Software Federations
———————————————————–
I propose thinking about your “enterprise” software as a loose federation of individual applications.
A Software Federation is a set of small, light, vertical applications coupled together.
Data flows between your applications through the use of APIs and process flows can be ad-hoc and are focussed on being “good enough” rather than being perfect. Ideally, the Federation is constructed with lightweight frameworks rather than high-end “Enterprise Platforms”.
One of the important ramifications of this type of thinking is on the role of the developer. Software Federations require developers who are capable of both understanding the business and creating the code that ties the pieces together. There are some and opportunities here for Domain Specific Languages to help drive developmt and the advances in the handling of REST in Rails 2.0 look like making much of this style of development simpler.
The Republic
———————————————————–
I’ve been thinking about what would be required to assist developing Software Federations. Consuming APIs is already pretty simple and parsing XML data is very definitely a solved problem. What seems to be missing is a lightweight system for managing process flows - something that would allow developers to easily define a flow through an series of applications, combining many small simple scripts to massage and process the data into a single Software Federation. Although “lightweight” and “workflow” don’t really seem to go together - the workflow system I have experienced are all in the category of “Enterprise Software Sucks”, it seems like it may be possible to create a framework that provides support to developers.
What do you think?
