Managing Modern Business Processes

In large enterprises, business productivity is inextricably linked to the successful and efficient management and execution of the daily tasks that make up an organization’s core business processes. Using modeling tools, organizations can build, implement, and execute process models to gain insight into their critical processes, and use that information to refine those processes and improve their performance.

Many process modeling and management tools, such as SAP Process Orchestration, use the graphical business process model and notation (BPMN) standard¹ to render business process models along with a specialized BPMN process engine to execute them. With BPMN, the steps in a business process are rendered in a standardized, exchangeable, XML-based graphical format that all users can understand, from the business users who create the processes to the technical users who implement them. Looking at a BPMN-based model during runtime, both business and technical users can clearly identify which process step is currently being executed, even if the process is running in distributed systems, for example.

While BPMN and its execution capabilities help organizations better understand and improve their processes, modern businesses are constantly changing, and traditional approaches to BPMN-based modeling lack some of the flexibility required to adjust quickly to new opportunities and requirements. This article introduces a new concept — process-driven architecture (PDA) — that can be applied when using any BPMN-based modeling tool and, using an example from SAP itself, shows you how a PDA-based approach enables the flexibility and efficiency required to manage and support your unique business processes.²

Why Use a Process-Driven Architecture?

The PDA concept is useful in a number of ways, particularly when it comes to processes that differentiate organizations from the competition. Traditional processes cover standard business processes, such as procure-to-pay, hire-to-retire, and order-to-cash, but how do you model and execute differentiating processes? For example, think back to when self-service check-in with airlines was a brand-new feature — how do you model a unique, industry-specific process like this? With a PDA-based approach, companies can address the core, differentiating processes they have in place that are not covered by standard processes.

In addition to supporting unique processes, this process-driven methodology ensures the right balance of development and maintenance costs, scalability, and fault tolerance, and provides sufficient flexibility for adjustments without becoming complex itself.

The PDA methodology paves the way for a streamlined approach to agile, BPMN-based modeling and execution. With other approaches, the IT department would need to take the BPMN models designed by business users and extend them with additional shapes for making the model executable that were not business relevant. This results in overly complex process models with little relevance to the business, and the original BPMN idea of executing the models exactly as the business users designed them is lost.

The process-driven approach, on the other hand, ensures that during execution, BPMN models are preserved as they were designed by the business users. This is a significant step forward for business process management in general. Also new with the process-driven approach is that both business users and IT users work jointly on a single BPMN model right from the project’s start and throughout the complete life cycle of business processes. In practice, this means that both sides sit together and work collaboratively on the process models — no decision is made exclusively by one side alone. Since the business processes are no longer muddled by technical BPMN shapes, the process models themselves become leaner and, with that, easier to maintain. This gives companies more opportunities to adapt their strategy to changing market conditions.

How Does a Process-Driven Approach Work?

The main idea behind PDA is to abstract process-driven applications as much as possible from the specific system landscape on which the processes run so that they are independent from the system landscape.³ As a result, changes in the underlying IT landscape have no effect on the processes, and process logic can be adjusted without considering the IT landscape. As a result, it eases the introduction of the same process in other departments, regions, or countries that typically have different IT landscapes.

But how can this abstraction be achieved? The answer is by providing two separated layers: one layer for the business process alone and a second layer for the integration into the underlying and typically heterogeneous IT landscape. Between the two layers is an interface known as the “service contract.” The service contract reflects the functional needs from the view of the business process and contains no dependencies (such as data types or business objects) from back-end systems. This is a significant change from the traditional approach, where the services provided by back-end systems were directly used in the business process models, with the consequence that a change in the back-end system often entailed a change in the business process.

To see how this multi-layer architecture works, let’s look at an example. Figure 1 shows a simple order booking process that is already defined as a process-driven application separated into different layers. The process-driven application is at the top and the integration-centric layer is at the bottom, with the service contract in between. Since the integration-centric layer implements the needs expressed by the service contract, this layer is also known as the service contract implementation layer (SCIL). As you can see, the Book Order service in the process layer makes no assumptions about the system where the bookings ultimately take place, or about any specific interfaces to the back-end system. Instead, each service in the PDA process defines a fixed service contract, which contains only the elements needed to perform the Book Order business function from the view of the business process. In this way, the service contract is defined primarily by the business process, which ensures that changes to the underlying system do not necessitate changes to the business process as well. Likewise, the process can be used essentially as is in any system landscape, because it makes no assumptions about the underlying system landscape.

