The trick is to recognize the reality of how people work together - and use that as the basis for a structured approach to managing their activities.

Let's take a typical scenario. A design team is in the middle of a large concurrent design project, and an unexpected issue has arisen - sufficiently serious to warrant specific management attention, and potentially impacting several design areas (database, user interface, security, and so on).

Meeting to discuss the problem, team members realize that a new sub-project is required to manage the issue. Initially they have no plan or structure for this new sub-project. The input to the sub-project is itself a problem definition that may require further investigation and development. However, there are a number of significant things that they can say from the start. They may have none of the detailed elements of a process, but they are able to recognize a pattern. They know how collaborative problem solving generally takes place.

The pattern they recognize for collaborative problem solution has specific aspects that allow us to model it, at a high level, as a process:

1. The people involved will perform certain Roles, each with their own goals and responsibilities. There will be a number of participants in the solution process, with skills in different domains - database design, user interface design, security engineering, and so on. For each type of contributor, there may well be distinct phases of activity: problem definition, concept design, detailed design and testing, integration and testing, and so on. Hence, the sub-project is in fact composed of multiple distinct streams of activity, one for each domain. The contributions of all these have to be coordinated.
2. The eventual deliverables will meet certain preconditions. If successful, the output of the sub-project will be a solution, probably consisting of a set of solution components in different domains. The solution components in each domain will include models and tests that demonstrate that the solution solves the defined problem. There may well be interface specifications and other supporting documentation. Among all these objects there will be varied dependency relationships. Hence, the components of the solution both at domain level and overall are an interdependent set that must be protected from further change unless the whole solution is revisited and retested. The set of solution components can be viewed as a transaction - somewhat like a database transaction, although subject to quite different rules in which all sub-project participants commit jointly to the resolution of the issue.
3. The process participants will interact in a way to ensure that their individual contributions combine to produce overall deliverables of the highest possible quality. The components of each domain solution must be made available to an appropriate person for integration into a unified domain solution. Similarly, the domain solutions must be made available to an appropriate person for integration into a unified overall solution. The individual domain solutions and the overall solution must all be validated and certified by an appropriate authority, and this activity must be linked to the aforementioned integration.

With this analysis in mind, we can use a Role Activity Diagram to represent the sub-project as a whole:

TAKE AWAY

You may be reading this because you are responsible for a large-scale software development. And you may be wondering how the diagram above is going to help you. Is it the magic bullet you need? If so, why?

If you do not find the diagram above self-explanatory, this is because it draws on concepts from Human Interaction Management. Before you can understand the diagram, you need to understand the concepts.

In the next instalment of this series, I will explain 3 different perspectives from which the diagram can be viewed:

1. Management
2. Participant
3. Solution

Armed with this understanding we will start to see how even the thorniest - and scariest - problems in large-scale software development can be tamed. Complex problems can be broken down into a set of simple ones, so that management controls can be applied and the required solutions delivered.

If this sounds like what you need, tune in next time - and if you can't wait, you can always get the book :-)

Posted by keithhb in Management • Security • Service-Orientated Architecture | Permalink | Comments (0)

• Analysts have a lucrative business in providing feature comparisons, advising vendors which new functions the market would be most interested in, and helping organizations select from the bewildering array of products on offer;
• Consultants have built a niche helping organizations choose, implement, and maintain these beasts - what a French consulting company with whom I once worked referred to disparagingly as "pousse-bouton" work;
• Enterprise architects charged with business process implementation are able to divest themselves of responsibility by laying it on the shoulders of software product vendors and their promises;
• Software product vendors have found a new market, often for a mixed bag of legacy or bought-in products that they can assemble, revamp, and re-purpose as a BPMS suite.

Nevertheless, it can't last forever.  The major vendors in IT are already owning up to the imminent death of the BPMS implicitly, not only by incorporating BPM functionality into monolithic middleware suites (Oracle, SAP, IBM, etc) but even into the operating system itself (Microsoft).  As I pointed out in my last post, published research from IBM shows how to implement business processes without a BPMS at all.  And here is what David Frankel of SAP has to say about using Model-Driven Architecture (MDA) for business process implementation on bptrends.com this month:

Model-Driven Service Orchestration

Often times, developers trying to get a handle on MDA approach it with the thought that they have
to use it to generate the components of their applications, or at least to generate fat skeletons of
the components, to which programmers add some finishing code. Then they run straight into the
last mile struggles with legacy back end systems that hold so much of the data in non-normalized
form.

