First, my apologies to regular readers of this blog for the 2-month gap since my last post.  Unfortunately, I wasn't able to spend this period indulging in extended sybaritic pleasures on a tropical beach - rather, it was devoted to preparing for release the first version of humanedj - "the free desktop personal productivity tool revolutionizing collaboration".

This software, which will remain free forever (and will become open source once it has stabilized), is available now in a "beta" version - production release is scheduled for early 2007.  To get a copy of the beta, you need to sign up for the "Humanedj Beta Testing Program".   Membership of the program is available to all, and the only obligation is to try the software and tell us what you think - the aim of having such a program is simply to let us engage with each tester personally, in order to get their feedback.

If you haven't got the time or inclination to test any new software, you might still be interested to take an online tour of humanedj [use Internet Explorer to view this].  The tour is a presentation showing the most basic function of the application, i.e., to gain structure and control over your messaging.  Anyone who read my last blog post, Email is not suitable for business use, will appreciate how important this is to all of us.  Humanedj does far more than shown in the tour - it is a complete process-based solution for human collaboration - but most people will start by using it for messaging.

I did take a few days away from software development to attend Process 2006 as a featured speaker.  Those of you who read Sandy Kemsley's recent blog postings will know all about this event.  You may have read there an off-the-cuff remark I made over a coffee to Sandy and Peter Fingar: SOA is just BASIC over IP.  My remark was flippant, of course.  But actually I was trying to make a serious point.

At Process 2006 there was a very wide range of speakers, from all over the world, discussing everything from process design techniques to gaining executive sponsorship to the nature of a mental model - so the event presumably reflected the main current thinking among BPM practitioners.  Yet it was surprising to observe that nearly all of the talks said pretty much the same thing:

BPM is not about implementing new software tools - rather, it is about changing management practice; and when it comes to the dirty work of process definition, just draw an old-fashioned flowchart, in whatever your favourite style happens to be, ideally on a large sheet of brown paper.

What are we to make of this observation?  It seems rather at odds with the size of the BPM software industry.

In fact, this view, so prevalent among BPM practitioners, holds the key to understanding why so many people in the Business Process field are resistant to new approaches, and new technologies.  The essence of the problem is that BPM (and, I will argue, SOA) have not kept up with the advanced systems thinking that is becoming standard among professional software developers.  As a result, people who end up using BPM tools tend to become disenchanted with the primitive functionality offered by such software - and end up thinking that they may as well stick to pencil and paper.

So what is the nature of this "advanced systems thinking" that is lacking in BPM and SOA tools?  In a word, object-orientation.  Many readers of this column will have some idea what this term means, but just in case, here is a quick overview of the history of programming before we go any further.  Bear with me - I'll keep it short!

Early programming techniques were what we now call "procedural".  Here is how one designs a procedural program:

• Start by working out what you want the program to do - its function
• Then break this into smaller chunks - subroutines - and carry on breaking down until none of the subroutines overlap, or are overly complex
• Join up the subroutines by saying which ones run - or call - each other, and when they do so.

This approach to programming was fine in its day - and with the advent of structured programming techniques from theorists such as Dijkstra, could even become quite sophisticated.  But procedural programming is fundamentally limited, and fundamentally flawed.  After all, what in real life proceeds in a neat sequence of chunks, and ends by satisfying a single well-defined purpose?  In my own life, very little - much as I might wish otherwise!  And the same is true for all of us, not only personally, but for the organizations we work for.

So the late 1960s saw the emergence of "object-orientation".  Here is how one designs an object-oriented program:

• Start by asking: what things, or objects, exist in this system?
• Then ask, for each object: what can it do? What functions, or operations, can this object carry out for the user?
• Finally, define the pieces of data internal to each object: the attributes it needs in order to perform its operations.

This, in a nutshell, is the approach to software construction that has led, over the 40 years since the emergence of languages such as Simula, to the incredibly sophisticated set of techniques (and accompanying tools) available to the modern software developer.  In particular, we have patterns, frameworks based on patterns, and development/runtime environments based on frameworks.  The power of such techniques and tools is immediately obvious when you compare a modern desktop with a green screen from the 1970s - or look at any Web page.  All modern user interface techniques depend fundamentally on object-orientation.

In fact, so do most other modern software applications, though this may be less obvious at first sight.  To a modern software developer, it is hard to overstate the importance of object-orientation, because defining software objects lets you create a "virtual" world inside the computer that corresponds closely to the world outside the computer.  After all, the real world contains objects, each with purpose, function and properties - well, so should the virtual world!  Otherwise the real world and the virtual world do not, and cannot possibly, relate closely to one another.

However, enter the world of BPM - or SOA - and you are right back in the early 1960s.  It's as if object-orientation never happened.

Mainstream BPM tools, whether for modelling or for execution, all operate on the same fundamental basis: joining up individual activities into a sequence, with branch points and looping here and there as necessary.  Some of the activities may be carried out by machines, some by people.  But in the end, what you are doing is exactly what an old-fashioned procedural programmer does - starting with a function, breaking this down into chunks, then joining up the chunks.  Some BPM languages and tools let you run streams of activity in parallel - but this is only putting procedural programs side-by-side, not making them object-orientated.

Similarly, SOA tools are all based on the procedural principle.  To most SOA architects, a service is just like a procedural program - it offers a single function that can be invoked on demand.  It was fascinating to read a discussion on the main industry SOA mailing list recently, in which most of the experts argued that object-orientation was actually unnecessary for SOA, or even antithetical to it.  What?!?  How can these people - senior, experienced and well-respected software developers every one - have got it so wrong?

The effect of this procedural outlook among BPM and SOA vendors and consultants is that "business processes", as defined using BPM tools, and "business services", as defined using SOA tools, cannot possibly bear any true relation to the real world.  They may in certain cases get some things done quicker, or cheaper.  But the things they are doing are not the same things that business people are interested in.

Business people are forced to live in the real world - unlike programmers, it's the only one they've got.  So business people tend to look with suspicion on systems that don't match the reality they know - and this includes any procedural system.  No business is made up of a "stream" or "chain" of processes, any more than it consists of a "repository" of services.  These are simply convenient fictions - convenient for consultants and software vendors, that is.  In reality, businesses are complex, inter-related, continually evolving networks.  Every business person knows this instinctively, and sees it proved again to them every working day as they engage with customers, suppliers and colleagues.

TAKE AWAY

I will have more to say about the IT/business divide in future blog entries.  In a spirit of fairness, commentators on this topic have often tried to lay the blame equally on both sides.  But it's time to recognize that, when it comes to BPM and SOA, the IT community is doing the business community a monumental disservice - the more so since there is currently little understanding on either side of the mess that organizations are getting themselves into with these new tools.

BPM and SOA may have enabled some organizations to reduce costs and improve productivity.  But what has been lost in the process?  Quite possibly, a true understanding of what your organization is, what it does, and what it is there for.  And the impacts of this loss will soon start making themselves felt.

If you are concerned by the mismatch between the real life of your organization and the IT environment being constructed to represent it, you need to start taking an object-oriented view of what is going on around you.  And this means adopting process architecture and process modelling techniques based on describing interconnected things - not on defining isolated sequences of activity.

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