Vorwort: Der nachfolgende Beitrag von Dr. Volker Stiehl verlangt ein längeres Vorwort. Nicht weil der Beitrag auf Englisch ist, was freigestellt ist, insbesondere bei Leuten, die sehr häufig in den USA sind und die ganze wissenschaftliche Diskussion mehr oder weniger in englischer Sprache erleben. Für solche Wanderer zwischen zwei Welten ist es leichter, Englisch zu schreiben. Das war bei mir auch früher auch so, vor 40 Jahren. Und auf den Autor kommt es an, egal in welcher modernen, weit verbreiteten Sprache.

Ich überschreibe mein Vorwort mit dem Begriff „Selbstverständlich “, Französisch „cela va sans dire“ (das geht, ohne zu sagen), oder Englisch „it goes without saying“. Einige glauben, das sei ein „grober Germanismus“. Google beweist uns aber, dass das nicht so ist. In meinen Mathematik-Vorlesungen in Berkeley hieß es statt „selbstverständlich“ immer „it is tacitly assumed“ mit dem Erfolg, dass die Studenten Schwierigkeiten beim Nacharbeiten der Vorlesung hatten. Statt „selbstverständlich “oder wissenschaftlich „implizit“ wäre eine explizites Hinschreiben besser gewesen. Konstruktiv Arbeitende lieben das Implizite sowieso nicht. Es muss konstruktiv alles „schrittweise, zirkelfrei und explizit“ vorgetragen werden. Konstruktiv ist nicht selbstverständlich.

Bei genauerem Hinsehen erweist sich das Wörtchen „selbstverständlich“ als ein charakteristisches Phänomen unserer hoch-technisierten Wohlstandswelt. Kommunikation über iPhone oder iPad im Internet ist „selbstverständlich“. Mobilität per Auto, Flugzeug oder Eisenbahn ist „selbstverständlich“. Unser Mittagessen ist „selbstverständlich“. Prozesse, also gerichtete Abläufe eines Geschehens in unserer Wirtschaft sind „selbstverständlich“. Jetzt kommt es dicke: „Irrtum, lass los der Augen Band“ (Faust I ). Sobald wir uns einem Phänomen in wissenschaftlicher Absicht nähern, ist auf einmal nichts mehr selbstverständlich, und wir erkennen, dass Selbstverständlichkeit jede wissenschaftliche Neugierde abtötet. Für einen Newton war das Fallen eines Apfels vom Baum überhaupt nicht selbstverständlich. Wäre das Fallen für ihn selbstverständlich gewesen, dann wäre Newton nicht auf den Begriff der Gravitation gestoßen und seine Himmelsmechanik wäre nicht geboren worden. In diesem Sinne wenden wir uns den Prozessen in nicht selbstverständlicher Absicht zu und schauen genau hin, wie Volker Stiehl das macht. Sein Buch „Process-Driven Applications“ ist dabei unsere Richtschnur.

The Process-Driven Approach –
Past, Present, and Future

Volker Stiehl

Since the publication of the book “Process-Driven Applications with BPMN” a lot has happened: More and more companies want to understand how BPMN (Business Process Model and Notation – a graphical notation to model business processes) can help them to implement their differentiating processes faster and more flexibly than before. They understand the enormous potential of the process-driven approach (PDA) and want to benefit from it. Major projects set up using this approach provide evidence of its superiority over its predecessors when it comes to business process implementation. And we are just at the beginning. Let’s look at the different stages of the history of PDA from past to future.

The Past

Companies strive to differentiate themselves from their competition, there’s no doubt about that. Business processes are at the core of every company’s business and this makes them prime candidates for differentiation. However, up until a few years ago, there was no efficient implementation methodology for producing flexibly adaptable business processes. We were still in the Stone Age when it came to business process implementation. The spark for the process-driven approach came from the release of the BPMN 2.0 specification in January 2011. For the first time, execution semantics were defined for a graphical process notation by a standards organization (OMG – Object Management Group). It was clearly defined how a process should behave if executed by a process engine that complied with the BPMN 2.0 standard. Software vendors immediately started implementing the new process modeling standard, providing process engines that executed BPMN process diagrams. This was a big step forward and laid the foundation on which process-driven applications could prosper. However, following the process-driven approach is a steep learning curve and is quite an undertaking for a company. I’d like to share some experiences with you to explain why I think companies are still hesitant to jump on the PDA bandwagon, even though it doubtless brings benefits such as reduced development costs, better business/IT-alignment, and competitive advantage.

