As a middleware expert Jürgen works at Oracle EMEA Alliances and Channels, responsible for Oracle’s EMEA fusion middleware partner business. He is the founder of the Oracle SOA & BPM and the WebLogic Partner Communities and the global Oracle Partner Advisory Councils. With more than 5000 members from all over the world the Middleware Partner Community are the most successful and active communities at Oracle. Jürgen manages the community with monthly newsletters, webcasts and conferences. He hosts his annual Fusion Middleware Partner Community Forums and the Fusion Middleware Summer Camps, where more than 200 partners get product updates, roadmap insights and hands-on trainings. Supplemented by many web 2.0 tools like twitter, discussion forums, online communities, blogs and wikis. For the SOA & Cloud Symposium by Thomas Erl, Jürgen is a member of the steering board. He is also a frequent speaker at conferences like the SOA & BPM Integration Days, JAX, UKOUG, OUGN, or OOP.
Berthold Maier works in the T-Systems International department of Telekom Germany as Enterprise Architect. He has more than 19 years experience as developer, coach and architect in the area of building complex mission critical applications and integrations scenarios. Within eleven years as Oracle employee he has held several leading positions including chief architect in the consulting organization. Hi is the founder of many frameworks and take over the responsible for reference architectures around BPM/SOA and Enterprise Architecture Management. Berthold is also well-known as a conference speaker, book author and magazine writer.
Hajo Normann works for Accenture in the role of SOA & BPM Community of Practice Lead in ASG. Hajo is responsible for the architecture and solution design of SOA/BPM projects, mostly acting as the interface between business and the IT sides. He enjoys tackling organizational and technical challenges and motivates solutions in customer workshops, conferences, and publications. Hajo leads together with Torsten Winterberg the DOAG SIG Middleware and is an Oracle ACE Director and an active member of a global network within Accenture, as well as in regular contact with SOA/BPM architects from around the world.
Danilo Schmiedel is one of the leading BPM and SOA System Architects at OPITZ CONSULTING. He has been involved in large integration-, business processes automation and BPM / SOA development projects where he implemented solutions for various customers. His main field of interest is focused on the practical use of BPM and SOA on a large scale. Additionally he works as BPM and SOA project coach. Danilo is a frequent speaker in the German Java and Oracle communities and has written numerous articles about the above topics. Before joining OPITZ CONSULTING Danilo worked as Software Engineer in several international projects. The Leipzig University of Applied Science has awarded his outstanding reputation in 2009.
Guido Schmutz works as Technology Manager for the IT services company Trivadis. He has over 25 years as a software developer, consultant, architect, trainer, and coach. In Trivadis he is responsible for SOA, BPM and application integration, and is head of the Trivadis Architecture Board. His interests lie in the architecture, design, and implementation of advanced software solutions. He specializes in Java EE, Spring, Oracle SOA Suite and Oracle Service Bus. He is a regular speaker at international conferences and is the author of articles and several books. Guido is an Oracle ACE Director for Fusion Middleware & SOA.
Bernd Trops is a Senior Principal Consultant at Talend Inc. In this role he is responsible for client project management and training.
Bernd is responsible for all Talend projects within the Deutsche Post and the introductions of new versions and components.
Before Talend, Bernd was a Systems Engineer working on various projects for GemStone, Brocade and WebGain and therefore has extensive experience in J2EE and SOA. From 2003 to 2007 Bernd Trops worked as a SOA Architect at Oracle.
Clemens worked as Chief Architect for the Shared Service Centre, Global Business Services, Boehringer Ingelheim in architecture, master data, service management and innovation.
At the moment he works with holistic enterprise architecture that provides the methodological platform for the new master data management.
He previously worked as a Platform Architect at Oracle Inc. in the United States, where he helped to develop next product strategy as well as the SOA BPM Suite.
Torsten Winterberg works for Oracle Platinum Partner OPITZ CONSULTING. As a director of the competence center for integration and business process solutions he follows his passion to build the best delivery unit for customer solutions in the area of SOA and BPM. He has long-time experience as developer, coach and architect in the area of building complex mission critical Java EE applications. He is a known speaker in the German Java and Oracle communities and has written numerous articles on SOA/BPM related topics. Torsten is part of the Oracle ACE director team (ACE=Acknowledged Community Expert) and leads the DOAG middleware community.
SOA and Business Processes: You are the Process! Published: January 31, 2014 • Service Technology Magazine Issue LXXX PDF
Business Process Management is a management discipline that thrives to improve process performance. If done right, BPM leads to appealing, user-friendly processes that provide information about productivity, that measure performance and that illustrate the potential for improvement while indicating the exact location in the overall process that potentially benefits from one of various process optimization strategies.
To deal with the complexity of modeling a company's business processes, business analysts proceed hierarchically and begin by describing a value chain (process level 0) through several levels of processes, until they reach a level on which they depict a detailed description of the activities of process participants. Figure 1 gives an overview of BPM with a figure for each modeling technology and the interaction with SOA services.
We see that Business Process Management and SOA go hand in hand: SOA enables BPM.
Figure 1 – BPM and SOA: the bigger picture
At the highest level of the process hierarchy, the functional process blocks for end-to-end processes that potentially span departments in the overall organization are described in a high level, very abstract and coarse grained language, like IDS Scheer value chains. There is no branching, but they do include the most important business goals, ideally expressed as KPIs and other organizational aspects, such as assigning steps to departments.
At the next levels, the process steps are described hierarchically, with the level of detail increasing downward. This is done today in the lingua franca for business process models, Business Process Management and Notation (BPMN). Here the process participants or players in a process are represented as "swim lanes," which contain the process steps that are assigned to this participant.
At a middle hierarchical level (levels 1-3), the process participants are still included relatively roughly through the organizational units, such as the "Purchasing" department.
If you drill down deeper into the process details, you reach the fine-grained level (level 4), at which the activities of the process are represented through automatic system interactions via services and through human interactions These steps that are performed by individuals are called "human tasks." Tasks are specified through process participants in their task lists. The sequences within a task can be modeled and listed in detail in an enterprise portal as "page flows." Examples of human tasks are:
When designing the human tasks, it is a good idea to distinguish the level of each process participant's expertise and adapt the screen layout accordingly.
Once a human task's goal has been attained, a SOA service, typically a task service, is called, which writes the data that was collected during the work step transactionally into a persistent store.
Now we have described the interaction between SOA and BPM. Attentive readers will have noticed an alternative to BPMN in the figure. What is hiding behind the new buzzword ACM (Adaptive Case Management), and how does it relate to "traditional" BPM?
We begin to grasp that further increasing efficiency is no longer achieved by further automating routine tasks (that is already mapped in today's standard ERP software). It is rather a question of determining certain tasks that would benefit from the creativity and decision making abilities that differentiate us humans from algorithms. These activities, such as deciding on a customers credit worthiness or prioritizing actions to resolve a critical situation are assigned to knowledge workers. Let us investigate when this new type of process improvement strategy and according role can be applied, where it is best used to complement routine work.
Why is BPM Not Being Enthusiastically Embraced?
Champagne bottles are opened - the business unit employees are happy. They celebrate that in the new BPM project they see to their delight that in practice the process for engaging external employees is running exactly how they specified it in their sequential process model. In detail, this process comprises a variety of assessments and approvals at different management levels. The exact sequences could be very well expressed in the business process model and notation (BPMN) 2.0 modeling languages. These models are understood by everybody in the team and can be easily changed. At the same time, these models are the basis for conforming executable IT processes.
Such success stories in which a departmental workflow has been used successfully in order to improve productivity can be found in most enterprises today and suggest that BPM as whole is a success. They nurture the belief in business IT alignment through BPM. But why is BPM not being more enthusiastically embraced? Why are automated processes not finally breaking away from the limited space for improvements at micro level, or within departments, and pushing forward into the enterprise area? In part the answer lies in reluctance on changing the culture from a siloed approach in which departments are defined through their function and not through their position in the end to end process to an enterprise wide process driven approach. Yet, in the last years it became clear, that flowcharting-based approach as advocated by most current BPM solutions is not sufficient to cover all types of processes. Sometimes it's not feasible to predefine every step before running a business process. Sometimes you don't know what happens next. Sometimes it's best to rely on a human in the field in order to find the right path towards reaching a business goal.
Routine Work vs. Knowledge Work
Increasing efficiency by automating processes – human history did not need to wait for computers in order to materialize this mantra. Henry Ford and Frederick W. Taylor successfully defined a management approach that broke work down into simple tasks, to enable the complexity of the overall job to be managed. In this way, the giant task of manufacturing a car was broken down into many individual subtasks that only required a few movements each. Each production worker had to carry out precisely defined steps. There was no room for acting independently—and it wasn't necessary either.
Drawing on Taylor's vision, several authors in the field of BPM management discipline have been promoting flowcharting as a way to optimize of business processes since the 1980s. These kinds of "normative" BPM projects ideally enable business departments to analyze business processes, document them, and easily change them if needed. However this only functions well for "normative processes" whose flow can be precisely described before being executed.
In knowledge-intensive contexts, this kind of process is too inflexible to be able to map the complex reality. It would simply be too expensive, and ultimately unmaintainable, to model all conceivable variants of the process cycles, including all possible error and event conditions in advance—if you could ever really achieve completeness at all.
A further requirement for successful normative processes is that the people who take part in the process can work productively under close and strict management conditions. Today, the factory of this type of production workers isn't a physical one anymore, but a mental one: They sit in front of their computer screens, forced to go through the same old task lists and screen sequences by process "straitjackets" of predefined processes. This makes it difficult, or even impossible to work in a way that is innovative and suited to the situation.
The process participants are taken by the hand and guided through a given process, following the model. Just like workers on Taylor's assembly line, they have little scope for decision-making.
However, today we have transformed into a knowledge society. Tasks such as customer complaint management, processing damage claims, supporting job hunters, assessing legal issues, or research and development all require a high degree of dynamic reactions, due to their complex circumstances and new events which can occur unexpectedly. Big names in management such as Peter F. Drucker and Thomas H. Davenport describe the rise of the knowledge worker, who is proving to be far less controllable than the production worker.
The Evolution of BPM - From Normative to Adaptive Processes
What impacts are the differing approaches of the production worker and the knowledge worker having on the designs of BPM initiatives? Rigid, or normatively designed processes, which define precisely how a process is to run before they are executed, are suitable when the goal is to standardize work in Taylor fashion. Traditional process automation lends itself to tasks that should always be done the same way in order to standardize quality, such as preparing proposals, applying for vacation days, soliciting legal approval, maintaining IT systems, performing integration, etc. often they are not characterized by a high level of risk.
In many other cases, when things get a bit more critical and involve human decision making, potentially under pressure, normative processes are simply too rigid. It is not always clear how many steps are needed and precisely what paths you should take to reach a goal. This is true, on the one hand, for knowledge-intensive processes, but on the other hand, also for the core processes in the company for which special experts are brought in. Typical examples of this include consulting or sales meetings, assessing an accident, appraisals, and investigations. Here, the focus is on expertise and the individual choice of the subtask by the user, so as to be able to optimally conclude a business transaction.
The attempt to continue to support this kind of knowledge work with normative processes leads in reality to process bureaucracy (everything is fine if the process is complied with, even if the company makes losses), and to ultimately unproductive process instances, as it is not possible to adapt based on experience. We don't need Taylor's approach here. A BPM that supports goals, something adaptive, would be significantly more productive. We are introducing the term "adaptive processes."
Adaptive Processes as a Branch of BPM
In BPM circles, this desired behavior is called "adaptive case management" (Figure 2). You don't look at the processes themselves, but rather focus on the case for which a goal is to be reached, for which a number of possible processes or process steps, depending on the situation, can be executed. Such a case could be anything: an insurance case, a patient, a project, an asset (such as a building), a customer inquiry, or even the entire customer. We consider the term "case" to be too limiting, and are therefore expanding it to include any kind of activity that requires a knowledge worker to be flexible.
In books and the blogosphere you will often find a debate on BPM versus ACM. We motivate instead that BPM is a cross-management discipline that aims to optimize processes. "Normative BPM" (nBPM) and "adaptive BPM" (aBPM) represent two equal approached under the umbrella of BPM, and are therefore useful tools in the toolbox of business and IT architects, which are used depending on the environment and the forces. A process can contain "island" of structured flows and other islands of rather less structured combination of activities. Even then, an ACM island might contain a Flowchart island.
Figure 2 – ACM and BPMN are variants of BPM
ACM is a sign for a recognition that IT evolves into providing knowledge workers with an optimal workplace that allows them to make the best possible decisions for the company. This means that people have to be the focus of business process management initiatives again—as participants in the process that are not fully controlled by the process model, but contribute actively and directly to the improvement. We do recognize that this kind of new twist that is not applicable for all works scenarios. Typically it is best used for aspects of business processes that that are not fully standardizable and provide a high degree of risk. An example is the credit decision process in banks. Depending on the type of the credit, this can be a highly standardized process or a rather adaptive type in which the decision-maker is provided with a high degree of autonomous decision-making authority, that will be prohibitive for the highly structured simply credit products.
Modeling Adaptive Processes
The basic idea behind the traditional BPM procedure, here referred to as normative processes, is that a process is a previously defined sequence of activities. All transitions between activities are also predefined. The gateways to processes are based on automatically executable business rules. Human interaction is through entries in work lists, through which the process participants are assigned tasks. All conceivable variants of the process are defined through the gateways (BPMN gateways). It is impossible to proceed in a way that diverges from the overall process model. Figure 3 illustrates this.
Figure 3 – BPMN processes precisely describe the work with algorithms
But what happens with adaptive processes? Does chaos rule? How can the business department ensure knowledge workers have free rein, but still perform essential tasks? Adaptive processes do not in any way mean that everything should be left to the user—there are simply more degrees of freedom. Here too activities are defined, but there is the option that allows workers to adaptively incorporate additional human tasks. The transitions between the activities are also not modeled in a fixed way, but are determined at runtime by the individuals taking part in the process. If necessary, they are also supported by rules that can be declared as preconditions. These rules recommend users a list of conceivable activities and tools for the current context.
Adaptive processes are in a permanent state of learning and developing. This is what makes them stand out from ad-hoc or dynamic processes, which give the user a great deal of freedom in the form of arbitrarily executing steps or predefined sequences, but do not have any built-in means for optimizing through experience in the process. Adaptive processes give knowledge workers the possibility of defining additional process steps driven by the situation. This helps them to expand the knowledge base and thereby to generate sustainable added value. This results in a permanent adaptation to reality. Despite all the freedom, the path that process participants take is logged, as a basis for permanent process optimization by business units and IT. In particular, suggestions for improvements by the process participants are logged and regularly assessed. This is referred to as model afterwards or design by doing. The ultimate process arises after the fact out of the diversity of the specific instances that have been run.
An essential property is that the semantic relationship between process steps can only be defined to a very limited extent, according to the system of rules that is contained in the BPMN language instructions. These rules also only apply to steps that follow on from each other, in other words it is not possible to express the relationship of remote steps ("Only execute step 19 if step 4 was not run").
Here ACM potentially offers a fundamentally more productive opportunity to describe the technical details of processes. An ACM model describes the semantic relations that activities have with each other. These types of relations express whether an activity must, or can, be completed in advance. These activities are not automatically processed at previously defined times and places in the process pattern on the basis of a process model. Rather, all activities are made available to users as proposals and users can then decide whether and when they make use of them. The model can also be used to specify that a subsequent activity must always be executed after a certain activity. This means that it is possible to map the regulatory policies of an enterprise and, at the same time, to give users the greatest possible degree of freedom. Several approaches to such kind of ACM modeling emerge, with OMG's CMMN, Case Management Modeling and Notation, being a promising one.
Type of User Management and Interfaces
Typical user interfaces in the BPM environment comprise work lists in which users find their tasks assigned by processes. Here, small screens are often supplied for data input in the individual tasks, displayed in a generic UI area.
User interfaces for adaptive processes also provide knowledge workers with a more flexible IT support. Here there are of course also task lists—but the focus is not on executing one small micro step in a large process sequence, but rather on the complete activity. This means we tend to find interfaces which are more like portals, representing an aggregated overall view of the case. For example, all the assigned master data, histories, and previous business cases can be found here. If it is a patient system, you, as the patient, are the "case," including your entire medical history, all examinations on file, examination reports, X-rays, etc. This makes it clear that accessing unstructured data, such as on a document management system, is an important feature of the interface. However, social and collaborative features and generally all activities that could be meaningful in the context, should also be available at all times. Then there are situations in which the process participant needs to create a new activity that has not been anticipated and where no software exists at all. This is an ad hoc activity, imposing the need for ACM tools that allow to adaptively add new activities to the case that were previously not considered.
Reclaim the Grey Zone
Adaptive Case Management is still evolving. We just start to grasp the future of work. This is a future in which we decide whether algorithms take control over important decisions such as a credit worthiness check or whether we reclaim the grey zone, the moment in which the algorithm says "maybe" and leave the final word to the human expert.