Thursday, 15 March 2007

Surfacing SOA by leveraging composite applications

At the Microsoft Architects dinner in Wellington, Richard Hook gave us some hope that SOA and BPM may be accessible through the familiar MS Office. With a highly professional borrow from The Devil Wears Prada, perhaps the ultimate in product placement movies, Richard showed how workflow could be done.
Unfortunately, we do not seem to be at the stage where development of business process is a natural part of doing the business. So the Miranda, Andy, Emily and Nigel roles in this brave new world would still be chained to a business process designed and built by some super business analyst, developer, implementation team.
A lesson that could have been taken from the movie itself is that the people who do the job are the key part of a successful business process. Empowering them to develop or extend the processes that they are involved in is essential to avoid missing large chunks of what actually goes on in a business. I suggest that offering them a Visual Studio-like workbench is not going to be the answer and neither are we likely to spawn enough process development experts for it to successfully occur in the background. In the real world, the people at the sharp end of the business are innovating all the time. This can be seen in the unhappy state of spreadsheets and Access databases dotted around shared filestore or "C: drives" in government and major businesses. The data in these repositories is essentially hidden from management dashboards and reporting tools but is arguably the very data that demonstrates how the business is operating.
After all the standards work done in expressing business process (BPMN, BPEL ...), the means of changing a bit of XML that represents the executing process does not seem a big ask.
Of course there is a fairly entrenched IT world out there with waterfall development, change control and other reasons for not doing things. It is hard enough to get the idea across that the business analysts might work with the same toolset as the developers to shorten the solution development process.
Certainly, if an organisation is wedded to MS Office, it is reasonable to take on all it offers as SOA componentry at the much neglected user interface layer but for the looser arrangements of the Office 2.0 world with a process execution engine may be a viable alternative for developing dynamic business processes where change can be effected at the shopfloor rather than in the ivory tower of IT or process improvement departments.

Monday, 12 March 2007

Data Protection Rules (no more)

Alan Travis in the Guardian, reports on a disturbing change in the handling of information in the UK .

The change is to allow widespread data sharing between public and private sectors for the first time in the name of tackling fraud.

The serious crime bill, which also proposes so-called "super Asbos" to target criminal masterminds, will allow public and private sector anti-fraud agencies to access personal financial information, including pay, tax, pension and benefit records held across the public sector.

The legislation follows a decision by the cabinet last summer to overturn the basic data protection principle that personal information provided to a government department for one purpose should in general not be used for another. Instead ministers have reversed the principle so "information will normally be shared in the public sector, provided it is in the public interest".



As we, in New Zealand, have the same underlying principles enshrined in our data protection provisions that the UK have overturned, we may see some opportunist shifting of the rules here. It is difficult to argue against any measure labeled as anti-crime, anti-terror or anti-rape but much intellectual effort went into the framing of the Privacy Act and associated regulations and practices, serious consideration of the issues and public debate should take place before any similar action takes place in NZ.

Monday, 5 March 2007

Case Management

Bruce Silver asks, and provides an answer to, the question What is Case Management? in his blog BPMS Watch .


To me, case management is about the organisational responsibility for dealing with a problem. IT people and increasingly, business process experts like to believe that the business problems can be modelled and coded so that the solutions are just waiting for an instance of the well known problem to arise. However, the essence of dealing with problems presented by real people is the need to adjust the process to the problem at hand within the current instance.

Whether the case is provisioning to a customer, delivering an entitlement or meeting a contract, innovation in the process is a desirable state of affairs.


For any 'case' we need to be able to answer ... Who has the ball? What is the plan? Where are we up to in the plan?

In some cases, the ownership of the case may be accepted with the understanding that the owner has to decide how best to deal with the problems presented (the health 'business' is an example of where the activities within the case may be novel and certainly the treatment plan may be a unique arrangement of activities).


Case management could be regarded as

  1. Problem Manager Accepts Case ;
  2. Problem Manager Chooses or Develops a problem resolution process;
  3. Problem Resolution Process;
  4. Problem Manager Closes The Case.

A more general view suggests that the process path to the final outcome of a case is dependent on more than one development of a new problem resolution process
  1. Problem Manager Accepts Case ;
  2. Loop until resolved
    1. Problem Manager Chooses or Develops a problem resolution process;
    2. Problem Resolution Process;
    3. Problem Manager determines whether problem is resolved;
  3. Problem Manager Closes The Case.

Case Management adds value if the the subject (customer; social welfare beneficiary; medical patient; legal complainant) and the organisation can identify where they are in the resolution process.




A BPMS supporting this aspect of case management would need to treat the process design and development as a piece of normal business. Ideally the business of the process designer is handled in the same way as any other aspect of the organisation business

  • Define a new (executable) process, message, document
  • Manage the delivery of a process into the execution arena
  • View the current state of cases through a developing business process in management dashboard and other reporting tools
  • Support cases within cases (if it turns out that a case is something distinct from a business process)



Given the preponderance of Visual Studio and similar developer workbench approaches to solution development, a fairly radical change seems to be required from the BPMS providers.



There are some real advantages to be gleaned from treating business process innovation as a normal part of business in the BPMS toolset as well as the business.

  • The ability to change is inherent in day to day processes;
  • The paralysis associated with the need to analyse everything in great depth and through vast numbers of future scenarios can be avoided.
  • Case managers do not lose sight what is actually happening because the process management and reporting systems actually deal with what would otherwise be an exception case.
  • Process designers can use the standard BPMS tools to understand the 'as is' processes because they are not hidden in ad hoc spreadsheets and MS Access databases