Blogs & Articles

Ever wondered about the practical implications of using optimistic locking in a process engine like Camunda 7? Explore the impacts on process execution and discover the intriguing dynamics, especially when messages arrive concurrently. Also, asynchronous continuations play a role, sometimes alleviating issues, while in other scenarios, they can (perhaps surprisingly) worsen the situation.

Planning your API life-cycle and especially the decommissioning of APIs and API versions due to breaking changes is a necessity. I want to add some thoughts about why the idea to have no breaking changes ever is illusional and go into discussing some drivers for breaking changes.

Previously, I wrote about the necessity to define the life-cycle of your API which includes a process on how to introduce possibly breaking changes. The logical next step is to discuss possible solutions. Luckily, there are already some sources. In this blog post I will focus on API design patterns as documented in our book “Patterns for API Design”.

One of the worst-rated aspects of APIs in organizations is life-cycle management. In this blog article I dive into misconceptions and typical challenges when defining API life-cycles.

At the end of 2023 I gave two talks. These were interesting for two reasons. One of them was the challenges that attendees had with their APIs which I will further describe in this blog article

While Camunda covers this topic in the documentation, I personally only got a full grasp on asynchronous continuations after playing around with them in different scenarios. This is why I want to highlight some insights on the impact they can have on processes that might not be completely clear just by reading the documentation.

API-First development has gained traction in the last couple of month. On its face its nothing new: Contract-First design is an old concept and even in the old SOA(P) days, it was considered best practice to design the interface of the service first and then do the backend implementation.

Have you learned BPMN in some class or with some book and your source simply told you – hey, it is good practice to place Start and End Events at the beginning and the end of your process model? But do you know why and how you should place those elements? And how they can really help you in process workshops and when creating or reviewing process models? So, let’s start…

A while back I needed to model a development process of a company. While creating the model I realized that the process-flow got quite complex, and I struggled to lay it out in an understandable way. That motivated me to do a little “experiment”.

Recently, Eric Wilde interviewed me on his YouTube channel. I want to share with you the video in which we talk about design pattens for API design.

When naming ID references in attributes or database columns, a simple but crucial mistake is made very often. Explore with me what the simple mistake is, which has cost several projects thousands of dollars (or equivalent).

I recently was involved in a discussion that I didn't think I would have in 2021. It was about the setup of database users for a Web application. Come and let's dive into some problems, which we should rectify once and for all!

This article will discuss a study which I did together with Tobias Unger and Daniel Wutke back in 2018: We analyzed three different business process-oriented projects with 184 BPEL processes with regards to their process-flow and data-flow complexity. We found that data transformation logic is larger and more complex than the process logic. Read on to understand how we came to these results and what this means for software development!

Welcome to the fifth part of our implementation series of a BPMN model in (Java) code! We came a long way and only two parts of this series are remaining. Today we deal with the problem of hanging threads, which we postponed until now.

Welcome to the fourth part of our implementation series of a BPMN model in (Java) code. We came a long way up and until the asynchronous reception of multiple, correlated messages. Although we have some technical details open, which I will address in a future part, we will step back and look at our "integration architecture" and how BPMN can also help us to improve our service/API design. In particular, we will see how BPMN "recommends" us to use the Request Bundle Microservice API Pattern.

Welcome to the third part of our implementation series of a BPMN model in (Java) code. We came a long way, but we need to deal with asynchronous message receives now. Yes, still no workflow engine... Our main objective to have easily comprehensible and well-structured code. But be aware that this series' example is concerned with a short-lived process without recoverability!

Welcome to the second part of our implementation series of a BPMN model in (Java) code. Yes, no workflow engine, just a demonstration how your source code will improve if you directly reflect the business domain and its processes. Our main objective to still have easily comprehensible and well-structured code. But be aware that this series' example is concerned with a short-lived process without recoverability.

Many developers don't like to concern themselves with the business side of their applications. Quite frequently I see that the whole business context, including business goals and business processes, is neglected, not understood, and not cared about. However, modeling business processes first as part of the requirements analysis and then transferring them into software (code) can make your source code better structured and easier to understand. Let us dive into why this is the case.

Pagination is very important pattern for API design. Thus, it is part of the Microservice API Pattern project where you can also find a good explanation of it. However, I often see this pattern implemented without reaping all of its benefits with regards to efficiency. Within this blog post I want to discuss two pitfalls and options for addressing them.

Modeling business processes can really help you to find out what information you think is correct and whether you can connect all the dots, i.e., the activities, so that everything play together. In this post I will show you two anti-patterns that are easily detectable when you formally model in BPMN. But don't be scared of "formally". It just means doing it right and knowing the syntax and semantics of the modeling language. I will show you of what you need to take care of.

There are forbidden words that you should avoid to use by all means necessary when naming operations, functions, or methods. For example, starting your names with do or make is the best way to create one of the worst identifier names. So let's dive into it.

Introduce your customer to the most number of your departments and employees in order to check whether your services are so good that he/she is crazy enough to still use them. In case he/she is even crazier, you have identified the best next employee to hire, which coincidentially already has a deeper understanding of your organization than your managers!

Since years I am very unsatisfied with the state of generator tools, which generate (Java) classes from service contracts (WSDL, Swapper/OpenAPI etc.). Most of my concerns are on the one hand centered around the problems they cause with compile-time checks (i.e., static typing) and on the other hand they do not fully embrace compile-time checks where they would help developers. So it’s kind of the worst of two worlds. But what would be the "best" API for creating message payloads look like?

Software development professionals are blinded by their experience while researchers don't have any. Good empirical research combines their strengths (experience and objectivity) and advance the knowledge on how to develop software better. Let's do it!

In software development projects we often think about the software. It is centered in our mind as the only important thing we need to care about. We try to make it more efficient, to make the code cleaner, we think about maintainability about performance and about availability. If we are an advanced software engineer, we also think about the usability and the end user. However, the customer will sooner or later realize that not the software is important but that it is the solution to his or her problems.

Unreasonable Software Development is the use of frameworks and libraries instead of common sense.

Today I gave my talk about Process-aware Microservice Design at the JAX 2020 conference in Mainz, Germany. It was an interesting experience because Corona is still a threat and as a result the conference was organized as a hybrid conference. Participants could join on-site or remotely via video conferencing. As a result, the conference floor was pretty empty.

Next week I am on vacations and thus I worked on my slides for my JAX talk about Matrix Organizations, Conway's Law and Microservices. I haven't probably finished my slides for a talk so early!