... well, just about everything.

Some of you will atready know that HumanEdj went on general release yesterday.  The press release is here and you can listen to a podcast with Elizabeth Book about it here.

This release follows months of beta testing, in a programme that included over a hundred organizations of all sizes, types, sectors, and geographical locations.  I knew from my consulting experience that the software met a need in all sectors, so the variety in the programme was not really a surprise. What was a pleasant surprise was:

• The level of response, since the only invitations to join the beta programme were mentions on this blog
• How many major incumbent software vendors were on the programme.

When I first started writing about Human Interaction Management (HIM), at the start of 2005, there was considerable resistance to the ideas from the software community.  Despite my efforts to explain that HIM is not competitive but complementary to all existing offerings, raising rather than diminishing the value of current software products, many people involved in the software market seem not to have believed this at all.  Rather, they saw the emergence of a "new breed of productivity software" as a threat.  This viewpoint has definitely changed - out of necessity.

We are currently reaching the peak of a hype curve - not only for existing middleware solutions (Business Process Management, Content Management, Business Rule Management, etc) but for the clutch of good-looking new tools known as Web 2.0 (wikis, blogs, AJAX, etc).  How much money are organizations actually making from adoption of any of this?  Very little, I would say.  And saying it, I often feel like the little boy in the story about the Emperor's new clothes - it can't be long before others start to say it too.

When the wave breaks, as it will soon, incumbents providing these products and services will either go under (i.e, watch consumers become disenchanted with the offerings into which so much money has been invested) or surf - by providing their user base with a step-change in how they extract value from such offerings.

Human nature being what it is, it will not be long before the people currently investing in new middleware start to ask how it differentiates them from their competitors - and those still in love with Web 2.0 start to reject reading blogs, editing wikis, and making customized charts in a browser as a waste of time.  To keep these customers, you must offer something more, something that speaks directly to their most immediate need - which is to succeed in whatever it is that they are currently trying to accomplish.

The business person's true needs are not for more information on a Web portal or more features in an ERP suite.  Rather, the business person needs to become more productive, both personally and on behalf of the employer on whose success they depend.  Hence the business person desperately needs a new type of software tools - tools that will help them achieve rather than just "do stuff".

TAKE AWAY

The coming change is actually an opportunity, not a threat, for a supplier of Web portals and ERP suites.  By providing goal-directed collaboration tools that are customized to integrate seamlessly with their existing offerings, such a supplier can show people how to leverage such offerings for direct and immediate advantage, thus increasing both adoption of these offerings and customer satisfaction.

This is why so many software vendors signed up to beta test HumanEdj.  It is a free goal-directed collaboration tool designed from the ground up to support such integration - it can be branded and extended via standard Eclipse plug-ins.  What software vendor wouldn't think it a good idea to offer something based on this to their customers, something that in helping them meet their own business goals incidentally brings them back to the vendor's own fold?

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

Or rather, how not to lose money.

Happy New Year.  Regular readers of this blog may be waiting for the next instalment of the current series on SOA.  In the first two instalments:

• Is your SOAP turning to SOUP?
• SOA and the invisible side-effects of refactoring

... I outlined some of the business issues facing organizations implementing SOA, such as managing change and assessing cost effectiveness. It has been generally accepted for some time that investment in IT is not, on its own, going to give your organization any strategic advantage.  To the contrary, it is quite possible that investment in SOA will simply bring you a bunch of new expenses.

After all, what does SOA really promise to the business?  New integration technologies are just what they say on the tin - new technologies for integration.  Why should spending new money on integration improve your organization's bottom line?

I am not recommending that anyone should abandon their SOA initiatives.  Rather, I am suggesting that such initiatives should be driven by business people, with business aims in mind.  SOA proponents all claim that "yes, this is exactly what we do already".  But the "business advantages" espoused by the technical people currently heading up SOA projects are not usually business-related at all.  They are technical advantages, whose effect will only be felt by the IT department (if at all).

So what sort of things can be considered "business advantages"?  Is there anything generic that we can usefully say?  And how does it relate to SOA?

Let's start by recognizing that an organization is made up of people, all of whom have their own issues.  So "business advantages" means different things to different people.  Here is a very generic breakdown of the sorts of people involved in running any organization, and at an extremely high level, their most pressing problems.

The board of directors are there to lead the organization as a whole.  What they do is mandate aims (strategies and initiatives to implement) and constraints (policies and regulations to adhere to).  So the generic problem that board members have is very simple: how can they ensure that these aims are achieved and these constraints are complied with?  This is effectively a demand for "commitment processing".  The board wish to specify to executives how the business should operate, then receive from these executives their commitment to do so, plus (as time goes on) statistics on how things are progressing.

