Holy War: Orchestration vs Choreography

Much has already been discussed about orchestration vs. choreography. The topic tends to divide the best of friends into either the orchestration camp or the choreography camp.

When working with an Event Driven architecture, addressing this topic is essential since EDA is fundamentally needed when building a sytem that uses the concept of choreography.

Let’s briefly recap the terms.

Choreography automates a process, workflow, or value chain without relying on a central component. Each actor in the process publishes relevant events when significant actions occur. Other actors in the process listen for these events and trigger their corresponding functionalities. This approach is inherently asynchronous.

Orchestration is also a method for automating processes, workflows and value chains using a central point called the orchestrator. This orchestrator follows a predefined process blueprint, often created using BPEL or BPMN. Based on this blueprint, it invokes actors to perform functions, which can be done synchronously, asynchronously, or in a combination.

Both approaches have their advantages and disadvantages.

Choreography offers flexibility because there is no a central point, making system modifications is easy. New actors can be deployed to listen for events that trigger their processing, and both new and existing actors can publish events for new functionality. Other actors in the system are responsible for reacting to and triggering the associated functionality.

This brings us to a major drawback of the system: governance, reporting, and clarity.

Governance:

• What events are associated with a particular process?
  Which actors (components) are linked to a specific process?

Since there is no central controller, there is a significant risk that, over time, events and actors may proliferate, and maintaining a clear overview becomes challenging.

Reporting:

• How many instances of a process are currently in progress?
• What is the status of various processes?
• What is the average execution time for a typical process?
• Which step in a process has the longest execution time?

Answering these questions is not trivial. Additionally, identifying when a certain process instance has come to a halt and finding the cause of this halt is also not easy.

It’s not that all these questions are unanswerable, but they require more effort.

Finally, there’s the challenge of clarity. Who will be able to provide an exact overview of how the process works after one year and numerous updates?

When opting for an orchestration solution, you’ll encounter several components during the setup:

• Process Designer: The first component allows you to design your process, identifying its various steps. Most of these tools offer a graphical interface and utilize either standard notations like BPMN or BPEL, or they may use a proprietary language.
  Once the design phase is complete, the technical team uses the “process designer” to establish connections between the different functional components and the process. This step is essential to ensure the desired functionality can be executed.
• Runtime: With the connections in place, the process can be deployed to the runtime component. This central component is responsible for executing different instances of the defined process. Running all process instances on this central component makes it easy to gather statistics on the various process executions.
• Intelligence: Finally, the solution often includes functionality for analyzing your processes, sometimes even in real-time.

When examining this concise overview, it becomes evident that orchestration has several notable strengths:

• Governance, Reporting, and Clarity: Since the entire process is designed upfront and executed in a controlled environment, governance, reporting, and clarity are effectively addressed. Processes are meticulously designed from the outset, and it’s clear who is involved in the process. Capturing essential intelligence data is also straightforward.

Despite its advantages, orchestration does come with a significant drawback:

• Lack of Flexibility: As processes need to be designed and “wired-up” in advance, making changes to them is not a straightforward task. This approach also introduces challenges related to versioning processes. When a new version of the process blueprint is introduced, questions arise about what happens to instances of the previous version still in execution.
• Infrastructure need: It requires a dedicated platform and possible a dedicated team to manage and govern that platform.

Side Note: Process Instance

A process instance represents the execution of a specific process blueprint. For instance, consider a “product registration” blueprint outlining steps such as inputting product data, capturing commercial photos, and obtaining product manager approval for commercial release. An instance, in this context, is the actual execution of these steps for a single product. If there is a need to register two new products, like product A and product B, this would result in two distinct process instances.

Over the years, both approaches have made significant strides in addressing their respective weaknesses and have become highly proficient in automating processes. To make the right choice, carefully assess your specific situation and prioritize the requirements that matter most to you.

That said, if I were to make a definitive statement, I would suggest examining your enterprise architecture. In a previous blog of mine titled ‘EDA: What Does It Mean,’ I introduced a fictitious model with certain assumptions. In that model, I drew a distinction between ‘value chains’ and ‘business processes/workflows.’ In this context, I would argue that choreography is better suited for ‘Value Chains,’ whereas orchestration is more suitable for traditional business processes and workflows.