Activity-Based Computing

Just had an interesting demonstration from IBM Lotus of some new collaboration technology they are developing. Looking beyond the demonstration (and what IBM currently has working) there is some exciting potential for the convergence of three sets of technologies:

• CSCW (computer-supported collaborative work). Allows co-workers to collaborate around some activity. Distribution and co-development of documents related to the activity, including rich media.
  

• BPM (Business Process Management). More structured collaboration, possibly involving orchestration and workflow, as well as BAM (Business Activity Monitoring).
  

• Web 2.0. Liberal use of tags, feeds and other internet mechanisms.
  

I'm not going to go into details about IBM's current and future technology here, but here are a few examples of how this kind of technology might be used.

• A team within an organization producing a proposal for a customer. (This is a classic example, because it typically involves workers who are engaged in this class of activity as a major part of their jobs, often working on several large and complex proposals in parallel.)

• Handling a customer complaint. (Even if most complaints are relatively simple, the scope of this class of activity is much greater, potentially involving any aspect of the organization's operations. Although there may be a customer service department with primary responsibility for handling complaints, other parts of the extended organization may be pulled in as needed.)

• Solving a production problem. (A problem may be broken down into subproblems, and this may involve spawning a number of other activities. See my earlier post on BPM and SOA, which includes a discussion of the problem-solving methodology TRIZ.)

• A doctor orchestrating medical intervention for a patient - tests, drugs, physiotherapy, and so on. (The interesting aspect of this class of activity is that the collaboration typically goes outside the boundaries of the doctor's own organization. So we would need some kind of federation - for example to coordinate the activity between the clinic and the hospital.)
  

Now let me mention some of the opportunities and challenges that this kind of technology throws up.

• Balance between standardization and flexibility. We're not talking about rigidly prescriptive business processes here, but about situated processes - in other words, processes that are driven by the requirements of a particular situation. For example, although it is certainly possible to standardize some aspects of customer complaint handling - every complaint gets logged, policies for providing refunds, and so on - many complaints will require detailed investigation whose exact form depends on the content of the complaint itself. Meanwhile, management will typically want to have a standard basis for measuring the efficiency and effectiveness of such activities. It is obviously possible to define standard activity patterns, and standard services to support flexible activities - but the establishment and enforcement of these standards is a crucial aspect of activity governance.

• Model-based management. A collaborative activity may be described by an activity model or workflow model (for example using UML or BPEL for People.) It may be possible to use these models in the creation or governance of activities. It may also be possible to infer models (and therefore extract patterns) from the actual history of activities. (The demonstration I was given did not include any process visualization or inference - but there are various IBM and other Eclipse-based modeling tools with which this collaboration technology could presumably be integrated.)

• Publish/subscribe. Use of tagging and feeds potentially provides a neat way of making connections with occasional users. (Atom is a more tightly structured standard than RSS, and may be more appropriate for applications like these that go far beyond simple news.)
  

• Pull/push mechanisms. Subject-matter experts within an organization might subscribe to various tags, with the effect of identifying activities where their expertise might be relevant (thus pulling themselves into these activities). Other social networking mechanisms may also be relevant in making connections between the Expertise and the Work.
  

• Semantics. A small team may have a fairly homogeneous set of tags. As collaborations get more widely distributed, the meaning of a given tag becomes increasingly uncertain, and so the semantic value of the tags may be diluted. This problem may be tackled either top-down (ontology) or bottom-up (folksonomy) - but there are some important issues either way.

• Federation and interoperability. How do we manage collaborative activities that cross organizational boundaries? (a) If the clinic and the hospital are using separate installations of the same collaboration technology. (b) If the clinic and the hospital are using different collaboration technologies.
  

We also had a very interesting discussion on AJAX, enterprise mashups, situated software and other Web 2.0 topics, which I shall write up separately.