New SAP book: Process-Driven Applications with BPMN

Hi Gareth,

Sorry for my delay in replying, but I wanted to wait until I was actually holding the first
copy of the book in my hands before responding – and yes, it is out now 🙂 . So thanks for your patience and thank you for ordering it!

This gives me the opportunity to quickly sum up what the book is about and why I think it is important.

My motivation to write the book was sparked by one simple question: How can
companies within the same industry differentiate themselves from one another?
If you think about it, there are three main areas where companies can innovate
and differentiate: products, services, and business processes. Since we IT folks have little influence on products and services, we can support the drive for innovation on the business process side. Ultimately, everything we develop ends up in business processes, be it cool user interfaces using the latest UI technology or apps running on mobile devices – in the end they all contribute to business processes. Or think about
the results of your analytical applications - how do you act on your findings? Most probably using business processes. And finally, think about all the events originating from the Internet of Things – how do you react to these? Once again, business processes come into play. So, you see, business processes really are a great big playground where companies can innovate.

The good news: Innovation on the business process side is less visible to the competition than on the products and services side. Here I’d like to remind you
of Steve Job’s excellent presentation of the iPhone on January 9^th, 2007 during the Macworld conference. If you haven’t seen the presentation yet, I’d encourage you to do so; it is remarkable and I still get goose bumps when watching it. However, Steve was wrong on one point he made. He said that the iPhone has “Software that’s at least five years ahead of what’s on any other phone”. But we all know how quickly the competition caught up. It is inevitable that if products/services are convincing, with a high “demand” factor for customers (as was the case with the iPhone), the competition will catch up very quickly, and it is difficult for companies to keep coming up with new breakthrough innovations to stay ahead of the pack. In addition, think about industries with saturated markets – here, companies only have one option to focus on: their business processes! The good thing about innovations on the business process side is that they are much harder for competitors to copy; companies don’t openly promote their process improvements as they (must) do their products and/or services. Processes are optimized behind the scenes, where they are hidden from the competition.

So, if companies innovate in all three areas (products, services, business processes),
the chances are high that they will be successful, and even be among the leaders in their respective industry.

If we take a closer look at business processes we can distinguish between standard
business processes and unique, company-specific, differentiating business processes. Standard processes are well covered by standard products and it doesn’t make too much sense for companies to implement these themselves. Depending on the importance of the business processes and the data that they handle, companies can run them either in the cloud (the less critical processes) or on premise (the more security-sensitive processes). However, companies cannot do much to differentiate themselves from the competition by using standard processes, so the next question we have to answer is this: How can companies quickly and sustainably build, run, and monitor differentiating business processes? And this is exactly why this book was written. It explains in detail the methodology, the architecture, and what the concrete implementation for differentiating business processes looks like. I call this approach “process-driven application systems” (PDA) because it stresses the importance of business processes as the main driver for all the decisions developers have to make during the development process.

The approach described in the book relies heavily on BPMN (Business Process Model
and Notation) and it was actually only made possible by the latest enhancements to the BPMN 2.0 specification: I’m referring here to the execution of BPMN-based process models by BPMN-compliant process engines. Since the development of business processes based on BPMN differs significantly from conventional software development, it was my goal to help developers avoid the traps we encountered in the early projects, and so the book focuses on practice as well as theory.

In the preface of the German version of the book, Prof. Erich Ortner summarizes some
of the transitions that the industry is currently facing and that are addressed by the process-driven approach. He believes that a new era is about to start. He writes (loosely translated):

“This heralds a new era, as the IT that we rely on in our work and our lives is shaped by three transitions: a focus on enterprise engineering that encompasses the whole organization, rather than “just” software engineering; the creation of application systems rather than “just” information systems; event processing rather than “just” data processing.  Events are fundamentally different from data and have to be handled, processed, and controlled in a different way.”

I firmly believe in his words – and we are just at the beginning. And talking of events, the loosely-coupled approach of process-driven application systems means that the architecture is already perfectly prepared for the reactive (programming) paradigm laid out in the reactive manifesto. Clearly we are thinking in the same direction 🙂 .

