The Architect Always Implements #

Discussing concepts is only half the fun if you cannot point to concrete code examples. Runnable code forces you to be precise, to think about details you can leave out on the conceptual level and, most importantly, it often explains things best. I am personally a big fan of the motto “the architect always implements”.

This is why there is source code belonging to this book, which you can find in this part of the website. These examples will not only help you better understand the concepts described in this book - they also give you a great opportunity to play with technology whenever you are bored from reading.

Examples Overview #

• Customer Onboarding Example: A process solution used in Chapter 2 of the book to introduce executable process models. It contains a process to onboard new mobile phone customers in a telecommunication company.
• Order Fulfillment Example: Example using microservices implementing an end-to-end order fullfilment process that involves multiple microservices and various local process models. While also mentioned at multiple places in the book, it is the core example in Chapter 7 and Chapter 8.
• Other Example: Curated list of interesting links to more executable examples, typically demonstrating specific concepts.

License #

The book and this website is here to help you get your job done. In general, if example code is offered here or in the book, you may use it in your programs and documentation. You do not need to contact me for permission, code on Github is typically licensed under Apache 2 or MIT anyway.

I appreciate, but generally do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN.

Technology Choices #

Note, that in order to provide code I have to decide on a concrete technology (which might not be the technology of your choice) and on concrete products (that might be outdated when you read this). And as co-founder of the process automation vendor Camunda, I am of course opinionated and tend to use the tooling I know best, which is the one my company is providing.

I decided for the following approach: In the book I write as vendor-neutral as possible. My opinions of course also influence our product, which means there is some kind of alignment unavoidable. But as process automation addict with 20 years of real-world experience, the book will be rooted in the frontline customer engagements that have formed those opinions