Christmas is coming so it seems appropriate to return to some reflections I made a few weeks ago, on parallels between enterprise technology and church architecture (see Mediaeval middleware and Stress-Oriented Architecture). And it seems I am not the only person making this connection.

Frits Bussemaker, founder and chairman of the Dutch BPM-Forum, wrote to me last week to ask whether I had an answer to a question he posed back in July, via his BP Trends column Gaudi & Gravity. Frits reflects on Gaudi's astonishing architectural masterpiece, La Sagrada Familia in Barcelona. Anyone who has seen this building cannot fail to be astonished - even today it is like nothing else. Personally I think it very beautiful. Images don't do La Sagrada Familia justice, especially now that construction works aimed at completing the building fill the background with cranes (Gaudi himself never managed to build the entire cathedral), but here is an aerial photo from before works started:

By contrast, George Orwell hated La Sagrada Familia. I have just finished re-reading his "Homage to Catalonia", and was surprised by his description of Barcelona's cathedral as "one of the most hideous buildings in the world". He writes, "I think the Anarchists showed bad taste in not blowing it up when they had the chance" (p.214, Penguin edition). Orwell really could be an old grouch sometimes.

Frits discusses how Gaudi "used the law of gravity to model and create this impressive and complex building in the real physical world", and asks:

Is there an equivalent for gravity in our imaginary world of IT, organization, and processes? If there is such an equivalent then we probably would have some very simple principles to shape our complex imaginary world.

Frits posits an answer as follows:

I suspect that the business process is the rope in Gaudi’s model and entities like competitors, shareholders, regulations, and, most important of all, clients will pull an organization into its optimum shape.

I agree with Frits that the "rope" binding together stakeholders in an organization is processes. However, I would add that these processes are not the kind that I call "mechanistic", but rather the kind that I call "human-driven".

Mechanistic processes are like the services of a building (electricity, heating, plumbing, etc). They seem vital, but you can manage without them if you have to. Orders can be taken, invoices created, payments processed and goods delivered by hand if necessary.

In fact it is the human-driven processes (collaborative, adaptive, innovative human work) of an organization that are the infrastructure. Imagine an organization in which no-one was making sales, dealing with customers and suppliers, assigning staff, managing work, signing off payroll, resolving issues, ... - everything would fall apart immediately!

TAKE AWAY

One of my first white papers, back in 2004, reminded people that:

An organization in which people interacted only via scripts loaded into machines could not think, could not respond, could not change and could not possibly provide effective support for its customers.

The trouble is, without Human Interaction Management (HIM), it is not obvious what such interactions consist of.

There is growing recognition that in today’s wired, globalized world, most routine work is being standardized, outsourced and automated. In other words, all that organizations have left to compete on is the interactive knowledge work (what I call “interaction work”) that is left over. HIM provides a means of doing such work more efficiently, and managing it better.

HIM also offers the opportunity to overcome the inherently fickle nature of Internet trading by binding your customers into shared, long-lived, collaborative processes. This is the route towards what Pine and Gilmore (authors of “The Experience Economy”) call the “fifth economic offering”: transformations.

Returning to Christmassy matters, one can make an analogy with modern business and the progress of a pantomime. We are currently approaching what is called the "transformation scene" - a moment when the protagonists get themselves out of trouble by discovering some device that allows them to enter a new and exciting world. The trouble is "Asia, Automation and Abundance". The device is Human Interaction Management. And the new and exciting world is what Information Age herald as follows:

A new generation of people-centric collaborative information management tools is set to produce the first fundamental advances in personal productivity since the arrival of the spreadsheet.

A very Merry Christmas and Happy New Year to you all.

Posted by keithhb in Business Process Management | Permalink | Comments (2)

This morning a colleague pointed me to a blog post by Dion Hinchcliffe, Leveraging Web 2.0 for business growth. Hinchcliffe, like many other pundits at the moment, paints a rosy picture of the new world of work that will be enabled by Web 2.0 technologies. The trouble is, this new world will only be rosy for a very few people indeed.

Hinchcliffe has picked up on the analyst firm McKinsey's term "tacit interactions". This term was described at length in their article "The next revolution in interactions", published in the McKinsey Quarterly, Q4 2005. The authors use the term to describe a particular form of collaborative knowledge work:

the searching, monitoring, and coordinating required to manage the exchange of goods and services

They go on to write:

Currently, jobs that involve participating in interactions rather than extracting raw materials or making finished goods account for more than 80% of all employment in the United States. And jobs involving the most complex type of interactions - those requiring employees to analyze information, grapple with ambiguity, and solve problems - make up the fastest-growing segment. This shift toward more complex interactions has dramatic implications for how companies organize and operate.

The authors conclude:

The shift from transactional to tacit interactions requires companies to think differently about how to improve performance - and about their technology investments. Companies can again create capabilities and advantages that rivals can't easily duplicate.

I agree whole heartedly with all this, and often quote the above words in support of my own work on Human Interaction Management (HIM). So it is good to see other writers quoting it too! However, when it comes to implementing the "shift from transactional to tacit interactions", Hinchcliffe (along with many other writers in love with all things 2.0) is looking in the wrong place.

Hinchcliffe, for example, describes the new wave of BPM tools as a means for people to implement their own lightweight process support for tacit interactions. However, consider this quote, taken from the article defining "BPM 2.0" to which he himself links:

BPM 2.0 is not for non-technical business analysts. Never should have been, never will, and nobody should care.

Indeed. BPM is for technicians, and this applies whether you are talking about version 1.0, version 2.0 or version 99.0. And it's not me saying this, but the software vendor (Intalio) who defined the term "BPM 2.0"!

So what about all the business people whose work is all about tacit interactions, but who could not reasonably describe themselves as "technical business analysts"? If we take Hinchcliffe at his word, this community is excluded by definition from the new and exciting Web 2.0 world. And I should think that this community includes about 99% of knowledge workers.

TAKE AWAY

The new world of work is exciting. Too exciting to leave it all to the techies! Web 2.0 tools are powerful levers for business growth, but efficient and effective use of them requires support for "tacit interactions" - i.e., a new form of business process.

I call this new form of business process "human-driven" - a term that should not be confused with the "human-centric" processes that are often discussed by analysts such as Forrester and are now supported by various BPM tools. Human-centric processes allow humans to interact with machines, typically to enter data or make low-level decisions, and have become mainstream. Human-driven processes are another thing entirely - they are a higher-level type of beast, and support for them is still emerging.

In particular, human-driven processes include interactions between humans and other humans, which requires new ideas and new tools. If you want to be part of the new world of work, BPM will not help you (whatever the version) - what you need is HIM.

Posted by keithhb in Business Process Management | Permalink | Comments (0)

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.

TAKE AWAY

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.

Posted by keithhb in Service-Orientated Architecture | Permalink | Comments (2)