Figure 1 — An example process-driven architecture

The major advantages of this approach are that the PDA process is identical for the business users and the integration developers and that the unique business process — which is often called the company’s “gold nugget” in terms of value — is not overrun with technical details. It precisely describes how the company runs its most important differentiating processes. In the end, the executable process becomes truly business-driven.

A Process-Driven Application in Action: SAP’s Language Services

Let’s take a look at how SAP itself used the PDA approach to successfully implement a major project. SAP’s language services (SLS) provide services for translations (in 39 languages) of a variety of items for SAP products, such as business reports, marketing materials, transcripts of videos, handbooks, and user interfaces. In 2014, SLS translated over 280 million words. The requirements for running the processes supporting these services were so unique that no standard software vendor could deliver what SAP needed. So the SLS team decided after an intensive evaluation phase to build their unique business processes following the PDA methodology, and to run them using SAP Process Orchestration.

There were several factors to consider in building the processes. The services the SLS team has to deliver depend on the translation scenario. For example, the translation of pharmaceutical texts must comply with FDA regulations, so only translators with the required qualifications are allowed to perform the translation. In addition, every translation project must consider different types of text sources (more than 700 ABAP and Java systems, for instance) as well as different types of text, such as marketing materials, texts for internal communication, and even official financial statements. As a result, each translation process must factor in those requirements by variants in their execution. In addition, a primary goal of the project was a high degree of automation so that the SLS team can ensure that even short-notice changes are translated on time. And another goal was to allow for flexible adjustments of the services to accommodate new or changed requirements.

With so many different moving parts, easily understandable process models were essential to the project. Figure 2 shows the result of the collaboration between business and IT in a BPMN model that could be created using any business-friendly BPMN modeler. Figure 3 shows the resulting executable BPMN model in SAP Process Orchestration. Note that the two models are identical — exactly what we wanted to achieve using the process-driven approach. The process-driven approach is generic and independent from concrete tools and environments, so it works with any BPMN-based modeling tool. The PDA methodology, with its uncluttered and collaborative approach to process modeling, was an ideal fit for the SLS project, enabling business users, BPMN specialists, developers, and user interface designers to easily discuss process logic, business functionality, user interfaces, and services.

Figure 2 — The BPMN-based process model from the business perspective

Figure 3 — The executable BPMN model in SAP Process Orchestration

As a result, the executable process is truly business-driven, and thanks to the early, intensive involvement of all users, acceptance of the model is all but guaranteed. Communication between the IT and business units is standardized through BPMN and is highly efficient because it virtually eliminates the risk of misunderstandings, and decreases the time between concept and implementation. In fact, although this project required the integration of more than 700 distributed systems, the creation and implementation of 65 process models following the PDA approach was achieved within eight months. Compared to traditional methodologies for implementing processes using programming languages such as ABAP and Java, the PDA approach has a time savings of roughly 75%.

With the successful completion of its PDA-based project, SAP has achieved two important goals:

1. SLS took a major step toward active process management, where business and IT work closely together and can adjust their processes more quickly and consistently.
2. SLS is now able to turn their unique business processes into a new business model that can be offered even outside SAP, making SLS a service provider for translation projects.

Summary

In a climate of continuous change, organizations need to ensure that their business processes are not only executing optimally, but that they can adapt at a moment’s notice. A process-driven approach that encourages collaboration among all stakeholders — from business analysts to technical developers — enables you to build sophisticated business processes that are efficient and agile enough to meet your business needs.

PDA is still a new concept, but as you saw from SAP’s language services example, it is also more than a concept — it works. And the opportunity is bigger than just supporting your unique business processes. The processes you implement could become a new offering for your customers or the foundation of a new business.

Learn more about how you can put the PDA methodology into practice in your own organization in Volker Stiehl’s book Process-Driven Applications with BPMN, available at www.springer.com/us/book/9783319072173, and from reading Bruce Silver’s comments at https://brsilver.com/process-driven-applications. 

^{1 Learn more about the BPMN specification at www.bpmn.org. [back]
2 For an in-depth introduction to process-driven architecture and applications, see Process-Driven Applications with BPMN by Volker Stiehl (Springer, 2014; www.springer.com/us/book/9783319072173). [back]
3 For more on business process modeling and implementation using BPMN 2.0, see BPMN Method and Style with BPMN Implementer’s Guide by Bruce Silver (Cody-Cassidy Press, October 17, 2011; https://brsilver.com/bpmn-method-and-style). [back]}