« Documentation made simple | Main | Controlling distributed business processes »

One thing on which most people involved in business would agree is the need for some mechanism for collaboration with partners.  What does this mean in practice?

Go to your software vendors for an answer and you will hear something like this: "ah, what you need is a means of implementing distributed, transactional processes".  In other words, start using our Business Process Management (BPM) tools - i.e., get ready for a very serious investment of time and money in a series of long-running IT development projects.  The aim of this exercise will be, for example, to create a networked, just-in-time supply chain or to set up automated delivery logistics.  Such processes may require humans to be involved here and there - for example, to make decisions at key points, or enter data taken down from a telephone conversation.  But the work involved is largely about automating things, at least as far as possible.

This is powerful stuff.  But does it genuinely answer the original question?

Surely collaboration is about rather different things; things such as:

• Negotiating with others - both inside and outside your own organization - to arrive at a set of shared, agreed goals, together with working processes designed to achieve these goals
• Putting in place mechanisms to decide on who will be involved in the work, help them get started, and support them while they see it through
• Integrating the work with management practices and executive policies
• Continually revisiting all the above to ensure that it meets current business needs.

It is fair to say that the latter form of collaboration - that we might call "human-driven" as opposed to "mechanistic" - corresponds more closely to what, in the minds of most people, business is all about.  It certainly makes more of a difference between success and failure.  You can have the best supply chain in the world, but if no-one is buying your products, it won't do you any good.

I have written before in this blog about what it means to support human-driven processes.  In this next series of postings, I will try to address a particular aspect of this question.  How can one ensure that personal collaboration across the Internet is secure?

Many people have addressed issues of securing back-end systems, even if access to these systems is provided via (for example) Web services.  Andrew Townley provides a useful summary in his blog, for example.  Yet such techniques do not help at all when it comes to a world in which interpersonal work processes are distributed across the Internet.  In such a world, no-one "owns the process" - and what is more, no-one can prevent it from changing, continually.  This brings issues of authentication and authorization that are beyond the scope of current approaches to system security.

TAKE AWAY

In this next blog series, I will show how the root of this massive security problem is that organizational applications (and data) are mostly located on servers - whereas they should be located on clients. 

Does this sound crazy?  If you are locked into the perspective of current tools and techniques, you may be thinking that it sounds far-fetched.  But my guess is that, in a few years, we will be wondering how anyone could possibly have thought it was a sensible idea to try and centralize such controls over working life.

If you want to succeed in the new economy, you have to let go of some assumptions.  The main one of these assumptions is that individuals are not suitable guardians of a trust store.  By contrast, the only way to create a safe, Internet-scale computing fabric is to give people (as well as organizations) the ability to create and manage their own trust stores - trust stores in which your working partners are assigned not just an identity but also Roles in specific business processes.

If you are interested to see why this is true, how it can be implemented, and how it can be safely controlled - stay tuned.

Posted by keithhb in Business Process Management • Internet • Management |Digg This|Add to del.icio.us