In my last post I promised to discuss mashups - in particular, how there is more than one type of mashup.
Let's start at the beginning - what is a mashup?
To help answer this, here are some pictures taken from publicly available presentations by the CTOs of 2 firms supplying software commonly used to create mashups, Coach Wei of NexaWeb and John Crupi of JackBe.
Coach Wei gives an overview of where a mashup sits with respect to SOA and Web 2.0, terming it "Enterprise Web 2.0":
Coach's principle is that a mashup is how you leverage back-end services, namely by applying a rich Web 2.0 interface in order to expose them for business use. John Crupi provides 2 pictures that explain this how this differs from previous approaches, which typically use portal technology. Here we see what John calls "Today's Content-Driven Web":
Here, by contrast, we see what John calls "Tomorrow's Data-Driven Web":
Essentially, a mashup moves the integration of disparate forms of information behind the firewall. By doing so, it becomes possible to add additional controls, not just for security purposes but also in order to connect data more usefully - for example, by showing on a single chart information that previously was displayed in separate "portlets" (i.e., separate areas of a Web page).
The growth of NexaWeb and JackBe testifies to the utility of mashup technology. However, the tools available today are just the start of the mashup trend. Why?
Useful as mashups are in their current form, software applications built in this way are essentially competing with process support systems as service consumers. Like mashups, both the BPMS (for routine, semi-automated work) and the HIMS (for human collaborative work) use services to implement business processes.
In practice, a current mashup can be thought of as equivalent to a step in a business process - a node in a BPMN diagram, for instance, or a Task in a HumanEdj Role. In fact, it would be quite possible to design a BPMS or HIMS process that incorporated one or more mashups in this way. However, at this point mashup and process tools are not integrated. For now at least, there is a clear division in the market between mashup creation tool vendors and process support system vendors, and this can only lead to problems.
Most organizations have come to accept that managing work activity better means managing work processes better. Hence they are using process techniques, and in due course most will adopt process execution software. If they are also using mashups, the consequence is that they will then have 2 siloed forms of design activity for "service-oriented business applications". As a result, features belonging really to processes will creep into mashups, and vice-versa.
In particular, processes of either BPMS or HIMS type tend to use data items to preserve their "state" - i.e., where the work has currently got to. For example:
- A BPMS process representing a product assembly might contain data items corresponding to quality check results, and use these to determine whether or not the product is ready to ship.
- A HIMS process representing a marketing campaign might contain data items corresponding to focus group results, and use these to determine whether or not the collateral is ready for release.
If such data items are hidden inside a mashup application, the process designer has two choices. They can duplicate the data items in the process definition - a redundancy potentially leading to error, even if the data is extracted originally from the mashup. Alternatively, they can try to avoid redundancy problems by insisting that the data is held only in the process - an articial workaround that restricts the usefulness of the mashup.
Like the Web, mashups will evolve. The next stage is surely to provide a means of integrating Rich Internet Applications with BPMS and/or HIMS processes, to permit safe sharing of data between applications and processes.
Such integration is likely to start with the HIMS rather than with the BPMS, since the processes that they deal with are very different. Processes for which a BPMS is suited are routine, repetitive and semi- or fully-automated. Human involvement in such processes is limited to key points, and takes the form of low-level data entry and decision-making. This is not the territory of mashups, which are aimed usually at higher-level knowledge work activities. Mashup activities are much more closely related to HIMS processes - innovative, collaborative, adaptive human work. It is HIMS processes that can leverage the rich content of a mashup, and hence it is here that the integration will probably start.
Returning to the theme of this post, there are essentially 2 types of mashup: siloed and process-aware. For now, mashup tools are siloed. However, in due course they will become process-aware via integration with HIMS technology - and once this happens, the combination of HIMS processes and mashup applications will be an extremely powerful way to leverage both Web 2.0 and your legacy infrastructure.