Frank Michael Kraft's Blog

It is a pleasure for me to announce this new book “Mastering the Unpredictable: How Adaptive Case Management will revolutionize the way that knowledge workers get things done”.

Knowledge worker productivity is the biggest of the 21st century management challenges. In the developed countries it is their first survival requirement. In no other way can the developed countries hope to maintain themselves, let alone to maintain their leadership and their standards of living.” – Peter F. Drucker

The facilitation of the knowledge workers and knowledge work, what is increasingly known as “Case Management,” represents the next imperative in office automation. The desire to facilitate work within the workplace is not new, yet recent advances in Information Technology make the management of unpredictable circumstances now a practical reality.

Over the course of the past few months there has been a groundswell of interest in a more flexible, dynamic approach to supporting work. Here are examples of what recognized experts have recently written on the topic:

“Advancing to support more knowledge work is the goal of many organizations, thus there is a new swell of activity around unstructured processes.” – Gartner VP of Research, Jim Sinur, Jan 2009

“I think a sea change is coming in the process world.” – Forrester Research Vice President, Connie Moore, July 2009

The sea of change Connie Moore refers to toward technology which is able to support knowledge workers. The work of a knowledge worker is by its nature unpredictable and can not be handled by more formalized process definition techniques.

For executives and managers of knowledge workers, Mastering the Unpredictable:

• Explains the need, and why previous trends don’t meet the need
• Explains the current technology gap, and the new technology that is coming to fill the gap
• Lays out the options have at their disposal to increase efficiency of their organization
• Equips them to best take advantage of this evolving trend

The book is a collaborative work of authors from industry which are process experts and thought leaders. The chapter I have written is titled “Improving Knowledge Work”. This is the chapter description:

Elsewhere in this book, the challenges facing an increasing number of knowledge workers are discussed. This book is about how information technology can leverage the abilities of individual knowledge workers. This is not about individual tools; it is about a holistic approach: Adaptive Case Management (ACM). But the approach will only work if individual knowledge workers draw immediate benefit from it. In this chapter, I argue that knowledge work will become easier, more fluent, if the right technology is provided. This is the basis for success within a network of knowledge workers, which in turn will yield the return on investment for the companies they work for. To accomplish this, the characteristics of knowledge work must be directly reflected within the information technology so that the use of such technology feels natural. I will discuss the technology needed to achieve this goal. In closing, I will sketch the full long-term potential for ACM.

It should be possible to pre-order soon at Amazon.

At the Workflow Management Coalition BPMN Industry Day we also discussed about the implications, that BPMN 2.0 now has a meta model. In itself this is a very good thing. However some problems appear, when thinking about backward compatibility, especially with XPDL as de-facto standard for model exchange. If there are models, which are incomplete, but they still need to be exchanged, how can this be handled, if the BPMN 2.0 metamodel requires strict cardinality conformity, that was not required by XPDL? The same problem appears in tools in general, if the model is in an incomplete state and it is saved. Tools need to react gracefully to this situation, otherwise the usability of the tool is harmed.

So if in this example the incomplete model is validated against the meta model, then it fails, because the meta model requires at least two participants for the conversation node. However it makes completely sense to have the cardinality 2..* in the metamodel, because there is no meaningful Conversation without at least two participants. A possible solution would be to water down the metamodel. This is not discussed for BPMN 2.0, but may be for XPDL.

So in this watered down metamodel the participants cardinality is only *, allowing for 0 participants as well. The validadion succeeds, but the semantic suffers. Furthermore the check has to be done whatsoever at some stage. So watering down the metamodel is not a good idea in my view. Instead the solution should be a model lifecycle.

In this proposal the model itself has a lifecycle, which can be active or inactive. If the model is inactive, the validation reacts gracefully against the metamodel. Only if the model is active, the validation fails, but this is indeed intended. So it is unter the control of the modeler, if he wants the full strength of the validation or not.

Such a model lifecycle is not planned in BPMN 2.0 as far as I know, but I think it is a good idea and should be considered. There is a MOF 2.0 Facility and Object Lifecycle Specification that might be considered to be used in order not to invent something new that exists already.

On the BPMN & XPDL Industry Day of the WfMC Thought Leadership Summit one topic of discussion was the current status of BPMN Diagram Exchange.

In the BPMN 2.0 Spec there is a proposal, that builds on a generic OMG proposal, which is not finalized and which will be standardized independent of the BPMN 2.0 standardization.

In this proposal the idea is to have a Diagram Interchange Model independent from the Domain Model, which is in my opinion, a good idea. It is generic, so that other diagram types could be modeled. The diagram validation is done agains a so called Diagram Definition Model, which is also new. The Diagram Definition Model defines, which Attributes a Diagram Interchange node or connector can have, the allowed references and additional (OCL) constraints. Furthermore each Diagram Interchange node or connector is refers to a Domain Model class – in this case a BPMN Task or Gateway or Sequence Flow for example.

Advantages I see:

• Seperation of Model and View – Model maintenance
• Multiple Diagrams for the same underlying BPMN model are possible
• Generic format for different diagram types – tools can use synergies

Disadvantages I see:

• Tools vendors can not use XSD validation. They have to implement the validation against the Diagram Definition.
• The constraints of the Domain model (e.g. Sequence Flows can only be connected to …) must be repeated in the Diagram Definition Model.
• Grafical Attributes (e.g. line thickness) must be repeated as per modeling element.
• Attribute Format (name / value) too generic in my view.

The XPDL Format used to include the Graphics Info into the Elements of the Domain model.

This is simple and straight, and current tools support it, but has the disadvantage, that it is not possible to have one modeling element (e.g. one process) appear in different diagrams. Instead, the modeling elements must be repeated as per diagram, which has many disadvantages in model execution, analysis and model driven development. The Signavio modeler, which was discussed at the meeting, follows the same approach. However it is good as long as only diagrams are drawn for visualization purposes.

Because the BPMN Digram Exchange Proposal was too generic for some, Bruce Silver proposed an BpmnDI.XSD for a concrete XSD validation.

This approach repeats basically all or many BPMN domain modeling elements. This of course is the disadvantage, because it is but a redundant repetition of the already defined domain model. However it is no complete repetition, because the gateway type for example is not included. So a tool must look into the domain model anyway to render the gateway.

Within this discussion it came to my mind, how the GMF (Graphical Modeling Framework) solves this question. I think it is well worth to have a look at this approach, because I think it may be a good compromise.

The GMF defines a Grafical Definition Model, which only defines Shapes. This is simple to understand and straight. Then it defines a Mapping Model. Within the mapping models, nodes and connections are grouped as needed. For example it defines, that there is a node lane which can contain node Activity and Sequence Flow. As a followon the Acitivty node is connected to the Activity domain class and the Shape, that descibes how an activity should look like. The shape can be re-used, which is an advantage of the BPMN Diagram Exchange Approach. The Structures of the Diagram is already contained in the Mapping Model, so it can be serialized to XMI and XSD, which is also an advantage. However still the diagram logic is separated from the Domain Model, which is an advantage over XPDL. And it is a very generic model, which is an advantage over a mere BpmnDI.xsd.

I personally worked with the GMF, and found it quite practical. I am not proposing to use GMF per se, but maybe the approach should be further considered.