Some of the most successful approaches that I’ve seen take a different route to nailing down the
last mile with MDA. They use service-oriented architecture (SOA) to present existing application
functionality as a set of service components whose interfaces are highly normalized via
consistent use of service interface languages such as Web Services Description Language
(WSDL). They use modeling to define specific orchestrations of the services. They walk the last
mile by compiling or executing the orchestration models.

In sum, this approach deals with the last mile problem that non-normalized back end systems
pose, by using SOA to provide a normalized intermediate tier that model compilers and model
execution engines can target in a consistent fashion.

In other words, Frankel is saying that you can use MDA to execute mechanistic business processes via SOA.  Draw your business process models, using whatever notation you like as long as it can generate code - UML is fine, for instance.   Then connect your code to services via WSDL.  That's it.  You can use a BPMS if you wish.  But you don't need to.

TAKE AWAY

Some people are attached to BPMS tools because of the wide range of features they typically offer - for messaging, reporting, configuration, and so on. However, tempting as such goodies may be, their use is not in any way related to increased business success.

In fact, there is a strong argument that adoption of multi-functional workplace tools has exactly the opposite effect.  A wide range of features and options often does little but distract people and muddy the waters.  Being bombarded by information from every side and in every form imaginable is a primary cause of stress - when you add multiple forms of messaging to multiple forms of reporting you get what I call "network overload", which is even worse than information overload.  On top of this many organizations are now using sophisticated workplace tools to transfer system administration responsibilities that properly belong to the IT department - authentication and authorization, for example - to end-users who are neither adequately qualified nor adequately resourced to handle such tasks.

What I see is that the net effect of introducing ever more highly powerful applications into the workplace has simply been to obscure individuals' true business goals and responsibilities.  How many people feel that they are running to stand still these days?  Or even just trying to keep their feet on the ground in the face of a tidal wave of information from all sides - and the demands for response generated by such information?

What the IT industry should be delivering is agile tools - agile in the sense of just-good-enough.  On this basis, the rise of programming techniques based on Model-Driven Architecture will, for many organizations, make a BPMS unnecessary.

For a start, an MDA approach is far closer to the original Third Wave ideal for BPM than the current generation of BPMS tools, since mainstream MDA tools such as Eclipse EMF are based on a simple, general, robust underpinning - unlike any current BPMS products!  It could be argued that the OMG MetaObject Facility that underpins EMF is the closest we currently have to the sort of generic framework envisaged by Smith and Fingar in their seminal 2003 book.

More importantly, MDA makes it possible to define your business goals, then implement processes to support them as quickly and simply as possible - and go round the loop again each time the goals change, as they do continually.  So why do you need anything else?  KISS, as they say.

Happy Easter.

Posted by keithhb in Business Process Management • Management • Office Applications • Security • Service-Orientated Architecture | Permalink | Comments (8)

In recent posts I have been considering what sort of software is required to properly and securely support human collaborative work - and giving examples of situations in which current tools and techniques fall down.  Here's one with which we are all familiar, yet which is in fact completely inappropriate in any real sense: the use of email to conduct a "business interaction": a conversation, dialogue, discussion, negotiation or any other set of inter-related work communications.

Email must be far and away the most common of all Internet business tools, more so even than the Web.  Not every company offers a transactional Web site, or uses such sites to do its own business.  But they all provide their employees with email and expect them to use it.  It is surprising, then, that when you actually start to think about it, that email turns out to be incredibly ill-suited to business use.

For a start, email is dreadfully insecure.  Some companies provide their employees with secure messaging services, but many more don't.  In general, emails are plain text communications that can be read by any intermediary as they travel across the Internet.  Further, you don't even know who is reading the email once it gets to its destination - it could be the person you address it to, or it could be their PA, or someone else who they have asked to check their email while they are out of the office.  It could also be an IT staff member with privileged access to the email system, or any superuser charged with maintaining it.

Email has in fact many technical security problems with falsified headers, corrupted attachments, and so on.  But let's put the insecurity of email aside, since it is such a huge and obvious problem - and look at some of its more subtle and interesting problems - ones that are business-related rather than technical.

First, there is tone.  In the early days of the Internet, its users recognized that email brought with it problems of emotional content.  Basically, when you write something you do so with an attitude - which may be anything from humorous to gently reprimanding to insistent to deferential.  The trouble is, the person reading it doesn't always interpret your message in the same way you meant it.  It is very easy to mistake the emotional content of an email, which is why early Internet users developed a concept of "netiquette" - a set of practices that enabled parties to a discussion to make their intent clear in terms both of logical and of emotional content.  These days, however, the use of email has spread and netiquette has vanished.  I've seen many an email discussion that would have been cordial if carried out in person deterioriate as the people concerned misread the tone of messages from each other.  And this can have serious business impact.