Managers have slightly different problems.  They have to deal with one-off ventures, projects, and issues.  They may be responsible for how the organization handles routine cases and problems.  Their fundamental need is to make sure that all these kinds of work are done efficiently - which means imposing enough structure for it to be facilitated, monitored and measured.  Some of the work can be (semi-)automated via workflow/BPM, but only some.  For the rest, such flowchart-based tools are far too restrictive.  However, the current alternatives - messaging and document sharing, perhaps via Web 2.0 technologies - don't provide any structure at all.

And then there's everybody else. The average office worker.  This is not a meaningless concept, since most people (including, in fact, directors and managers) have a basic problem in common.  Peter Drucker pointed out back in 1966 that "The Effective Executive" is good not at carrying out tasks, but at using time.  But these days, none of us have enough time - we are overloaded.  There is information overload: the well-known struggle to keep up with everything you are expected to know in order to do your job.  Even worse, there is network overload: characterized by the deluge of messages cluttering up the email inbox of the corporate employee.  The BBC say that:

It’s not unusual for office workers to spend as much as two hours a day, every day, sorting and reading all the mail which pours into their in-boxes, let alone the time they have to spend responding to it.

We all suffer from too much communication, which gets in the way of true collaboration.  And it is collaboration that delivers true business value.

TAKE AWAY

What does the analysis above of generic business problems have to do with SOA? 

Simply that we need to start by recognizing core business problems if we are to deliver genuinely useful business solutions.  In fact, effective enterprise IT architecture can help deliver solutions to all the problems outlined above - but only if the services provided by such IT are based directly on business needs, rather than technology features.

Most ERP system functions are never used.  Most "business intelligence" data is ignored.  Most "single sources of truth" bear little relation to the information truly needed by executives.  And the enterprise systems that people do use end up, as often as not, wasting people's time rather than saving it, like CRM systems that make you first do the work and then write it up.

In the second post from last year referred to above, I proposed that the answer to such business problems lies in Human Interaction Management (HIM), a set of principles, patterns and techniques for structuring collaborative work.  HIM is aimed directly at solving such problems, and is now fully supported by free software tools.

In the next posts to this blog, I will show how HIM can be used to leverage SOA to gain true business advantage.  In particular, we will see that HIM offers a direct way to understand change to services, and to measure their cost-effectiveness.

Posted by keithhb in Business Process Management • Internet • Knowledge Management • Management • Office Applications • Service-Orientated Architecture | Permalink | Comments (1)

There is so much excitement at the moment over applications delivered via a Web browser - wikis, blogs, shared documents/workspaces, portals, Web-based messaging, and so on - that no-one seems to be asking how much any of this actually contributes to the quality of workplace software.

It's all very new, which is an attraction in itself.  And it appears easy to start using such applications, since their user interfaces are often simple.  But is this type of software application actually any better than we had before?

In fact, it's usually much worse.  We've got used to complaining about having too much functionality in applications such as Microsoft Office, so at the moment the Web 2.0 stuff is benefiting from a rebound effect - it's simplicity is tempting. But here are some reasons why such software is a poor substitute for old-fashioned desktop software:

• It is not sensible to try and provide the same level of user interface functionality in a browser application that you can in a desktop application.  Browser programming technology is too lightweight to support truly sophisticated client applications - Javascript, to take one example, is a simple interpreted scripting language that was never intended to be as robust or powerful as the Java language it mimicked.  Any attempt to provide enterprise-class user interfaces solely via such browser technologies will ultimately founder, due not only to problems of download time for huge applications, but also because it is building a house on sand.  Using Web 2.0 means accepting a simplistic user interface.
   
• Most organizations are drowning in complex middleware systems, each of which carries a very high total cost of ownership. No-one wants more such systems. Desktop applications tends to be lightweight - the barrier to adoption is low, whether for one person or for the entire organization, since there is no need to involve the IT department at all. Web 2.0 applications, however, are the opposite - to the user, it seems simple to get started, but most commercial companies do not want their wikis or documents hosted on Google. They want them on their own servers, accessed by server-side software that they have installed, which means engaging with the IT department to start yet another long and involved software adoption cycle.
  
  
• Browser applications intended to support collaboration, as many do, depend on all concerned having access to the same servers.  But collaborative human work processes typically involve people from more than one organization.  Hence all participants may not have access to the same servers, or to the necessary resources on those servers - and even if this could be provided, there are many situations in which no one organization has the right to "own the process".  Hence it is necessary for all concerned to work in peer-to-peer fashion, rather than via a centralized server bottleneck.
   