Well, I think there are various reasons for the hesitation and I want to start with a quote from Jeff Davis’ book Open Source SOA, where he explains how BPM and SOA complement each other and discusses the slow adoption of executable BPM: “We believe two major impediments exist: perceived complexity and paradigm resistance”. If I consider my own experiences I couldn’t agree more! Davis expands on the second point (paradigm resistance): “Paradigm shifts are often slow to materialize because of the risk of the unknown, and there are always pockets of resistance in learning new technologies. We contend that to not embrace BPM is far riskier, since the competitive landscape only rewards the agile.” Just a few sentences, but they hit the nail on the head!

Let me add my thoughts and experiences to this discussion of why companies are still hesitant. Here are some ideas to think about:

• First and foremost: Lack of knowledge about…
  • …BPMN itself: What does the standard already provide out of the box?
    BPMN is feature rich and very powerful. But the problem starts with the BPMN specification itself: It divides the BPMN shape set into different groups, called conformance classes. One reason for grouping BPMN elements in conformance classes was complexity. This presumes that some shapes are too complicated for business process experts and they won’t need them. What a mistake! I’ve given several courses in the meantime to business folks as well as to developers, and the outcome was more or less always identical: Once they understood even more complex constructs such as transactional or ad-hoc subprocesses, they immediately had scenarios in mind where they could use them. Sooner or later even business folks need the complete BPMN palette to cover their business requirements. In fact, those who were introduced to a reduced BPMN shape set complained that they had difficulties modeling certain scenarios due to (presumably) missing features. They were always surprised to hear that the function they so urgently needed was actually available in the BPMN standard and that it was part of the specification right from the beginning. I personally don’t understand why even educational books often don’t teach the complete shape set. Business folks are certainly not stupid and are willing to learn. Hence, I always teach the full BPMN palette and can report only good experiences – and this is how it should be.
  • …how to model expressive, self-explanatory BPMN models?
    Another interesting point which has been solved in the meantime. BPMN models should be understandable from the process model alone. In his book BPMN Method and Style, Bruce Silver describes in great detail how the goal of self-explanatory process diagrams can indeed be achieved. It just requires learning some rules and having the discipline to apply them. Definitely not rocket science and in fact it’s pretty easy to follow. In my trainings I’m always referring to Bruce Silver’s recommendations and students never have problems understanding it.
  • …how to modularize processes so that parts can easily be replaced, even during runtime, to increase overall process flexibility?
    In order to master the abovementioned requirements, modelers need a solid understanding of the different structuring options at their disposal. They need to know what hierarchical expansion is all about. Hierarchical expansion is a term coined by Bruce Silver in his book. I personally prefer the term 3D-modeling as modelers should not try to put their complete process logic onto one 2-dimensional page. If you want manageable process models, it is almost impossible for real-life processes to fit on one sheet of paper, because of their sheer size. If you want to ensure manageability and maintainability in your processes, modelers need to expand their modeling into three dimensions, which means organizing the process chunks into layers. They therefore need a sound understanding of how embedded subprocesses, call activities, event subprocesses, and loosely coupled processes using send/receive tasks actually work. It’s also important to know the differences and when to use what. Once you understand this, it’s quite easy to come up with neatly modularized process models allowing for maximum flexibility.
  • …how to preserve BPMN-based business processes during implementation?
    This is actually what the process-driven approach addresses with its layered architecture, which separates business process logic from integration process logic. As I’ve written at length about the motivation for the process-driven approach in another blog, I don’t want to repeat myself here. Instead, I’d just like to direct you to my reply to a reader’s comment on the SAP Community Network here. You have to scroll down a bit to find my lengthy reply.

• BPMN-based processes are perceived as too static/structured and not flexible enough. This impression comes from a lack of knowledge of the options for structuring BPMN processes and increasing their flexibility. This topic has already been discussed (see respective bullet point above). Let me add that even case management scenarios can be up to 95% modeled with the pure BPMN 2.0 standard, so in my opinion the discussion about BPMN’s inability to cover these cases as well as the discussion about an alternative language for modeling case management scenarios (CMMN – Case Management Model and Notation) are largely superfluous.

