IT Directions

Keith Harrison-Broninski

Mashups and processes

Vote 0 Votes

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.


You are dead-on about the need to include human-centric process within mashup applications. However, I think you are wrong about having to wait for HIMS and mashup to converge. There are already two mashup tools that include strong human process: ActiveGrid and Serena Mashup Composer.

See my post for a discussion of why I think these two vendors actually meet your mashup-plus-process requirements.


Kelly A. Shaw, Ph.D.
Serena Software

Thanks for this, Kelly. I understand your point. In fact, I don't think we differ as much as it might seem.

We agree that process and mashup technologies need to become integrated. You are saying that this has already started, in particular with your company Serena's "business mashup" offering. So I had a look at your Web site, and found this summary:

How can business mashups help me?
Can you think of some small applications that would help drive new business or make your operations more effective? Don’t you wish there was a way you could build these applications yourself, without having to wait for or rely on IT? That’s exactly the purpose of business mashup. They allow you to create automated processes, tie these processes in with multiple back-end or cloud-based systems while providing the unified experience we’ve all come to expect from mashups.

In other words, your company has started to integrate what I call "mechanistic" processes with mashups. All well and good, but for most business people, the real value of process/mashup integration lies in the other kind of processes, what I call "human-driven". And before you reply that Serena has plans to offer support for Forrester's "human-centric" processes, or does so already, these are not what I am talking about. Forrester's "human-centric" processes are simply a subset of my "mechanistic" processes.

In brief, mechanistic (including human-centric) processes are repetitive, routine, semi-automated work in which human involvement is limited to key data entry and decision making points. By contrast, human-driven processes are the sort of collaborative, innnovative, adaptive human work done by readers of this blog. See my last BP Trends column for a full explanation.

All the best

Keith Harrison-Broninski cuts through the hype in his hands-on guide to where enterprise IT is really going

Keith Harrison-Broninski

Keith Harrison-Broninski is a researcher, writer, keynote speaker, software architect and consultant working at the forefront of the IT and business worlds.


 Subscribe in a reader

Recently Commented On

Monthly Archives