• Systems intended for use by all kinds of people in all kinds of situation must be very easy to use, doing most of the work for you invisibly - especially back-end integration such as data sharing between applications.  This is not at all true of "Web 2.0" applications - they all present a different user interface, all run on different servers, and do not interoperate in any consistent fashion.  However much office workers may complain about Microsoft Office, they have come to expect a single user interface, which intelligently manages data integration complexity on their behalf.
   
• Any Web-based application is available only when you are connected to the Internet.  But in many working situations no such connection is available - when you are in transit, for example.  A well-designed desktop application, however, can be used at any time, even on any device.  Put the program and your data files on a USB stick, for instance, and you can work wherever you are, using any computer to which you happen to have handy, whether or not an Internet connection is available.

The most successful new desktop software applications of recent years - Groove, Skype, Firefox, and Thunderbird, for example - have not been browser based.  And if they were built today, using currently popular AJAX technologies, they wouldn't work as well as they do - they wouldn't be as fast, as stable, as well-featured, or as easy to use.

So when you are next considering adoption of an end-user workplace application - or building one - ask yourself this question:

Will a browser platform provide the level of functionality that, over the 20 years since the emergence of windowed operating systems, people have come to expect?

And don't be surprised if the answer is a resounding No.

Posted by keithhb in Internet • Office Applications | Permalink | Comments (0)

The well-established law of business known as Pareto's rule tells us that 20% of the work gives rise to 80% of the costs.  Typically this part of the work is the part least susceptible to automation.  In other words, your bit.  What happens when your company realizes that most of its costs are on salaries such as yours?

But no, you may say - people such as myself are the life-blood of the organization.  My employer would not be so foolish as to dispense with the valuable work carried out by highly-skilled individuals such as myself.

It would be nice to think so.  However, despite the BPR fiasco of the 1990s when exactly this kind of thing did happen on a large scale, the current trend towards outsourcing of everything possible is leading to what will probably be an equally disastrous re-run.  Perhaps you will be one of the lucky ones who gets to come back on an inflated consultant's rate when the dust has settled!  Perhaps you won't.  But it would make a lot more sense for everyone concerned to deal with things more thoughtfully this time round.

The underlying problem here is actually very simple.  People even at a senior level in organizations have a poor understanding of what it is that their staff actually do.  They form a simplistic concept of what their staff are up to, and then think: if this is all there is to it, why not get someone on the other side of the world to do it cheaper?

The perspective underpinning such decisions is that work can be defined as a series of tasks.  This task-oriented outlook arises from traditional management tools such as work breakdown structures in project planning, and is supported by mainstream technologies such as workflow and BPM.  In such approaches:

1. Work is divided up into tasks
2. These task units are assumed to capture what is done.

This is fair enough when the work consists of assembling cars on a production line, or matching bank statements to receivables.  However, the approach breaks down completely when it comes to what I call human-driven work - the sort of collaborative, adaptive, knowledge-based work that you and your colleagues do.

Treating work as task-oriented is equivalent to viewing it from the outside - as a detached observer, individual tasks are all that you see.  However, this is completely inadequate for human-driven work, which must be understood from the inside.  Your own work is not about tasks at all.  It is about things such as information, interaction and innovation - much of which is almost invisible to an observer.  Only by understanding work from the inside can you make valid judgements about it - such as how genuinely to do it better.

TAKE AWAY

How far down the outsourcing route is your organization already?  Where will it stop?

Even though ignorance of the true value of human-driven work was the direct cause of large-scale losses during the BPR fad of the early 1990s, it is all happening again.  In fact, those most concerned about it are the outsourcing companies themselves - the suppliers, not the customers.  They may be making a packet at the moment, but know there is huge trouble ahead when their clients start to realize what they have let themselves in for.

So, in an effort to stave off the coming backlash, the outsourcers are actually in the vanguard of efforts to better understand human work.  Many of them are already looking to the techniques of Human Interaction Management to get a better handle on what highly-skilled people actually do.

However, ultimately it is the responsibility of each organization to get properly to grips with what they want to outsource, and how.  The old notion of "core" processes has been discredited for a long time, with Hewlett-Packard outsourcing printer design, and banks everywhere outsourcing financial transaction handling.  So when will you come to understand what the highly-skilled people in your organization contribute - before or after it makes them (quite possibly including you) redundant?

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

What?  The Chair of the Workflow Management Coalition, and former CTO (and designer) of Staffware, saying workflow sucks?  Yes, it's true.

Jon is not exactly noted for reluctance to rock boats.  But this statement seems particularly challenging.  I'll look more closely at Jon's message, and the content of the white paper he recently published, in a moment.  But first, we need to step back a bit.