• No experience in building BPMN-based applications, resulting in developers misusing BPMN as a programming language. If we use BPMN as just another programming language (this has really happened – I’m not kidding) we end up with messy process diagrams with no value at all, because developers tend to add technical steps (e.g. connect to a backend system and map data from the format used in the process to the format the backend requires) and technical exception handling procedures (e.g. what happens in the case of a timeout for a reply message the process is waiting for?) to the core BPMN business processes delivered by the business folks. You can imagine what the resulting processes look like. The finished result is unrecognizable to the business side, leading to great frustration. Wasn’t BPMN introduced to improve communication between business and IT? Using it like this is a surefire way to derail the good intentions of BPMN to the point of absurdity. However, if applied correctly, BPMN can indeed deliver on the promise of improved communication between the two camps. Projects have shown that this is possible.

• Old habits die hard: many developers are still living in transactional times.
  The development of process-driven applications requires a different mindset because we have to consider a central process engine driving process execution forward. If developers are not willing to engage with process-driven development (e.g. because they have no experience with process engines and what that means), they are unlikely to see a positive outcome. Many developers are still thinking in terms of transactions and processes driven mainly by user interfaces. However, the fact is that companies want more automation and less user interaction – a trend that clearly favors PDAs, which try to increase automation in processes. This old way of thinking is certainly one of the biggest challenges to overcome and belongs to the “paradigm resistance” argument brought up by Jeff Davis above (fearing the unknown).

• Implementation of a new collaboration model between business and IT.
  I’m using the term BizDevs for this new way of collaboration and I first introduced it in my blog referred to above. In essence, it reflects the common responsibility for the business process models with both sides, business and IT, during the whole process lifecycle. Hence, business people become an integral part of the processes’ development cycle – a new accountability the business folks have to get used to. But, without this collaboration model, the implementation of BPMN-based process models becomes questionable at best. For me, BizDevs are an indispensable prerequisite for successful PDA implementations!

• Poor implementation of the BPMN standard in the BPMN engines.
  This point might surprise you, but it turns out that BPMN engines that don’t implement the full BPMN shape set force process implementers to live with workarounds. One simple example makes this point pretty clear: If the Inclusive Gateway implementation is missing, the modeler is forced to compensate for this by implementing the same semantics using Exclusive Gateways. However, this is cumbersome, error prone, and contradicts BPMN’s intention of providing an expressive modeling notation. What could be expressed by using just a handful of shapes ends up as an overly complex and bloated process diagram. The result for the business is again frustration. The same argument applies here as for learning BPMN: Only by implementing the complete shape set can the solution move forward. Don’t accept anything less. And don’t be swayed by your vendor’s argument that you can overcome the semantics of the missing shapes by using workarounds. That’s not why BPMN was introduced!

• BPMN-based process implementations are only something for large organizations.
  This certainly has something to do with the high price tag for business process management suites (BPMS), which were only affordable for large enterprises. Fortunately, this has changed dramatically and even small and medium-sized businesses (SMBs) can finally implement (and benefit from) the whole process-driven approach, as it can be built and run completely on open source software. The process-driven approach was based on a generic methodology right from the beginning and was not bound to any particular process engine. The only prerequisite was it supported BPMN. Besides that, any BPMN-compliant engine can be used. The argument that executable BPMN-based processes can only be applied in large companies is no longer valid – PDAs are ready for SMBs.

• BPMN perceived as too complex.
  Compared to alternative notations such as Event-driven Process Chains (EPCs) this is certainly true. However, if it comes to express a company’s real-life behavior using process models it is unavoidable to have a certain shape set at your disposal. And honestly, it is still manageable. See it also from a different angle: to model real-life business scenarios with a reduced shape set typically ends up in nasty workarounds, certainly something you want to avoid.

Now that I’ve talked so much about BPMN, it’s time to take a brief look at one concrete example. The following figure depicts a simple vacation request approval process:

It reveals already BPMN’s key strength: its intuitiveness. The diagram is immediately understandable even to someone who has never seen BPMN before but has a basic understanding about process models in general. Without diving into BPMN’s specific nomenclature, the process can easily be described: obviously an employee triggers the process by sending a vacation request. A manager has to approve it and depending on the manager’s decision the process continues accordingly. Either the employee has to update the vacation request in case of a rejection, or the process executes two steps in parallel: sending a message to a human capital management system (HCM-System) and informing the employee about the approval so that he/she can mark the vacation in his/her calendar accordingly. Once both activities have been completed, the process reaches its end.

