Beauty of #microservices: part 3 employ #BPM to tame the service granularity beast

1 Introduction

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 which uses other blogposts about microservices http://improving-bpm-systems.blogspot.ch/search/label/%23microservices

See also the previous blogposts of “Beauty of #microservices” topic.

• “Beauty of #microservices: part 1 #entarch #apparch” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-1-entarch.html for the definition of the following terms: process, orchestration, microservice or Autonomous Component (AC), and microservice architecture. 
• “Beauty of #microservices: part 2 architecting for change” http://improving-bpm-systems.blogspot.ch/2015/05/beauty-of-microservices-part-2.html

2 Service granularity

A recent article from Zhamak Dehghani of ThoughtWorks https://dzone.com/articles/taking-microservices-home says “Service Modeling is Difficult” and “Find your Granularity”.

Of course, the service granularity is difficult, because it is usually done bottom-up, i.e. in the solution-space without systematic understanding of the problem-space.

What could be a good enough description of a particular problem-space? Ideally, the following is necessary to analyse objectively a particular problem-space:

1. An domain-of-interest (e.g. business unit, group of processes, etc.) whose unsatisfactory behaviour is qualified as a problem.
2. An explicit and machine-executable model of this domain-of-interest.
3. Data those are sufficient to simulate the behaviour of the domain-of-interest with its model.

To build an explicit and machine-executable model of a particular domain-of-interest, this domain-of-interest must be considered as a system. Considering the following definition of the concept ‘system’ “set of interacting discrete parts organized as a whole which exhibits (as the result of interaction between the parts) some emergent characteristics indispensable to achieve one or more stated purposes”, those “discrete parts” have to be identified first. In other words, it is mandatory to find something that will allow to state: “this domain-of-interest is a system of ”.

Typical business artefacts that are used to describe a particular business are: capabilities, functions, services, processes, roles, data, etc. Is it correct to state that a domain-of-interest is a system of capabilities? System of functions? System of services? Not sure – they (capabilities, functions or services) can be explicit, but they can’t form a machine-executable model to simulate the behaviour of domain-of-interest.

So far, it is correct to state that a particular domain-of-interest is a system of business processes ( see http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-as-system-of-processes.html ).

Each business process is an assembly of the following artefacts: events, human activities, automated activities, services, processes, data, documents, rules, roles, records (audit trails), reports and KPIs. All those artefacts are designed in accordance with their domain because they are specific for a particular process or a group of processes. Thus, domain-driven design is automagically followed.

For example, data structures comprise some data necessary for a particular activity and those data are sub-sets of an enterprise data model (extra blogpost will be written on this). Roles are around a particular activity – who can execute this unit-of-work, who can supervise it, who can consult it, etc. Those roles are composed from the enterprise-wide organisational and functional roles.

All those artefacts are units-of-functionality with single responsibility.

All those artefacts have well-defined interfaces.

The majority of those artefacts are stateless.

Thus there is only one step away from the microservice architecture – just wrap those artefacts as services and deploy them separately.

Some of those artefacts in some BPM-suite tools are already microservices! In other BPM-suite tools, some of those artefacts are in the same JVM (see “programmable monolith” in http://improving-bpm-systems.blogspot.ch/2015/12/typology-of-platforms.html ).

3 Conclusion

The use of BPM (which is a top-down analysis of a domain-of-interest) resolve the following difficulties of the microservice architecture:

• granularity of microservices is defined in accordance with the domain-of-interest, thus “domain-driven design” is achieved
• relationships between microservices become explicit and they are known at the design-time
• the number of relationships between microservices is reduced thus complexity is reduced as well

Thanks,
AS