Consider my post last week, How to abuse your software investments, in which I asserted that the deluge of new Internet tools known as Web 2.0 is actually a disadvantage to most organizations.  People are spending more and more time using these sexy new programs and devices without having any way of measuring the contribution to business goals made by such use.  As a result, most organizations are wasting more staff time than ever before.  Hardly the spirit of "extreme competition" needed in the new and challenging 21st century business environment!

To take just one example of such time wasting, here is a quote from the BBC, to which Jon himself drew my attention:

It’s not unusual for office workers to spend as much as two hours a day, every day, sorting and reading all the mail which pours into their in-boxes, let alone the time they have to spend responding to it.

How much is this contributing to personal or organizational goals?  I've written about the problems of corporate email before.  But email is just one example of how human work is actually being hijacked by new workplace technology.  Blogs, wikis, mailing lists, forums, intranets, chat, Web search, .... how are you measuring the operational (dis)advantages resulting from use of such tools in the workplace?

Here is a picture of where most organizations are now:

The underlying problem (and here we are getting closer to Jon's message) is that traditional work management tools - such as workflow - are of no help at all here.  You might think of workflow et al as "Work 1.0" and current knowledge-focused, collaboration-intensive, and innovation-driven work practices as "Work 2.0".  Here is a picture of where organizations need to go:

The key element of this picture is the blob in the middle, Human Interaction Management System, or HIMS.  What is an HIMS?  And why do we need one in order to implement what Jon's white paper calls Knowledge-Intensive BPM, or KIBPM - to control fundamentally important business activities such as Project Management and Case Management?

Let's start with the definition of an HIMS.  Here it is, from "Human Interactions: The Heart and Soul of Business Process Management" (2005), the seminal source book on Human Interaction Management (HIM):

A process modeling and enactment system that provides native support for the six Role Activity Theory object types (Role, Entity, Activity, User, State and Interaction), uses a state-based approach to Activity enablement and validation, permits Interactions to be composed of multiple asynchronous channels, and supports management of process change by allowing any process component to be created and configured as a natural part of process execution—not just objects of the six fundamental types, but also the user interfaces by which they are presented (screens, for example) and the means by which they interact with other systems (Web service calls, for example).

This is a complex definition, of course - almost what you would expect to see in a software specification document.  This is deliberate and necessary.  A HIMS must be a very specific sort of beast, in order to support the 5 basic principles of HIM:

1. Connection visibility - to work with people, you need to know who they are, what they can do, and what their responsibilities are as opposed to yours.
   You need Role and User objects, both instances and types, each with its own properties and responsibilities.
   
2. Structured messaging - if people are to manage their interactions with others better, their communications must be structured and goal-directed.
   You need Interaction objects in which there are multiple asynchronous channels, each for a different purpose.
   
3. Support for mental work - organizations must learn to manage the time and mental effort their staff invest in researching, comparing, considering, deciding, and generally turning information into knowledge and ideas.
   You need Entity objects that can be created, versioned and shared within a process.
   
4. Supportive rather than prescriptive activity management - humans do not sequence their activities in the manner of a procedural computer program.  There is always structure to human work, sometimes less and sometime more, but it is not the same kind of structure that you get in a flowchart.
   You need State objects that can both enable and validate Activity objects, along with the Roles that contain them.
   
5. Processes change processes - human activities are concerned often with solving problems, or making something happen. Such activities routinely start in the same fashion - by establishing a way of proceeding. Before you can design your new widget, or develop your marketing plan, you need to work out how you are going to do so - which methodology to use, which tools are required, which people should be consulted, and so on. In other words, process definition is an intrinsic part of the process itself.  Further, this is not a one-time thing - it happens continually throughout the life of the process.
   You must be able to manipulate not only objects but also user interfaces and integration mechanisms via the process that contains them.

How could a conventional "task allocation and notification" system possibly provide all these vital features?  Just to take one example, I have never seen a workflow/BPM system in which it is practical for users to try and make significant change to a process from within the process itself.  This is why Jon Pyke says, of course with tongue in cheek, that workflow sucks.  We need a new form of software tool, in order to support the business practices that are at the heart of organizational efficiency in the 21st century.

TAKE AWAY

 If you want to compete in the 21st century, you need to leverage your human resources efficiently.  If you want to leverage your human resources efficiently, you need an HIMS - not a workflow/BPM system rebadged as an HIMS.

So ask any software vendor trying to sell you a "Human Interaction Management System" how their offering conforms to the definition above.

Don't let them sell you a pig in a poke.

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

Here are some typical programs that someone reading this blog might use during a regular working day, in no particular order:

• Email client, perhaps as part of a Groupware solution such as Notes, possibly pushed to a device such as a Blackberry
• Web browser, particularly for search
• Intranet portal offering a Business Intelligence dashboard
• Reports from a decision support system
• Workflow/BPM task manager for notifications and work allocation
• Back-end ERP system for data on finance, logistics, inventory, etc
• Operational front-end system for various forms of data entry and maintenance
• Document/content management system
• Spreadsheet
• Word processor
• Presentation designer
• Drawing tool
• Project planner
• Voice-over-IP (e.g., Skype)
• Shared document access (e.g., Writely)
• Sector-specific databases - of drugs in healthcare, license numbers in law enforcement, and so on
• Sector-specific tools - graphics editors in design, CAD/CAM tools in engineering, and so on
• etc etc etc

I could go on.  These days, many people would add peripheral tools such as blog editors to the list, for example.  But perhaps you take my point!  It's a long list, isn't it.

Peter Drucker wrote, as far back as 1966 (in "The Effective Executive"):

The effective person focuses on contribution.  He [sic] looks up from his work and outward towards goals.

The great majority of people tend to focus downwards.  They are occupied with efforts rather than with results.

In other words, effectiveness is not about tasks.  It is about time.  Decide at the start of each day what are the most important things you need to achieve, then allocate your time accordingly.

Do you do this?  Most people would like to, but in fact are simply drowning in a sea of software.  They spend much of their time using programs of various forms, without ever stopping to ask a simple question:

How much does use of this software, at this moment, contribute either to my personal goals or to the aims of my organization?

TAKE AWAY

We are in the midst of a massive change in human working behaviour.  Some people, and some organizations, may be capitalizing on it, but many more are not.  The world is polarizing into the "very smart", who understand how to leverage the change - and the rest of us, who are just struggling to keep heads above water.

So, do you want - and does your organization want - to be "very smart"?  If so, you need to tackle grass roots issues head-on.  In particular, you first need to find out what are your staff are actually doing each day.  Most organizations have no way of knowing this, let alone any way of measuring its effectiveness.

I will be talking more about this issue in future blog entries.  For now, you might like to refer to this article - What is going on in your Organization?

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

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)

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)