Second, there is involvement.  The people engaged in an email interaction tend to change as the conversation progresses.  Often people are CCed by one respondent but not by another - sometimes deliberately, other times just because a party presses "Reply" instead of "Reply All" by accident.  This gives rise to all sorts of thorny problems, not just of politics and wounded feelings, but very practical things such as people expecting someone to know (and act on) something that they were in fact never informed of.

Third, there is sequencing.  People tend to work through their inboxes in date order - oldest first.  So how many times have you replied to an email, promising certain actions, then realized there was a later email (perhaps not even from the same person) which renders your response inappropriate or even unnecessary?  To avoid this problem, I try to consciously force myself not to reply to anyone at all until I've read all my emails, which is a tiring and unnatural way to work.  Effectively, you end up reading everything twice, since once you've worked through your inbox once you have to start all over again - and hope that another email doesn't arrive while you're doing so!

Fourth, there is filing.  How do you file your emails?  Myself, I try to put them in folders, organized logically, but often the subject matter of the folders.overlaps.  Do you put a message from a consultancy client about a technical issue under "consultancy" or under "technical"?  Do you keep each client's email in a separate folder or organize it by "type" in some way?  Not only do such filing strategies rarely work as you would like, but they are also incredibly laborious.  It takes ages to set up and maintain the rules that assign messages to folders, and even then you end up doing some by hand as most email systems file incoming but not outgoing email.  One solution is just to leave everything in a default inbox and rely on search tools, but then what do you search on?  Every email has different keywords.  We're into the rarefied domain of what is called "latent semantic analysis" - and all we need is to store our interactions with people in a sensible way!

Fifth, there is the biggest problem of all.

Email is so easy to use that it's easy to overlook how for many people it is more of a problem than a convenience.  In a corporate environment, it is not unusual to receive hundreds of  emails per day, which both reduces productivity and increases stress. As they say, for some people email gets in the way of their work - and for the rest, email is their work.

Why do we all get so many emails, more than we can reasonably be expected to deal with? Because we never get the chance to specify exactly the messages we are willing to receive.

For example, many people routinely "CC the whole world" as a means of dealing with an issue that crops up - partly since it is easier than working out who exactly needs to know about the issue, and partly to cover their own backs. And the impact of this very common practice is enormous. Faced with an inbox full of such blanket postings, you are nevertheless forced to read each one carefully, since you can never be sure that the one message you skim, or skip entirely, is the one that raises a business problem for which you will later be held responsible. Far from increasing co-operation amongst colleagues, unrestrained messaging not only reduces productivity but also fosters a culture in which people are encouraged to offload issues onto others - rather than a culture in which people are motivated to personally ensure solutions

Similarly, when someone has a question that needs answering, the general assumption in a modern workplace is that one can just fire off an email to get the information required. No matter that the recipient(s) may already be drowning in work, or may not be the best people to ask anyway - simply by receiving an email, they each take on the responsibility to respond, even if it is only with a suggestion that someone else would be better placed to help out.

TAKE AWAY

The underlying problem with email is that people are rarely clear about who they are working with, and on what, or who is the best person to approach in a given situation. There is no clear visibility of shared and individual goals and responsibilities, so people deal with things in a variety of unpredictable ways.  For instance, they may spread the net as wide as possible, and include anyone that could possibly have a tangential interest - with the result that everyone's workload increases, general efficiency drops, and stress levels rise.

The only way forward is to provide a simple means for people to declare what exactly they are interested in, and what exactly they are responsible for - i.e., software tools that facilitate a more intelligent form of human collaboration.  Email does not provide this, and is never going to provide this.  It is a low-level protocol that should underpin more business-oriented tools for human collaboration.

And once we get such tools, perhaps we'll be able to get more work done, with less stress - and still get home in time to see the kids.

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

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!

TAKE AWAY

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.

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

If you've been following this blog series on improving the security of collaborative work - congratulations.  You're still here!  I am well aware that the ideas presented so far not only run counter to accepted IT wisdom, but challenge assumptions so basic that no-one even bothers to voice them.

The assertion outlined in the previous postings is that securing work carried out across a "distributed network" - a network owned by no single participant in the work, like the Internet - is not being approached in the right way at present.  Why?  Because the nature of such a work process is to change as it goes along.

Securing any IT system at all is an immensely hard problem, for a number of reasons - the varied nature of possible attacks (ranging from "social engineering" to cryptography), the resource cost involved (both human and technical), the fact that new attacks are constantly being devised (by a highly efficient hacker community), and more.  However, in spite of this, if you are willing to try, it is possible to secure systems and keep them secured - unless, that is, the systems in question are changing under your feet the whole time.  And this is the exact nature of collaborative work.

