We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

IT Directions

Keith Harrison-Broninski

Complying with rules is not the same as working to rule

Vote 0 Votes

In recent posts I have been looking at the issues, particularly of security, facing people who try to put support in place for human collaboration that crosses organizational boundaries.  In particular, though it is now widely accepted that a process-based approach is essential for structuring and managing work, existing workflow and BPM tools fall down when it comes to cross-organizational work activities.  And the underlying problem is that no one organization "owns" the process.

Standard process support tools assume that somewhere, there is a server hosting each "process instance".  In other words, the process itself is like a program, with which the human process participants interact, and which does a certain amount of work on its own to support them (typically carrying out automatable activities such as database updates or Web service invocation).  But when you have multiple organizations involved, each with their own systems, and more importantly, each with their own management responsibilities, where is this program going to "live"?

In some cases, one party to the process has enough leverage to lay claim to being the host - consider a large manufacturer, for instance, who may insist that smaller suppliers hook into its own systems if they want the business.  The manufacturer may not truly own the process, but they can force everyone else to act as though they do.  In other cases, however, no one party has such power, and all parties must work together in some more equable way.

This is the domain of what is called "choreography" - the definition of an overarching "public process", to which all parties sign up, and which includes a description of the interactions between parties but no detail of how the supporting back end activities will be carried out by each party.  However, choreography is very limited in scope at present.  Part of the problem is that current choreography techniques possess neither a standardized graphical notation that would permit the parties to visualize a process nor a standardized means of arriving at agreement on a process definition (though I have proposed the techniques of Human Interaction Management to fill both these gaps).  But this is by no means the whole problem.

A more significant issue is that choreography is about defining programs.  A process created using the techniques of, for instance, the W3C choreography language WS-CDL, is essentially a quite basic set of control flow structures (each party's role being defined like a procedural program), that interact at key points in precisely defined ways.  This is never going to capture the reality of human collaborative work, is it!  People work in flexible, innovative, adaptive ways that are totally unsuited to such descriptive techniques.  In particular, a large part of what people do when they work together is to discuss, periodically, what they are going to do from now on - in other words, they redefine the process itself on a regular basis.  This goes entirely contrary to the principles of process choreography - at least as currently supported by the IT industry.  At present, those tools that exist for choreography require you to go through an old-fashioned "design, code, test, deploy" cycle in order to implement something, and then expect you to leave it well alone for as long as possible.

The reality of how poorly the IT industry is doing in this respect is illustrated by problems facing those parts of the public sector responsible for maintaining law and order.  A typical case may well involve police forces, social services, legal bodies, educational institutions, mental healthcare, hospital services, and more.  How are the people in all these organizations supposed to collaborate using "programmatic" tools?  Apart from the rigidity of the processes that can be defined in such tools, which is no use at all in such a situation, each person works under quite specific constraints regarding, for instance, data protection.  There are complex rules regarding what information can be shared and with whom - rules which if broken have serious consequences.

Further, the people who work in such fields are chosen for their ability to judge a situation and develop an appropriate response on the fly.  They are not expected to work from a procedure manual, and would be failing if they did so.  Being expected to comply with rules is not the same as being expected to work to rule!


So what is the solution?  Clearly we need process support tools that are not only more adaptive, but that also allow the process instance to be spread across multiple machines.  Further, such tools must provide facilities for the people involved to define precisely what information they wish to share with others, who will receive it, when they will receive it, and under what conditions.

This latter facility can only be implemented by appreciating that keeping information confidential is not the same as concealing ownership of information.  A social worker may not be able to make the contents of a case file available to the police, but they would not wish to hide the fact that they have such a case file.  A process definition needs to support the definition of information, and sharing of that definition, without necessarily making the information itself available to all parties.

I will be discussing these ideas again in future blog entries.  And if you are interested in an implementation of these principles for support of collaborative processes, free enterprise-grade software will be available soon (and you are welcome to sign up for pre-release trial if you wish).

In the meantime, anyone responsible for managing cross-organizational work processes should at least be aware of these issues.  Anyone who has tried to use current workflow/BPM tools to support cross-organizational human work activities will tell you that it is a very painful, expensive, and unrewarding experience.

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