This time I will try and illustrate the proposed approach - process-based tools that are hosted on clients rather than on centralized servers - by means of an example.  And as so often happens, the perfect example dropped into my lap only recently.

Have you ever been driven into a perfect storm of rage by customer "service" from a supplier?  I try to take the long view and stay calm in most situations, but got pretty close to the edge when trying to sort out my personal broadband service during the last few days.  Over a year ago, I signed up for what was, at the time, in the UK, a fast business-grade connection, from the supplier I have used for well over a decade now.  The 12 month lock-in on the contract is now over - and since the company is currently offering a price of about half what I agreed to pay originally, I tried to contact them to sort the matter out.  This is where matters went horribly wrong, the only silver lining (to my raised blood pressure) being that the story is usefully instructive for our purposes here.

As background, the company concerned was one of the first UK ISPs.  In its early days, 1992 onwards, it was a very friendly, knowledgeable outfit with a technically-literate customer base.  The company managed its growth well, and grew rapidly, to the point where at one stage 2% of UK phone calls were to its dial-up service.  Then, after 6 years, they were bought out.  And everything changed.  In particular, the customer service effectively vanished overnight.

Before takeover, even at the height of their popularity, you used to ring their office building in suburban London, and speak to a permanent employee.  It was not unusual to speak to the same person on multiple occasions, and the person you spoke to would be the one that dealt with your case.  Now, if you email them or use their Web site to submit a support request, you are lucky if you get an automated acknowledgement, and even that won't be for a while.  If you dare to ring, on the other hand, you get forwarded from one person to another in a never-ending chain - 6 is not unusual, often not even being transferred, but having to hang up and redial - and at each stage, you must repeat your name, confirm your identity via a sequence of questions, then explain your situation all over again.  At the end of going through this sequence 3 times, all I got each time was a promise of a callback.  And none of these callbacks ever materialized.

What is the root cause of this appalling behaviour?

If we compare the current situation to the early days of this company, and make an analogy with computer systems, at the start a customer like me had what we can think of as a "channel" to the supplier (like a persistent open socket, if you are technically minded).  I could ring them, and know who I was contacting - even where the person was located. This was long before the days of calls being recorded, but the person I spoke to would take responsibility for sorting the matter out, would ring me back once they had done so, and - crucially - if I then got further problems, I could ring the person concerned on their direct line.  I never had to re-explain anything, and always knew exactly how to contact them if necessary.