It is as simple as that. However, bringing such a process to implementation is a completely different story and chances are high that the resulting BPMN-model being used for execution differs significantly from the model shown in the figure. Why? Because developers tend to add steps to the original model just to connect to systems and care for timeouts or other technical issues. The solution to this problem is the application of the process-driven approach depicted in the following figure:

You can identify the business process at the top of the figure and the technical details for implementing the Book Order step in the process diagram beneath. This clear separation of concerns allows preserving the original business process even during implementation. Another benefit is the usage of BPMN for technical integration processes as well, making BPMN to a universal language for all kinds of processes – an aspect that I will take up again at the end of this blog.

To sum up: the process-driven approach delivers on BPMN’s promises: It addresses the above mentioned challenges and, at the same time, ensures the following core benefits:

1. Dramatically reduced development costs for process-based applications
2. Better alignment between business and IT (BizDevs)
3. Gaining competitive advantage due to improved business agility and increased process flexibility as well as process adaptability to changing business needs/market conditions

The Present

 After reflecting on the various reasons why companies might be hesitant to implement executable processes based on BPMN, those who have done so are already reaping the benefits mentioned above. These benefits are no longer just theoretical– they are project proven! I’d like to especially stress the second point: Project participants are excited about the new quality of communication! Both sides are meeting each other at eye level. Self-explanatory BPMN process diagrams leave no room for interpretation – the implementations are immediately correct. Can you say the same of your last process implementation project? In addition: The BPMN process models are identical with the implemented ones and, at the same time, are the process documentation – all in one. BPMN has indeed become the common language between business and IT that it was originally intended to be. And finally: Both sides are highly motivated as they understand each other much better, both pulling together in the same direction.

This leads, of course, to more interest from other companies. The number of requests is constantly increasing. And it all starts with education. As you have seen from the list above, the main problem is a lack of knowledge. In order to make the approach tangible and applicable for every company, a workshop is a necessity to start you on your journey into process-driven applications. The core ingredients of this training are:

• BPMN 2.0 – the complete shape set
• Modeling expressive, self-explanatory business processes using BPMN
• Preserving your modeled processes during implementation – the process-driven approach
• BizDevs – learning how business and development can work effectively and efficiently together

If you are interested in a workshop, just drop me an e-mail at pda.consulting.vs@gmail.com. It is possible to get through the basics of PDA development within three days.

The Future

In times like these, which are marked by growing digitization, process-driven applications will play an increasingly important role in companies as they allow faster implementation of processes supporting the management’s key strategy. And time is becoming THE decisive factor in future process implementations. In order to prepare organizations for future challenges, a thorough education is a necessity. This starts in universities: Process-driven applications and their development need to become an integral part of the curricula for both business informatics as well as computer science. Only this combination ensures the realization of the BizDevs idea in companies – and this is crucial for the overall approach.

PDAs will need to be adjusted for the new hype topics of today: cloud computing, micro services, in- memory databases, eventing, big data, the internet of things, etc. However, the overall architecture of process-driven applications is already well-prepared for these developments, thanks to the clear separation of business processes and integration processes via dedicated service contracts (for details about the separation and how to implement it, see my book listed in the Literature section at the end of the blog). In combination with eventing, business rules, and integration, process-driven applications will reveal their full power. It will also be interesting to see how lightweight process engines can potentially be installed on embedded devices and drive the execution of more technical processes (called micro processes) in the devices themselves. BPMN could establish itself as the lingua franca for all kinds of processes, not only for business processes – ending up as a PMN (Process Model and Notation). The potential is there and would help all participants to talk to each other using the same process language.

Whatever the future brings, companies implementing the process-driven approach are well- positioned to face it, as this approach boosts the organization’s process efficiency. Now that we’ve identified the reasons why companies have been slow to adopt PDAs, and how to overcome them, the road ahead for PDAs is well mapped out. I’d like to encourage you to overcome your hesitation and try out PDAs for yourself. The topic is now well understood and real project experiences prove the validity of the benefits you will get by implementing PDAs. Now it’s up to you to act – it’s worth the effort!

Literature

• Davis, Jeff. 2009. “Open Source SOA”. Manning Publications.
• Silver, Bruce. 2011. “BPMN Method and Style, 2nd Edition”. Cody-Cassidy Press.
• Stiehl, Volker. 2014. “Process-Driven Applications with BPMN”. Springer.