This blogpost is inspired by several blogposts about microservices and it is based on the blogpost [REF1] “Architecting #cloud-friendly application architecture #apparch (inspired by #microservices)” http://improving-bpm-systems.blogspot.ch/2015/04/architecting-cloud-friendly-application.html
See also the previous blogposts of “Beauty of #microservices” series
- “Beauty of #microservices: part 1 #entarch #apparch” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-1-entarch.html
- “Beauty of #microservices: part 2 architecting for change” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-2.html
- “Beauty of #microservices: part 3 employ #BPM to tame the service granularly beast” http://improving-bpm-systems.blogspot.ch/2016/08/beauty-of-microservices-part-3-employ.html
- “Beauty of #microservices: part 4 from agile development to agility of enterprise systems” http://improving-bpm-systems.blogspot.ch/2016/08/beauty-of-microservices-part-4-from.html
- “Beauty of #microservices: part 5 defragmentation of enterprise data model” http://improving-bpm-systems.blogspot.ch/2016/09/beauty-of-microservices-part-5.html
- “Beauty of #microservices: part 6 managing state is a teamwork http://improving-bpm-systems.blogspot.ch/2016/09/beauty-of-microservices-part-6-managing.html
2 Breaking the monolith
This blogpost is a continuation of two previous ones:
- "Enterprise patterns: eclipse" http://improving-bpm-systems.blogspot.ch/2013/06/enterprise-patterns-eclipse.html
- "How to modernise a legacy ERP" http://improving-bpm-systems.blogspot.ch/2014/04/ideas-for-bpmshift-delenda-est-vendor_27.html
At the AS-IS step, the monolith is the master of everything related to this BE (thisBE) – data, rules, processes and events (which are generated during the lifecycle of this BE and may affect other BEs.)
The first step is to externalise and make explicit the process to manage this BE in a BPM-suite tool. Keeping of thisBE (i.e. its data) is externalised as well. Also the associated rules must be externalised (as a copy) to reproduce the business logic spread in the monolith.
The monolith keeps its slave copy of data which are maintained via some stor-API. The associated business logic and event logic are still managed by the monolith. The data (as a slave) must always stay in the monolith because they may be used somewhere.
The second step is to externalise rules (when they are good enough to cover all the existing rules from the monolith).
At the TO-BE step, everything related to thisBE is externalised, but the associated events must be “injected” into the monolith by some func-API.
3 Anti-pattern DOUM
Avoid the "DOUble Master" (DOUM) anti-pattern (section 5.6 of my book "Improving enterprise BPM systems" http://www.improving-bpm-systems.com/book ).
As coordination can be carried out by an application or by a process engine, we have to be very careful to avoid the “double master” anti-pattern. At any moment in time there must be only one master responsible for the coordination of a particular process instance. (Of course, the coordination role may be delegated if appropriate.) This is analogous to a well-organised meeting where the chairperson decides who talks next.
The non-recognition of this anti-pattern can be very costly. We have observed a BPM solution which allowed the modification of data by a process engine, by an interactive application (i.e. by a human) and by a batch at the same time. The coordination of activities was based on data and, if necessary, the application or the batch could “correct” the process. The process engine was used mainly for the handling of three human activities, and the implementation of this solution (for a relatively simple business process) took several man-years.
How will you eat an elephant? Piece-by-piece, of course.