As I have discussed on many previous occasions, both in this blog and elsewhere in my writing on Human Interaction Management, collaboration between humans involves repeated change to the process itself.  Much of what we do when we work with other people is to ask, "how should we proceed from this point forwards?", agree a means of doing so, and start putting it into practice.  We go through such a cycle again and again - in most work processes involving more than one human, it will happen several times.  Further, each time may involve a different group of participants - people come and go from projects, teams, ventures, negotiations, programmes, etc - and even those that stay the course generally find that their role in the proceedings changes subtly or dramatically as time goes on.

With regard to IT systems, this means that any IT systems geared towards support of collaborative work must be able to support such constant change.  However, current enterprise technology is not in a position to do so.  Databases, project management systems, time recording systems, billing systems, document storage systems, communication systems, ERP applications, portals, ... the developers, administrators and controllers of such systems fight off change requests tooth and nail.  Why are these IT folk so resistant to the true needs of their business users - who are, of course, the only justification for having the systems in the first place?

Because mainstream technology available to IT folk to build systems makes the constant change required for business collaboration almost impossible - especially if you wish to provide secure, reliable systems.

OK, you might say, I know that old-fashioned monolithic application development, with its lumbering release cycles, was like this.  But surely, these days, there are better ways - ways that offer more dynamism and agility to the business?

Well, no, actually.  Despite the claims of vendors and analysts, if anything the situation has just got worse.

Business Process Management (BPM), for example, is often touted as a means to "keep the business agile", yet in fact it acts in almost exactly the opposite way - to bind people into a set of predefined processes, drawn up by analysts and implemented by programmers at great expense.  Changing such processes may well be harder and more expensive after implementing BPM than it was when everything was handled manually - especially as BPM in itself provides no formal way to guarantee the security and reliability of a process.  OK, you can encrypt XML messages sent as part of that process, and put up a firewall in front of your "demilitarized zone" - but any security professional will laugh if you offer this as a security policy.  With current tools and techniques, change a process defined in a BPM system, and any confidence you may previously have had about its integrity goes out of the window.

Similarly, Service-Orientated Architecture (SOA) will not help either - like BPM, it will only make the situation worse.  Many companies are investing massive effort into building hundreds of inter-related, inter-operable, and inter-dependent "services" to act as their IT backbone.  What they are doing is creating an immensely brittle infrastructure - one that is in unstable equilibrium, to draw an analogy from physics. In such an IT environment, who can say what impact changing particular services will have?  All sorts of cracks could open up - not only systemic breakdowns (crashes, deadlocks, livelocks, etc) but loopholes for hackers.  Best to leave well alone as long as you can ...

TAKE AWAY

Collaborative human work cannot be (and therefore is not) safely supported by enterprise systems in their current form.  What is the result?

People are doing such work informally - using telephone calls, text messages, emails, word processor documents, spreadsheets, whiteboards, and so on - just as they always have.  And this is about the most insecure way imaginable of carrying out what is, in the end, the most important work done by any organization.  Any and all of the previous ways of working are open to any number of attacks or compromises.  We've all heard about the laptops left in taxis.  At present, the whole business community is scattering information about carelessly, for want of any better way of proceeding - any computer systems that support the true nature of collaborative work, and do it responsibly.

In the last post I promised to describe what a different system might look like - but this has turned out to be rather a long post already, so that will have to wait for next time.  For now, suffice it to say that the answer lies in a redistribution of processing - to better mirror the real world.  Just as an organizational HQ is mainly concerned with setting strategy, monitoring its progress and providing resources to the people on the ground, so should enterprise servers adopt a less interactive and more supportive role.  And just as workers in any field need, if they are to work efficiently, to be empowered to get on with things without asking permission from their superiors for every tiny action they take, so should enterprise clients become more self-sufficient.

If you'd like to understand more about how this can be achieved, stay tuned to this blog.

Posted by keithhb in Business Process Management • Internet • Security | Permalink | Comments (1)

In the last posting to this blog, I discussed a massive security problem for the modern organization: how to collaborate safely with business partners, in what might be called "human-driven" processes. I went on to propose that the root of this security problem is that organizational applications (and data) are mostly located on servers - whereas they should be located on clients.

This may seem contrary to common sense - especially since many organizations have set out over the last 10 years deliberately to remove all client-side "User-Developed Applications" (UDAs) in the belief that this would reduce overheads. In nearly all cases at present, organizational software applications run on servers - including of course all "Web 2.0" apps, in which only the user interface is run locally - and once a hacker gets in to such a server-side system, they've won the lottery.