Effectively, customer and supplier built and shared a "process context" - a mini-workspace, in which lived certain data and activities.  Data included my account details and any problems or issues I was facing, along with any relevant information provided by the supplier.  Activities included efforts on my side to supply additional information or carry out tests, and on their side to sort things out in various ways.

All this was accomplished informally, of course.  They may have used some kind of CRM system, but if so, I was never aware of it in any way.  What I was aware of, to my delight as a satisfied customer, was that we knew each other - "knew" in the very specific sense of understanding that we were engaged in a collaboration, and of what that collaboration consisted.  We were participants in a shared process, participants who had signed up to be involved, had agreed on the nature of the process in question, and each did their bit to ensure the process was carried out successfully.

TAKE AWAY

The functionality required to provide effective customer support is very different from CRM.  Some CRM systems may include the ability to document specific issues raised by a customer, and the actions taken on both sides, but such systems offer no ongoing means to manage that process.  And current Business Process Management or workflow products do not provide sufficient flexibility to support the full range of issues raised by customers, which are generally a highly individual concoction of requirements and problems.

The problem with CRM, BPM, et al is that they assume both customer and supplier will fit naturally into the limited range of functions offered by a pre-configured server system.  And this is so far from business reality that it is almost laughable.  In fact, the true nature of customer service is more like this:

1. Customer (or sometimes supplier) opens a negotiation - on a number of topics, which may or may not be related.
2. Supplier and customer exchange information, and agree next actions to be carried out - all this being highly customized to the case in question.
3. Step 2 is repeated until both parties are satisfied.

What sort of software is required to support this behaviour?  Software that lets both parties define multi-party contracts, replete with custom data items and activities, and each keep a copy of that contract on their own system (since both parties will naturally want a record of the agreement).  Further, the software objects embodying this contract must act not only as a "system of record" but also support active engagement in the collaborative process thus defined - as well as the continual re-negotiation of this process.

It is easy to see that current Web technology does not work anything at all like this - saving or printing a page from a supplier's support Web site, for example, offers nothing like the functionality described above.  What is required is a "rich client" capable of defining, depicting, enacting and revising such collaborative contracts - a client that all parties to a process use to support the work involved.  My own efforts to provide free software of this form are surely only the start of a new wave in technology for customer service.  And for many other fields too.

In the next instalments of this series, I will look at further applications and examples of this approach to collaborative work support.  Stay tuned if you want to see what is round the corner.

And I have changed my broadband supplier, by the way.

Posted by keithhb in Business Process Management • Internet • Management | 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)

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 | Permalink | Comments (0)

In the next few blog entries I will be discussing open source projects that have reached a certain stage – that of being at least as mature as their commercial competitors. Many organizations are still reluctant to use open source software for mission-critical applications – and in some cases there are good reasons to be suspicious. I will conclude this series of blog entries with a discussion of the potential hazards of adopting certain types of open source software in an enterprise infrastructure.

However, these hazards are not those typically those voiced as objections by IT management – unstable or insecure software, availability of support, and legal issues. The open source projects I will be discussing in the next few entries are perfectly viable from all these perspectives. In general, major open source software applications are written at least as well as leading commercial products (often by the same people), enthusiastically supported by expert and helpful developers (as opposed to knowledge-free call center staff), and transparently licensed (via industry-standard agreements).

Similarly, the advantages of open source are not those typically quoted, either. For example, open source evangelists, being technical folk, make a big deal out of being able to correct or enhance the code yourself if you need to. This is exactly the opposite of what an enterprise is looking for - the very last thing they want is the headache of untangling some huge and complex application when there is a problem. The real benefit of open source is that it is generally more attuned to real-world needs, since open source projects get started precisely in order to meet such needs. While software vendors are grappling with legacy products and market positioning, the open source community just goes off and builds useful stuff.

Stay tuned to this blog for a discussion of the true hazards of open source as regards enterprise adoption, which are to do with the type of project. For now, I will be looking at projects that are not only free from such hazards, but that offer significant advantages over their commercial rivals.

First up is an offering in a space of increasing importance – information retrieval. The success of Google is a measure of how valuable this technique has become in modern life, yet despite the continuing advance of Web search, the facilities that most organizations offer for searching their intranet, or even their public-facing Web site, are little more than pitiful. The ability to retrieve a particular document from the sprawling Web presence (internal or external) of a large company is often more a matter of art than science, and may well depend on knowing in advance the likely path to the data concerned.

