Enterprise Mashups and Situated Software

Situated software and mashups are regarded as closely related concepts. (See for example Redmonk's James Governor.) But there are some important differences between the two concepts, which I want to explore in this post.

I also want to talk about the related concept of Bricolage. As we shall see, many popular examples of both situated software and mashups involve strong elements of bricolage.

(Update: I've just added a post to my SOAPbox blog about the Lightweight Enterprise. I now have a number of related posts, which I need to tie more firmly together.)

Bricolage

Bricolage is a form of improvisation practised by some engineers, using whatever resources and repertoire come to hand, in order to perform the immediate task. A person who practises bricolage is called a bricoleur.

Bricolage may be contrasted with following a disciplined and repeatable engineering process.

Situated Software

Clay Shirky defined situated software as "software designed in and for a particular social situation or context." This may be contrasted with software that is produced as a universal solution for some generic problem. For some examples, see my post on Situated Software (January 2005).

The late Claudio Ciborra saw bricolage as a useful way of delivering situated software. The Wikipedia article on Bricolage glosses Ciborra's argument as follows. "By valuing tinkering and allowing SIS to evolve from the bottom-up, rather than implementing it from the top-down, the firm will end up with something that is deeply rooted in the organisational culture that is specific to that firm and is much less easily imitated."

We can perhaps understand the link between bricolage and situated software by considering the link between their respective opposites. The economics of scale in software production appear to point towards a disciplined (and easily automated) software engineering process, producing universal (standard, one-size-fits-all) software artefacts. (In the Boxer model of Collaborative Composition, this is represented as an anticlockwise arrow.)

Both bricolage and situated software seem to represent an entirely different ethos - driven by the particular rather than the universal. (This is represented by a clockwise arrow in the Boxer model.)

However, bricolage doesn't always produce situated software. (Tinkering doesn't always produce something that is deeply rooted in the organization - it only does this under certain favourable conditions.) And conversely, some situated software often requires a highly focused and disciplined approach as well. (Similar to what Christopher Alexander calls a Timeless Way of Building.)

IBM's Ali Arsanjani (Kant versus Hume) has suggested that we can identify two styles of SOA, which he associates with the philosophers Kant and Hume. My interpretation of this is that Kant represents the production of services (and other software artefacts) from some apriori (generalized, enterprise-wide or industry-wide) schema, while Hume represents the production of services and software artefacts from the specific local requirements, grounded in the strategic context of a specific enterprise and its customers?

Some people like to refer to the universal/rational/Kantian position as top-down, and the grounded/empirical/Humean position as bottom-up. But I think this is a misleading equation - after all, it is the Humean position that is driven directly by the actual business requirements, while the Kantian position is based on reusing abstract constructs from elsewhere.

Mashups

So where do mashups fit into this story? In recent months, there has been a rapid growth of composite applications, based on apparently arbitrary combinations of online services such as GoogleMaps, Flickr, del.icio.us, and so on. (Philip Boxer has done some analysis of these interoperability landscapes for the Asymmetric Design blog.)

One of the explanations for this rapid growth is that such mashups can be produced very easily using new platforms such as AJAX and Ruby on Rails. But I don't think that the definition of mashup depends on using any particular technical platform. I also don't think that the basic concept of mashup is affected by the physical location of the mashup execution - whether on the client-side (browser) or on the server-side - although this is obviously important from a technical point of view.

Large numbers of simple mashups can be produced through bricolage. (Many of these are based on images, because this gets around some of the security restrictions of the standard browser.) But many of these I don't see as genuinely situated applications. They are produced from rational analysis of abstract domain knowledge, not from empirical analysis of context and situation. They follow an anticlockwise development path rather than a clockwise one.

From an enterprise point of view, the interesting mashups might involve composing real enterprise services - something like mixing SalesForce services with mySAP services. But this requires more than bricolage - it requires careful analysis of the semantic interoperability of the services to be mashed-up. This analysis will be situated (and therefore possibly not repeatable elsewhere) to the extent that my particular way of combining SalesForce with mySAP is grounded in the particular way I want to run my business.

Synthesis

• Not all mashups are situated. (However, complex enterprise mashups are more likely to be situated.)
• Not all clockwise software production is based on bricolage.
• Enterprise software is rightly suspicious of bricolage. But this is not a sufficient reason to reject situated software or enterprise mashups.
  
• The architectural challenge is not to replace anticlockwise software production with clockwise, but to develop higher-level platforms to support collaborative composition - allowing clockwise to be combined with anticlockwise.