Architecture + Goals = Adaptive!

The discussion about ADAPTIVENESS in processes or knowledge work leads to interesting avenues. Here are a few recent examples:

Jim Sinur – Gartner: ‘Got Social Processes’ proposes a range of process types from structured to ‘guiding’  processes with more and more social interaction. I wonder how others feel, but to me SOCIAL (or its kin E20) by its definition means open and uncontrolled interactions of people and not managed processes. I have posted  a graphic about a similar spread of interaction types in March 2010 when I commented on Jeanelle Hills BPM predictions, but I see them as different technologies and concepts. Jim says that he wants to stay away from a technology discussions, therefore he does not consider HOW these technologies would practically integrate and interact. However integrated, adding ‘social’ free-text-snippets to orthodox BPM does not improve processes or make them adaptive. Only completely new technology can  provide all these variants of process interactions. To become adaptive and thus allow any form of case or process, the BPM technology needs enable the user creation of new goals, tasks, rules, content and participants during execution. That has nothing to do with being ‘social’ and it isn’t ‘ad-hoc’ processes. You can read more in ‘Mastering the Unpredictable’!

Let me state here again that adding SOCIAL capabilities does not provide the dynamics, flexibility and adaptiveness that knowledge work requires. If that wouldn’t be so, then Lotus Notes would be the one and only system because it provided those social features a long time ago, including forms and collaboration.

There are a number of posts out there that cover the differences and likenesses between ACM, BPM and E20. John Tropea wrote a kind free-flow-thinking post on the subject that pulls in many quotes. He does  step into the issue of modelling for BPM or CM, stating that designing a process from a BPM-flow perspective is not the same as defining and fulfilling goals in case management. Yes, BPM is about cheap mass production and case management is about this one special situation. Therefore ADAPTIVE  is about LEARNING from this one special case for FUTURE ONES without going into a complex design exercise. Even if this one case will never be repeated exactly, there may be a lot of knowledge hidden inside it that will help to resolve future cases faster and better. ADAPTIVE is also about creating processes without a-priori analysis from a well-defined library of elements. Jim Sinur’s ‘Design by Doing’ describes the iterative process discovery approach well.

Tom Shepard has proposed that ACM Adaptive Case Management is DATA-focused rather than FLOW-focused. That is certainly one important distinction, but there are several BPM solutions that also have data-mapping facilities such as Tibco. The differentiation is in how the data focus is achieved. Who can create new data elements how and when in the lifecycle? How dynamic can the data be linked to other elements such as GUI-forms, content and rules and used? How are the data handled in a distributed environment? Is there a transaction-safe mechanism? What effort and skill is required to bring business data into the process environment and vice-versa? What meta-data are available for the data? I propose that only an architecture with a well defined ontology of business terms and data entities will provide full adaptability.

I think that the key differentiator of ADAPTIVE is GOAL orientation, while FLOW-processes simply conditionally sequence units of work. Each process goal – often  called a milestone to distinguish business goals outside the process/case boundary – refers to one or more sets of tasks (sub-processes?) that represent alternative ways to fullfil the goal. Business rule preconstraints and context-relevant events can trigger the appropriate tasks. These events ensure task and case synchronization without a rigid flow that would need to consider all possible exceptions. Because these goals are alternatives or hierarchical, there are no process deadlocks or exceptions possible. A situation that does not fit any of the goals or tasks (i.e. the receipt of an undefined document) simple adds a ‘Resolve’ goal that the user can add tasks to. Also typical case management can be seen as goal oriented and therefore ADAPTIVE requires a function such as the Papyrus User-Trained Agent that will propose to an inexperienced participant to add goals or tasks based on training by experienced actors.

The Papyrus screenshot shows that GOALS are linked in a hierarchical tree, ensuring no conflicts. Goals link to tasks, who may be linked to rules, content and GUI presentation. Once a task is chosen, all alternative tasks for that goal are blocked from execution.

To achieve an adaptive process or case management environment, one needs a well defined ARCHITECTURE that also handles the data models, which enables business users to define GOALS and business rules (who need the data) which in turn enables non-technical participants to iteratively ADAPT all process elements.

About Max J. Pucher

I am the founder and Chief Technology Officer of Papyrus Software, a medium size software company offering solutions in communications and process management around the globe. I am also the owner and CEO of MJP Racing, a motorsports company focused on Rallycross or RX, a form of circuit racing on mixed surfaces that has been around for 40 years. I hold 8 national and international championship titles in RX. My team participates in the World Championship along Petter Solberg, Sebastian Loeb and Ken Block.

‹ SWOT Thy Best Practice Benchmarks!

The Texas Two-Step of BPM and ACM ›

Posted in Uncategorized