Orchestration vs. Choreography – different patterns of getting systems to work together

Introduction 

Krzysztof (Interviewer): Business organization is a composition of experts providing products or services in the area they know the best to gain their shared business outcome. For example, the Marketing Team works hard to gain new Clients, the Sales Team sells products to those Clients, and the Customer Relations Team takes care of positive customer experience and retention. Shared business goals and a profit can be achieved only when those teams work together. The question of how to compose and arrange their services to implement Business Process Management is the key part that defines how the whole organization works. Today we will be debating on the best method to do so. We have Choreography Pattern and Orchestration Pattern – our speakers in the Debate. Can you please introduce yourselves? 

Orchestration Pattern: Thank you for organizing this Debate. I am Orchestration Pattern, and I believe that only a centralized and well-organized component can provide stability and tracing for Business Process Management. This is like an orchestra concert – we have a conductor showing every group of musicians when to play their part. Without him, musicians would be playing chaos instead of a symphony. The same thing works with IT Systems – if we have the Orchestrator in the middle of our systems communication, we will be able to manage our process, and verify its status easily.  

Choreography Pattern: I am glad I was invited to participate in this talk. Thank you for having me. I am Choreography Pattern, and my point of view on systems communication rules is opposed to that of Orchestration Pattern. I believe that an additional decision-making component in the middle of our IT ecosystem is redundant. What is more, I believe that components should be autonomic and coupled loosely enough to provide the business value itself, without impacting others. This is like with a jazz band, when musicians are waiting for others to stop playing, and continue their freestyle related to melody another team had introduced. With such an approach, we have one component less to maintain, and we don’t have one big single point of truth, which is difficult to manage.  

Round 1: IT Systems Design 

Krzysztof (Interviewer): Thank you for this quick introduction. Now, we will start round 1, and we will discuss your ideas from a technical perspective at first. The question here is – are you not just different names for synchronous and asynchronous communications?  

Orchestration Pattern: No! I can implement both communication patterns. That is why my Orchestrator Component is so crucial. Let me elaborate on the example you introduced at the beginning. When the Marketing Team gains a new Client, Customer Relations and Sales Teams should be aware of it and update Client information – so as to when a salesperson wants to call the Client, they can immediately gain information about them, all communications which occurred and all purchases the Client had made. Here is how I would implement those two functionalities. 

Async Client Synchronization with Orchestration Pattern 

Synch Client Details Response with Orchestration Pattern 

Choreography Pattern: I agree with Orchestration Pattern in the matter of names – I can implement synch and async communication as well. I just don’t agree that the Orchestrator Component is crucial. Let me re-design an Orchestration Pattern’s idea because I can still provide the same business functionalities without an all-mighty element in the middle. 

Async Client Synchronization with Choreography Pattern 

Synch Client Details Response with Choreography Pattern 

As you can see, I can do the same Business Logic, but using less business logic components, with more flexible design.  

Orchestration Pattern: Your design looks terribly complicated! And, I can see an element in the middle – this Events System. So, I can’t agree there are fewer business logic components. Isn’t it just the Orchestrator but with another name? And, to be honest, I just can’t see this flexibility here…. 

Choreography Pattern: First of all, you missed the fact that your design will look significantly complicated if you place error handling in the Orchestrator. How would you react if the CRM system did not respond in the Client Synchronization? You need to implement repetitions and business logic around informing the Online Shop about the situation. Let me re-phrase your design with this missing part. 

Orchestrator needs to handle errors and systems unavailability. With Choreography, components just wait for proper events 

At the same time, my components just wait for a proper event – no changes need to be made there, and there’s no error to be handled by a third party because of the inaccessibility of one system. With that, your design does not look that simple because you need to handle all “what ifs”.  

Second – my Events System is not a business logic component. This is a space where systems publish events about their processing. There is no business logic included – it is like a forum, where everyone shares what they did. This gives me the flexibility I was talking about – if I don’t want emails to be sent by the Correspondence System during the Customer Registration Process, I just disable the listener in this Correspondence System. For other components, this change is invisible. In your design, you need to make business logic changes in the Orchestrator.  

Orchestration Pattern: It all sounds fine as long as the process is not interrupted with an error or unexpected behavior. What happens then? If one of your elements fails, or simply does not publish a proper event, the whole business process hangs up. And we don’t have a place where we can trigger the end of such a process. 

Choreography Pattern: This is what we need monitoring and tracing tools for. Those light-weight technical applications should have alerts for not-consumed events or stuck processes without end events. We can either automate the generation of end events by those tools, or let human decide what to do, as is the case with Orchestration Pattern, but not in one, big, almighty element. Yet, you have a point – it is more difficult to plan and manage with me than with Orchestration. 