Whether or not this approach has actually reduced overheads is another question, of course, especially when you balance maintenance overheads against the increased productivity many users experienced from their own hacked-up spreadsheets and databases. But that's a side issue.

By contrast to the current approach, let's suppose enterprises were to switch to a truly decentralized model, in which all data, services, etc are supplied by clients, with servers being used only for non-interactive archiving/monitoring/analysis purposes. The hacker has a much harder problem - not only finding a target to attack (since properly built client software could be run from anywhere), but in making use of any access gained (since they will only ever see a small part of the complete picture). This supposes standardized, interoperable clients, of course, not a return to the mess of standalone UDAs.

Further, it is commonly believed in the security community that security policies based on "Role-Based Access Control" (RBAC) are the most promising approach. Ross Anderson, in his authoritative survey of computer system security techniques, wrote in 2001:

the policy model getting the most attention at present from researchers is role-based access control (RBAC), introduced by David Ferraiolo and Richard Kuhn ... This sets out to provide a more general framework for mandatory access control than [Bell-LaPadula] in which access decisions don't depend on users' names but on the functions they are currently performing within the organization. Transactions that may be performed by holders of a given role are specified, then mechanisms for granting membership of a role (including delegation). Roles, or groups, had for years been the mechanism used in practice in organizations such as banks to manage access control; the RBAC model starts to formalize this. It can deal with integrity issues as well as confidentiality, by allowing role membership (and thus access rights) to be revised when certain programs are invoked. Thus, for example, a process calling untrusted software that had been downloaded from the Net might lose the role membership required to write to sensitive system files.

(Anderson, R., 2001, “Security Engineering: A Guide to Building Dependable Distributed Systems,” Wiley Computer Publishing, p.145)

So RBAC may be the way forward from a security viewpoint. However, implementing RBAC in a way that meets true business needs is much harder than it seems. This is because most people do not need static Roles, and static assignment of Roles, but truly "dynamic" RBAC.

A very common business situation is that the parties to a collaborative work process may change as the process unfolds - not just the assignment of identities to Roles, but the Roles they play and the nature of these Roles. Think about any work process you personally engage in. By and large, the nature of your work (and that of each of your colleagues) is likely to change at some point during the process, often repeatedly. This is what I mean by "dynamic" RBAC. We are moving to a world in which work processes are distributed across the Internet, so we need Internet-wide dynamic RBAC systems to secure these processes.

However, current RBAC systems - which tend to be server-based - do not provide for this situation. They may allow for identities to be set dynamically, and sometimes for their assignment to Roles to be updated in use (though this can be cumbersome and poorly managed), but generally you must pre-configure the system with a set of Role definitions on deployment.

To date, there is no operating platform in widespread usage that implements RBAC in a dynamic enough fashion to support the kind of adaptive business processes typical of modern human working practice. Witness, for example, the J2EE authentication model, which is useless for such purposes - and other collaborative mechanisms such as email that depend on authentication and authorisation are fundamentally broken for the purposes of static RBAC, let alone dynamic RBAC. Anyone can edit email headers before sending a message to make the email appear to have been sent by someone else, and anyone that has worked in a large company knows just how useless email address groups are for the purposes of collaboration.

Similarly, dedicated attempts at providing Internet-wide security may have some claim to solve issues of authentication, and even in some cases static RBAC, but fall down completely when it comes to dynamic RBAC. In a 2005 article for ebizq, Identity and Human Interaction Management, I discussed the emerging federated identity systems Liberty Alliance and Shibboleth. Whether or not these ever gain traction, it is interesting to consider what they can and can't do. In particular, while they claim great security strength for authenticating users, they pay only lip service to the assignment of Roles to process participants - and have no dynamic RBAC mechanism whatsoever.

TAKE AWAY

Without "dynamic" Role-Based Access Control (RBAC) there is no way to safely collaborate with business partners. Yet at present, the IT industry has completely failed to implemented dynamic RBAC.

The reason for this failure is that modern business processes are inherently decentralized - so you need a supporting platform that is similarly decentralized, i.e., client-side. The business environment of the 21st century demands a safe, Internet-scale computing fabric in which people (as well as organizations) have 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, and in which the users are empowered to control the security of the process from within, as part of the work itself.

In the next postings to this blog, I will discuss just such a platform.

[Declaration of interest: part of my work is building client software to implement organizational work processes]

Posted by keithhb in Security | Permalink | Comments (0)