This is, of course, a well-known problem, to which knowledge management techniques are often touted as the answer. Indeed, such advanced solutions can be employed to unlock the information archives of a company – but you do not always need the sort of high-end, and very expensive, tools sold for this purpose. For one thing, there are alternative approaches to knowledge management that can be leveraged to expose the knowledge hidden inside information, some of which I discussed in previous blog entries, and I will be returning to this topic in future posts. However, there are also far simpler ways by which the hundreds of thousands of documents available via HTTP on a large company’s servers can be made available – and thus turned into an asset rather than a liability.

I was struck recently by the marketing puff for a commercial search engine, which offers as a “step forward” the ability not only to search structured data (requesting specific values for specific fields) but also to provide flexibility via assigning weights to the different terms in a search. Surprisingly, whoever wrote this PR spiel – and possibly the vendor itself – does not seem to be aware that such “advanced” features have been available for years in the leading open source search engine.

The search engine in question is Lucene, an Apache project. Lucene is not only very well-established but can do some very cool things. For example, Lucene can search via named fields - a feature that in itself offers a step on the way to full knowledge management – and offers wildcard, fuzzy, proximity and range searches. Terms in any of these types of search can be boosted, grouped, and controlled via the use of logical operators.

For a proper explanation of these features, see the links referenced above. The point is that Lucene is very full-featured. However, Lucene is not a search application – it is simply a search engine, a code library that can be used to interrogate any body of text. To use Lucene as the search tool on a Web site, for example, it must be embedded into a product designed for the purpose.

Fortunately, since June 2005 there has been a sub project of Lucene aimed at doing precisely this. The Web crawler and search facility that incorporates Lucene is Nutch. Nutch operates somewhat like Google - in fact Nutch incorporates some technology that Google itself put into the public domain, technology that permits Nutch to crawl, index and search enormously large collections of documents. Moreover, the user interface of the Nutch search facility is, if anything, more helpful than that provided by Google, providing an analysis of how the page ranking was generated along with the results themselves.

If I were a search engine vendor, I would be worried now that Nutch is getting off the ground properly. I have used Nutch in anger, and cannot see any reason to buy commercial software for this purpose now. Simple to install, robust, scales, configurable - what more could one want?

TAKE AWAY

If you work for a large organization, ask yourself whether its public Web site and intranet provide genuinely acceptable search facilities. If not, consider implementing Nutch. It takes – literally – minutes to do the initial installation, and configuration even for a large document base is not complex. And Nutch, like Lucene, comes from the Apache Foundation, one of the most (if not the most) well-established and reliable homes for open source projects.

Tune in next time for a discussion of other open source software with the potential to transform your enterprise IT environment for only a small investment of time and effort.

Posted by keithhb in Internet • Knowledge Management • Open Source | Permalink | Comments (2)

This is the concluding entry in a 5-part series on BPM futures. Previous blog entries showed that:

1. The imminent provision by the OMG of a standard XML format for BPMN will effectively render BPEL unnecessary
2. The adoption of BPMN for process definition means that business process automation will become a high-level graphical interface to component technologies, rather than a separate layer in enterprise architecture
3. By taking a computer science perspective, we can see that in due course Web service choreography will supersede Web service orchestration for the definition of those processes in which human involvement is limited to key decision and data entry points (what I call "mechanistic" processes)
4. Hence, forward-looking organizations need to consider now the creation of choreography descriptions, an activity for which the techniques of Human Interaction Management can be used: both to develop the processes needed to establish agreement on multi-party collaborative contracts, and to provide the graphical notation needed to depict the contracts themselves.

In this final blog entry (for now) on BPM futures, I will look at the type of software vendors best positioned to take business process automation forwards.

The argument above shows that business process automation is turning into a rather different sort of activity than has been supposed to date. As implemented by current BPM suites, business process automation is largely a matter of drawing flowcharts - effectively it is a sort of high-level, graphical programming. In fact, BPM competes directly with a combination of the UML and J2EE, for example. Though the picture painted by BPM vendors, and some analysts, is rather different, the battle could be considered a David vs Goliath one. I would happily bet that the total number of all BPM installations ever is nowhere even close to the average number of downloads of JBoss (say) in a single month - which in November 2005 was about 200K.

Of course, a BPM suite provides features that do not always come for free with a component-based approach to process automation - in particular, Business Activity Monitoring (BAM) - though here too technologies such as JMX are starting to provide a viable alternative. However, my point is simply that to date BPM has not become an ubiquitous part of enterprise technology, and this is because it is competing with other approaches that are mature and very well-established. Moreover, the people who are in the end responsible for implementing and maintaining BPM - the IT department and their outsourcing suppliers - are a lot more comfortable with J2EE or .NET than they are with a particular proprietary BPM toolset.