Round 2: Change Management 

Krzysztof (Interviewer): Thank you for this exciting discussion in round 1. You have already mentioned a topic we are going to discuss now – the Change Management. In this round, we will look at the flexibility to change and impact a change in the solutions you propose. So, how fast can you deliver new functionalities and processes with your approach? How difficult will changing the existing ones be? And finally, if you introduce a change in one component, what will happen in other components? 

Orchestration Pattern: Choreography Pattern accused me that each change of my architectures requires a large number of adjustments in multiple components. That is not exactly right. Yes, I agree that changing a process itself would require changes in the orchestrator component responsible for the process. But such a change will not always entail a huge impact. Having ESB as an integration platform, we reduce the number of changes in the Orchestrator for the data mapping part. On top of that, having BPM Engines as Orchestrators, simplifies change delivery in the business process itself. If we change the structure of Data in one component, we will need a similar structure in components, that consume the Data. I doubt we can avoid such situations with Choreography Pattern, so in the case of Change Management, I believe we are close. 

With Orchestration, a lot of changes requires some adjustments in the Orchestrator Element

Choreography Pattern: I strongly disagree that we are close. To prove that, I would like to refer to the very basics of our concepts. Orchestration is like an Orchestra Concert. If we want to change the violin section, we need to write a new melody for the violinist every time, and sometimes ask the Conductor to conduct a bit differently. As I mentioned, I am more like a jazz band – if one of my musicians wants to play a different part, I just allow him to do so. Of course, he can totally change a melody, and other musicians will also want to react to it – but I just leave it to their decision. In a worst-case scenario, which is an unsynchronized change, they will stop playing at all, waiting for an old melody to come up. A worst-case scenario for Orchestra is that they are playing a mess that hurts your ears. To be honest, I would prefer silence… But ok, now let me come back to some examples and refer to the processing from round 1. I’ve already provided the first one – if we want to remove sending emails, we just disable the Correspondence System. Of course, later, we will probably remove also the CRM listener for event #3, which is responsible for communication history synchronization – but not doing so won’t cause any errors. The second example is data mapping. In Orchestration Pattern, the Orchestrator is responsible for tracking data structure changes. Even a small change in a data structure would require adjustments in the Orchestrator. My designs are also not free of such problems – but I want my events to be created with simple data models describing only Business Object basic attributes. Of course, Orchestrator Pattern can always use such models, but with my designs, we still have one component less to change – the Orchestrator Element. 

With Choreography, the number of changes in more than two components is smaller 

Round 3: Business Process Tracing & Data Management 

Krzysztof (Interviewer): Now, let us move to round 3, where we will be discussing on the Data Management and tracing a process execution. As Sam Newman says in Building Microservices: ”As we start to model more and more complex logic, we have to deal with the problem of managing business processes that stretch across the boundary of individual services”. There are a few questions here – how do you view sharing and maintaining data between your multiple components? And what is your plan for verifying the status of the process instance?  

Orchestration Pattern: This topic is very simple as regards my designs. Let me start with the Data Management. All information is cataloged into pieces and stored in my components without any unnecessary duplications. If one component needs more data, it just asks the Orchestrator – and it collects and provides what it requires, with proper data mappings (for example, handled by the ESB platform). And now comes the biggest advantage of mine – tracing processes are incorporated directly in my Orchestrator. An end-to-end process takes place and is managed by this element. You know exactly where you are in the process at the moment just by accessing one component. I doubt that Choreography Pattern has as simple idea as mine.  

Process Tracing in Orchestration Pattern is concentrated in the Orchestrator Component

Choreography Pattern: This topic can be addressed with my designs too. I would also start with Data Management. With me, data is being shared around the organization with events and the correlation identifier (which is being produced by the business process initiator). Data can be duplicated in components for further usage, with the model adjusted to the component business function. Just look again at the Synch Client Details Response with Choreography Pattern sequence diagram. In my designs, there is no need to call the third party for data, because it is being synchronized between components in case it will be necessary for business processing. The next topic is tracing – and here I agree that it can be more complex with me than with the Orchestrator. But, having the correlation identifier generated by the process initiator, we can still easily connect sub-processes that compose a bigger business process.  

Processes in Choreography Pattern are more distributed, so tracing can be a challenge

