I facilitated one of the last roundtables of on the conference, about Enterprise 2.0 and BPM mashups.
Mashups (considered a part of Enterprise 2.0) are lightweight integration of web-based services and data, often in ways that the service providers never intended them to be used; personally, I think that as mashup techniques get easier, mashups will become the technology of choice for what’s referred to as “end-user computing”, that is, all the stuff that is created within business units (typically now using Excel or Access) because it’s either too small for IT to take on as a project or they can’t turn it around in a timely manner. I see software-as-a-service BPM and other services as having an impact on the ability to do mashups, since these platforms are often designed with a bit more openness in mind.
I’ve looked a lot in the past at Enterprise 2.0 and BPM, and the features that are (or should be) creeping into BPM under the influence of Enterprise 2.0: RSS, tagging, SaaS, mashups, collaboration, and all sorts of user-created content in general. There’s a lot of challenges around this, many of the cultural, since Enterprise 2.0 decentralizes control of IT assets and requires a certain level of user participation.
We spent most of the session talking about BPM mashups, not Enterprise 2.0 in general. At one level, a BPMS can be considered to be a mashup platform, given the right business services available for assembly.
BPM mashups can take several forms:
- Lightweight assemblies of subprocesses and services
- User-facing information at a step in the process, e.g., Google maps mashed up with BPM data and presented to a user in a form in order to complete a task
- BPM as a component within a portal, possibly assembled by a user
Issues around mashup adoption include IT not trusting something that is user-created, and business analysts not understanding the concept of mashups as well as not yet having easy enough tools to do mashups. There are also issues around discoverability of services (as I discussed the previous week in a Mashup Camp session) and the use of internal versus external services, where both types require some sort of SLA to be included in any sort of production mashup.
By lowering the barrier to entry, mashups can play an important role as application prototypes, or emergent applications that IT wouldn’t have thought to build for the business; IT can learn from what the business creates for itself in order to create more structured applications and processes.This is similar to the concept of how a folksonomy is used to gradually become a taxonomy: allow the users to do it themselves, then observe and detect the patterns. My favourite phrase that someone used at this point was to “intelligently stumble upon the future” and the whole idea of unintended consequences of mashups, although there was some discussion as to whether is was closer to serendipity or Frankenstein. Along this line, we talked about how to keep bad things from happening in mashups, and agreed that the services and data to be mashed up had to be controlled in some way (by IT) so that, for example, someone couldn’t do an unindexed full text search on a multi-million record database.
Without a doubt, mashups enable agility in application development, and BPM stands to benefit from enabling all types of BPM mashups.
There was some discussion around whether business users/analysts were asking for this, and whether they really wanted a full mashup capability, or just some parameterized configuration. I think that they don’t even know what’s possible through mashups, and if they did, they’d want it.