However, all this may change with the next generation of BPM tools. The argument that was made in previous blog entries, and that is outlined above, shows that business process automation will inevitably move towards the creation of multi-party collaborative contracts - where the parties may be internal to a single organization or span several organizations - and the use of these contracts to generate executable business processes. This is a very different kettle of fish from the usual software development process. Though agile methodologies, in particular, place an emphasis on negotiation and re-negotiation of client expectations, the future focus of BPM will be on the creation of agreements among several collaborating parties. BPM tools will then provide the means for each party to automatically turn their part in such agreements into working software.

Tools of this nature bear little relation to existing BPM products. But they do bear a strong relation to another class of products - those provided by vendors specializing in middleware to support Service-Orientated Architecture (SOA). SOA techniques are in flux at the moment, and there is a lot of debate among experts as to the benefits of a distributed vs centralized backbone, or the WS-* stack over simpler techniques such as REST and XML-over-HTTP. However, despite all this debate, there are some tenets to which most people adhere - in particular, the key technique of SOA is to establish what are generally called service contracts. There is little agreement among those in the field even on what a service is, but most agree that a service should expose some kind of description as to what it does. A service contract is a description of itself that a service publishes (somehow) - it is used by those that wish to call the service to determine what they can expect from it.

There is a strong parallel here to the direction in which business process automation is going. Both are based on the definition of contracts rather than on the definition of internal behaviour. SOA tools have not yet advanced to the point of being able to generate the latter from the former, but (as shown in the previous blog entry) there is every reason to suppose that this can and will be automated by software in due course.

There is a growing realization that the architectural principles emerging for the design of business processes by analysts (based on establishment of multi-party service contracts for collaborative behaviour) are the same as those already used by technicians in SOA. In fact, there is a strong argument that in a decentralized, globalized, Internet-enabled economy it will soon be hard to survive without applying such principles to the organization of your enterprise. As McKinsey wrote recently:

"the shift from transactional to tacit interactions requires companies to think differently about how to improve performance - and about their technology investments. Moreover, the rise of tacit occupations opens up the possibility that companies can again create capabilities and advantages that rivals can't easily duplicate."

Hence, it is realistic to expect that the next generation of tools for business process automation will come neither from platform vendors, nor from BPM pure-plays, but from vendors currently providing a complex, and to many people invisible, part of the IT middleware infrastructure - tools that come under such confusing and often overlapping categories as Web Services Management (WSM), Enterprise Service Bus (ESB), Enterprise System Management (ESM), and so on.

TAKE AWAY

In the next year or two, expect SOA to become high-profile among business leaders as well as technical folk - to become as much a management methodology as an approach to IT. This change will bring with it some key questions, related not only to development - how can we create a set of services, and agree on them with those responsible - but also to governance - what policies, procedures and other controls do we have in place for maintaining and regulating services? The SOA community is evolving some answers to these questions, but inevitably these answers are currently too IT-focused. If SOA is to successfully make the transition into a management approach, it needs to take on board the general principles and patterns that underpin business activity.

Such principles and patterns need not only to encompass diverse fields of business theory (quality management, knowledge management, project management, ...) but also insights from the many scientific disciplines connected with organizational life (psychology, biology, social systems theory, learning theory, and so on). Further, it is no good assembling such insights into a huge, diverse and confusing set of "best practices" - the consultant's favourite trick. They must be organized properly into a theory with a formal basis that provides the reassurance of sound thinking together with a structured and maintainable approach to implementation.

With respect to IT industry support for this move, expect SOA vendors to find an exciting new field opening up for them - the full support of mechanistic business processes, currently considered the domain of BPM tools. Those SOA vendors that embrace the move to declarative expression of processes descriptions, and automatic generation of process implementations, may well find themselves catapulted to a new and prominent level of visibility among business leaders.

PS

On a personal note, before publishing the ideas in this series I did not expect them to be met with much (or any) agreement. BPEL in particular is a focus of current IT industry interest, and consequent vendor investment. So it was a pleasant surprise not only to find that some influential people have already come to similar conclusions about BPEL - Phil Gilbert of Lombardi, for example, in his own blog - but also to receive many messages of support for the ideas in general. Whether you agree or disagree with the views expressed in the series, please let me know, either publicly via a blog comment or privately via email (see my bio). Private messages will of course be treated in confidence.

In the next blog entries, I will be looking at some of the most important open source software tools. I am continually surprised in my consulting work to find that organizations are paying for software that is less mature, less feature-rich and less well supported than that provided by the open source community. I will also discuss some of the situations in which open source is not a good idea.

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