For a start, there are multiple means by which I communicate with each beta tester - typically a combination of telephone, Skype talk, Skype chat, and email.  So the individual communications end up scattered about in various different places: my head, scribbled notes, Skype, and Thunderbird.  I try to record all interactions in a single repository, but this always means first having the conversation then writing it up (or pasting it in).  So inevitably some pieces of each conversation get lost, or collated out of sync.  If we were collaborating using a Human Interaction Management System (HIMS), such as humanedj itself, none of this would be an issue.  The technology underpinning each communication would be irrelevant, since all would be conducted via a HIMS that automatically recorded events.

Then there is the nature of each conversation.  Most people want to talk about two separate things:

1. Their experience of using the software - its strengths, weaknesses, what they would like to see added, and what they would like to see removed.
2. What sort of relationship they can expect with my company Role Modellers if they adopt the software - issues of licensing, support, partnering, and integration.

In HIM terms, these are separate "Interactions" (goal-directed communication channels) in a single "Story" (collaborative work process).  Keeping them separate has all sorts of advantages.  In particular, one can then involve different people in each Interaction: techies for the software discussions, business people for the relationship discussions.

Finally, collaborations tend to evolve over time.  Just to give one example, several of the beta testers have now decided they would like to collaborate amongst each other.  There are several such sub-groups forming - some in particular sectors, some organized geographically, some for the purposes of producing written material such as articles, some to investigate particular ways of jointly testing the software itself.  A few of these collaborations are being conducted via humanedj, though not all.  It would certainly simplify matters if the creation, merger and splitting of Stories was managed using humanedj - since otherwise those involved have only an informal idea of what is going on.  Using humanedj to conduct the Stories would not only facilitate the work itself and allow it to be automatically recorded (as described above), but make it amenable to management control - others in the organizations concerned would have visibility of the work, and a means both of controlling and of supporting it.

TAKE AWAY

Do the examples above sound familiar to you?   A software trial program is a typical example of what HIM calls a "human-driven" process.  Perhaps some of the tasks may be automated, but the work is quintessentially about people and their interactions.  With such work, you cannot say at the start how things will turn out - indeed, a fundamental part of the work itself is to establish how things will turn out.

With the rise of what author Daniel Pink calls "Asia, Automation and Abundance", such work is becoming more important than ever, as the only true competitive differentiator left.  Further, the new Internet-based communication tools have left us all drowning in a sea of messages from others - what I call network overload - that can be neither handled by individuals nor controlled by organizations, let alone leveraged properly for advantage.

We all need to structure our communications better - as collaborations, in which the individual Interactions are understood, separated out, and supported by a new generation of software tools.  Ask your software vendors what they are doing about HIM - and if their answer is unhelpful, ask yourself whether you are working with the right software vendors.

Posted by keithhb in Business Process Management • Internet • Knowledge Management • Management • Office Applications | Permalink | Comments (0)

Just consider the number of downloads of, for example, JBoss application server - an average of 150,000 to 200,000 per month.  The total number of deployments is of course less than the number of downloads, but even so, these numbers are off the scale compared to anything that BPM and SOA vendors could possibly claim.  How many workflow/BPM systems, from any vendor, have ever been implemented, worldwide, do you think?  I don't know the figures, but I do know they are not in the hundreds of thousands.  Low-level programming technologies are still the undisputed king of the enterprise technology backbone.

Following the articles published on this blog over the last couple of weeks, a number of people have written to ask me what sort of high-level technology approaches I would recommend to supplant BPM and SOA in their current forms.  I have tried in this blog, over the course of 2006, to explain aspects of the solutions required.  But it might be useful for to provide a few links from other sources that summarize where things are going. So here are some useful summary  articles.

Is There A Method To The BPM Madness (Sue Bushell of CIO Magazine, published on bptrends.com)

BPM - A Systemic Perspective (Janne Korhonen of EDS)

Business Process Management - The Next Generation (business guru Peter Fingar, writing on bpmg.org)

TAKE AWAY

Are you, like so many, frustrated by the products on offer from enterprise software vendors?  Does the marketplace seem to be a confusing mishmash of overlapping technologies, none of which bear clear relation to business needs?

If so, the best defense is offense.  Read the material above, then ask your vendors what they are doing about it.  It's time for the marketplace to speak up!  Muttering to each other over a coffee at conferences is not going to change anything.

And don't be blinded by science!  If you find the nature of - and benefits offered by - a software product hard to grasp, then you probably don't need it.  In fact, software vendors know this already, since despite the glossy Web ads, most are now struggling to stay afloat in a crowded marketplace.  It's the perfect time to make your views felt.  If you want something better, you need to ask for it.

Posted by keithhb in | Permalink | Comments (2)

My post last week, on "business processes" and "business services" that bear no true relation to the real world, attracted a good deal of comment - not just to the blog itself but also on the leading SOA mailing list, on which an excerpt from the article was republished by the moderator.

This is exactly what I had hoped would happen.  Many readers of this blog, and people on the SOA list, are in a position to offer software users something better, so I am trying to get the message across to at least some of these vendors and standards committee members.

However, the comments showed that many people misunderstood what I was trying to say.  Mea culpa, of course - I should have explained myself better.  So here is an extended discussion, that I hope will make things clearer.

If you are a user or developer of BPM/SOA tools:

• First read the original article, if you haven't done so already
• Then follow the discussion below.

In a year or two, the impacts of the new tools you are currently implementing or building will start to make themselves felt.  And this may well make the difference between success and failure for your organization as a whole.

BASING PROCESSES AND SERVICES ON BUSINESS OBJECTS

It is quite extraordinary that, despite the advances of the last 20 years in management theory, so many people in the IT community still feel that business reality can be expressed as a set of activity sequences.  A typical outlook is that a business is comprised of what Hammer and Champy termed "functional silos": Finance, Manufacturing, Sales, Servicing, and so on.

