Is BPM Dead, Long Live Microservices?
![Image](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCu7CjePl2TYjIxHejPmxsTugkP2CLpK33e4NQFMkSqDrf7eAiryfD1RBz5MkyEvZ3flwWVaZdIur4lIQJgptWJc4E0mk79mxEBex1beLRHGo_x1IcC9Lj7Dj9Qhy0oBjoUgGiZmmbm0I/s640/1-ChoreographyVsOrchestration.png)
With the massive uptake of Microservices Architecture -industry wide- and with it, the adoption of patterns such as Event Sourcing , CQRS and Saga as the means for Microservices to asynchronously communicate with each and effectively " choreograph " business processes, it might seem as if the days of process orchestration using BPM engines (e.g. Oracle Process Cloud now also part of Oracle Integration Cloud , Pega, Appian, etc) or BPEL (or BPEL-like) engines are over. Although the use of choreography and associated patterns (such as the aforementioned) makes tons of sense in many use cases, I've come across a number of them where choreography can be impractical. Some examples: Data needs to be collected and aggregated from multiple services -e.g. check the Microservice.io Composition pattern . Note that this pattern doesn't necessarily implies that an orchestration is required. Could be that data is collected and aggregated (not transformed) into a