Orchestration Pattern: So, it looks like I am right, and tracing processes are much easier with me. Choreography needs to have additional, dedicated tools for such a purpose – I can use my Orchestrator to play that part as well. What is more, using data stored in my Orchestrator, I can easily make reporting and crucial decisions. This distributed logic Choreography proposes can be a real challenge. 

Choreography Pattern: I agree – it is challenging. But without the centralized decision-making engine, we can use more light-weight tools for tracing rather than the Orchestrator for doing everything. The same goes for reporting – I can have a system or a microservice designed only for that. This approach is widely used in microservices ecosystems. I just like my architecture components to be autonomic and work independently, providing a specific, well-defined business function– rather than one complicated Orchestrator, tempting to be a Central IT System of the organization. 

Round 4: Organization Impact 

Krzysztof (Interviewer): Wow, we had a very exciting discussion in round 3. In their last sentence, Choreography mentioned the organization’s impact. Now, let us discuss a high-level perspective on that. How do you think the organization will change when it chooses you as a widely used pattern? Do you believe that the IT systems design influences on how the company works? Or maybe it is otherwise – the company structure is reflected in the IT ecosystem? 

Choreography Pattern: That is actually a very interesting question. The CEO-Choreographer would say to his directors: “My Vision is to become the biggest hygiene mask producer in Europe. I am all ears now for your ideas”. Then, the Marketing Director would come up with a campaign for new markets, the Sales Director would immediately start calculating his current sales level, and Factory Directors would be waiting for Marketing Director’s predictions on sales, so they could adjust the number of products they would need to create. This approach has two big advantages. First, those Directors are fully responsible for their ideas and inputs. They know that the growth the company has is also their doing. The second advantage is that the CEO has much less work, and his burden of responsibility is smaller.  

Orchestration Pattern: Indeed, it is a relevant question. Orchestration introduces a strict order in the Organization, which is a crucial weakness of Choreography, where this order might not be well-defined. The CEO-Orchestrator would say to his directors: “My Vision is to become the biggest hygiene mask producer in Europe. To do so, I want the Marketing Director to create a campaign for new markets, the Sales Director to focus on current sales level to no unnecessary financial troubles bothered us, and Factory Directors to double their production”. This CEO has thought everything out, and the whole company knows that he will lead them to success. Maybe his burden is greater – but at least he knows how the organization works. Of course, on some level of abstraction – because his directors think of their tasks, and orchestrate processes in their units to realize low-level processes. If you asked whether this has any reflection in IT Systems design – I would say “yes.” Melving E. Conway  has the same opinion, which is in evidence that he introduced Conway’s Law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” In my case, the Orchestrator will reflect a strong management position and order in the Organization.  

Choreography Pattern: Choreography does not involve any order in the organization – it is just divided between multiple autonomic Teams. What if the CEO-Orchestrator becomes sick? What if he is wrong? With Choreography, we have not only more space for discussion, but also more autonomic, responsible Teams sharing their inputs and improvements. I agree with Orchestration Pattern that the IT Systems design is reflecting the organization’s communication structure. But I would go further with that – I believe that implementing Choreography Patterns in IT Systems will make small teams start working in the same way. Then, choreography is being spread in bigger organization units, and finally – it will come to the CEO. A wise one will notice that he is no longer alone with decisions, he can delegate more work, and he can rely on teams fully responsible for their business functions. At the end of the day, he will have less work and less to worry about, and his employees will feel more responsible for the organization. To conclude – I agree that Conway’s Law works, but with me, it can work in reverse as well. In such a case microservices and choreography would result in small, agile, business-oriented teams. 

Orchestration Pattern: With me, this CEO will know immediately that he is wrong. With simple processes tracing and monitoring outcomes, it is easy to find a bug in the process. With Choreography Pattern, you might probably know that something is not working well, but you will spend more time debugging and looking for the unit responsible. What I can agree on is that Conway’s Law also works on reverse – having one or few systems for business rules implementation, we will shortly come up with a similar management structure making crucial business decisions.  

Conclusion 

Krzysztof (Interviewer): Thank you for your participation, insights, and shared ideas. I hope this debate will be very helpful in the upcoming weeks, months and years when dozens of organizations will be voting for the best pattern to use in their projects. Personally, I would vote for Choreography Pattern. I don’t think Orchestration Pattern is a bad one – but solutions designed with Choreography are more flexible, technology agnostic, and can be tailor-made to meet our Customers’ requirements. Choreography Pattern also helped us build Starboost – the Microservice Canvas, which proved to be reliable, scalable & adjustable for real-case business scenarios. I believe that Choreography will make IT systems great again, and it has my vote in current and incoming projects. And what about you, my dear reader?