This description of business operations is what enlightened management consultants have been trying to change since the late 1980s - trying to move business people to a more useful perspective based on processes. And a process architecture is not a value "stream" or "chain" - what author Martyn Ould derides as the 5-bite kebab:

Martyn Ould's "5-Bite Kebab" - (c) Venice Consulting Ltd 2006

Rather, as Martyn points out, a process architecture is a network of objects and interactions: different for every type of organization.

The real world isn't sequential at all. Processes or services may often be treated as activity sequences, in the belief that this is a useful abstraction from reality: a simplification of reality in order to get a handle on it.  However, as abstractions go, it is a very dangerous one.  The sequential approach may be easy to implement for vendors, especially those with legacy products to repurpose, but it is highly inaccurate.  Treating processes or services as objects is a much more helpful and valid abstraction of organizational life.

For example, in real life a customer has a relationship with a supplier that is not simply defined by a sequence of ordering, shipping and payment activities, but encompasses more complex things such as having an account (which may include standard requirements, payment options, etc.), making overlapping requests (the output of which may be delivered together), specifying delivery details (which may be to a third party), and so on.

In fact, it is fair to say that activity sequences are "more abstract" than objects. In other words, they are an abstraction that is further from reality. They are so far from business reality that, used as a high-level modelling technique, they present a serious risk to organizational health.

IT people are well-versed in object-based techniques, and current IT tools do use them - but only behind the scenes, for implementation of the process and services that users are forced to design as activity sequences.  But there is no reason at all to restrict the use of an object-based abstraction to programmers!  All vendors have accomplished by forcing sequential tools onto business people is to make them think that such tools are poorly designed.  I deal with a lot of non-technical business people (users and consultants in particular) and they almost all feel that BPM/SOA tools bear no reality to the world they know. They use these tools because (and only when) they have to, not because they want to.

This is because business people naturally conceive of their organization very differently to a set of activity sequences. Just ask any CEO about the long-term relationships (s)he is trying to build with customers.  So what we need is to provide business people with tools that let them model the world the way they truly understand it. It's no use saying that behind the scenes everything is object-based - that doesn't help the business at all.  The issue here is not about implementation of software tooling, but about the design tools presented to users - which is all that business people see. Designing processes or services as activity sequences does not ring true with business people - and they're right to be suspicious of it, since in real life very little happens in this way.

IT people tend to think that business people are incapable of understanding objects. Well, in my experience it's the other way around. Business people naturally understand the world as a dynamic, evolving, adaptive network of interconnected things - but IT people naturally retreat to sequential design techniques, probably since tools are easier to build if constructed along these lines (especially if you are a software vendor with a back catalog to leverage). It's the IT community who don't "get" the value of object-based design in this space - not the business community.

Further, it makes no difference whether processes or services are to be implemented from scratch, or via reuse of legacy applications.  A main aim of both BPM and SOA is to make the implementation of processes and services completely transparent to users. It is user-facing design tools, not software implementation techniques, that we are discussing here - and it is important to understand the type of design in question.  There's a difference between physical design (how to go about the nuts and bolts implementation of software code) and conceptual (aka logical) design.  Conceptual design is what, with BPM and SOA, users see - and it is the basis not only for their interaction with IT, but also for how they make use of computer systems, and and how they re-shape their business operations around those computer systems.  It's very important to have both sorts of design, and not to confuse them.

It might be that the physical design is based closely on the conceptual design.  If so, software tools could be used to help generate one from the other semi-automatically. Alternatively, the conceptual design might be so high-level that there are several layers between it and any physical design that is used to generate software code: the physical design might include several existing packaged applications, for example.  In this case tooling may not be able to do quite as much for the user.

However, such questions are not my main subject here.  What I am saying now is that a set of activity sequences is a very poor basis for conceptual design. A much better approach would be to allow users to define the business objects in which they are interested.  This does not mean exposing a horribly complex set of object models to users - programmers might need such models to build the underlying code, but users should be protected from these gory details.  Rather, we need to provide BPM/SOA users with design tools that let them capture and visualize, in a simple way, the business objects with which their organization is concerned.

What I am talking about is a better way to conceptualize business process and business services - a way that matches more closely the reality of organizational operations.  So that you know I practise what I preach, in my own work I am trying to provide free software tools that do this for human collaboration - "human-driven" work processes.  What I am calling for here is for similar tools to be made available for "mechanistic" BPM and SOA - business operations that are automated, or in which human involvement is limited to key decision and data entry points.

TAKE AWAY

The BPR disaster of the 1990s may well be happening all over again for organizations investing in BPM and SOA, as they invest heavily in a simplistic, inflexible approach to business operations.

Yet basing the design of processes and services on business objects is not more complex than basing it on activity sequences - it is easier!  For business people, object-based design is how they naturally think: about assets, staff, product catalog, inventory, customers, and so on. All these are objects, not functions. Trying to get business people to categorize their world as a bunch of functions is forcing a square peg into a round hole.

Further, I'm not arguing that existing BPM/SOA techniques should be abolished (in most cases, anyway). What I am suggesting is that there is an entire layer missing - an object-based modelling layer. Unless this is put in place, BPM/SOA will end up like BPR - an approach on which the next generation pours scorn, wondering how its practitioners can have been so incredibly short-sighted.

There is still time to turn things around.  I am not proposing taking very much away, but rather, adding something new - a higher-level modelling layer via which business people can, with the support of IT people, describe the objects that are of interest to their organization.  If you want the current generation of software tools to work to your advantage, you need this layer, and you need it soon.

Posted by keithhb in Business Process Management • Management • Service-Orientated Architecture | Permalink | Comments (12)