There is another important aspect covered in the book that I’d like to stress here: the
question of whether a roundtrip of one BPMN model between the business and IT teams is possible or not. There have been several discussions on this, which brings me to issue of finding the right collaboration model between business and IT. My standpoint on this is that if we (business and IT) continue to collaborate as we have in the past (the business team writes a specification, which the IT side then has to implement – I sometimes call this a “dictate” from the business side), then we will fail. However, with BPMN as the common language between business and IT we can work on new levels! The new collaboration model is based on collaborative work on one BPMN model, which is then executed, as it is, by a BPMN engine. This is possible if organizations are willing to follow the new collaboration model described in the book, where both sides are equally responsible for one BPMN model, which is preserved throughout the transition to execution. The responsibility for the executed model is now extended to the business side, so there can be no more finger-pointing between the two camps. I’d like to use the term BizDevs for this new collaboration model (this describes the collaboration between business and development and has nothing to do with “business development”; the term is influenced by the recently introduced term “DevOps”, which describes the collaboration between development and operations).

We can also look at this discussion from another angle. Companies spend a lot of time and money on modeling their differentiating business processes. Modelers are
increasingly using BPMN for this purpose, ideally using the modeling recommendations given by Bruce Silver in his book BPMN Method & Style. Why should these valuable process models be sacrificed (and modified) just to make them executable? Why would you create two models: one for the business side and one for execution? And who then is responsible for synchronization? Aren’t we ending up in the same old trap, where the documented processes differ from the executed processes? What use are the processes then? And can companies really afford the effort of double-maintenance? This doesn’t make any sense to me! It also blatantly contradicts the original intention of BPMN, which is clearly set out right at the beginning of the BPMN 2.0 specification: “BPMN creates a standardized bridge for the gap between the business process design and process implementation”. We should take any action necessary to keep this dream alive! Bruce Silver has written a remarkable preface for the English version of my book that echoes these sentiments.

This new collaboration model certainly has implications for students in higher education, especially in the subjects Informatics and Business Informatics, since students of both disciplines will need to be able to apply the collaboration model in
their companies later on. It is therefore important that they learn the process-driven approach and the BizDevs collaboration model. However, this is a separate topic and I won’t discuss it here.

One final point: As I’ve explained above, the whole process-driven approach relies heavily on BPMN and structured processes. Now, you might well be asking yourself whether this isn’t already outdated, because the process community is already talking
about the next “big thing”, Adaptive Case Management (ACM). ACM is all about
unstructured processes, targeting knowledge workers in particular. The assumption is that ACM processes cannot be captured using BPMN as we cannot predict the execution sequence of the process steps. So, shouldn’t we back this horse instead? My standpoint is pretty clear: In the majority of cases, customers want to avoid time-consuming and costly human collaborations and are striving for as much automation as possible. I’m not saying that there are no use cases for ACM, but, considering the number of automated processes, ACM is, in my eyes, overrated. And even in cases where ACM makes sense (for example, the collaboration between physicians in hospitals), a lot can still be covered using BPMN in combination with business rules, as discussed in a dedicated chapter in the book. Take the Internet of Things as another example: It is all about massive automation and this is a domain with huge opportunities for differentiation and competitive advantage if companies apply the process-driven methodology. Ultimately, companies with process-driven application systems are well prepared for the future. Having said this, it should be said that there is no “either-or” between ACM and PDA. They actually complement each other very
well.

This brings me to the end of my short ( 😉 ) reply. The way we model and develop innovative processes based on executable BPMN is indeed a game changer! It not only affects the architecture and the development of application systems but also the way business and IT collaborate (keyword: BizDevs – see above).  In my view, the
process-driven approach is the most promising way for companies to move forward
and keep pace with change. It gives them the opportunity to flexibly adjust their processes to changing market conditions and, by doing so, to keep their competitive advantage.

I hope I’ve been able to explain what motivated me to write the book. Now it’s up to you: Enjoy reading and let me know what you think!

Volker