Considering that the TCO of a custom-developed application is only 20% for the implementation of its first production version then the rest 80% must be taken seriously. A real-life example: the cost for a small modification (changing an UI field from free-text to drop-box) in a custom-developed ERP is 20 KCHF and the implementation time is 3 months.

The agile development does guarantee that prototyping and implementation of a new application can be done rather quickly. But, the agile development does not guarantee that the production version of an application can be changed very quickly. Just compare – change a wheel of a parked car and change a wheel of the moving car.

Building blocks with the low level of changing frequency may be kept as microservices, services or even be embedded into a monolith. Building blocks with the medium or high level of changing frequency must be kept as microservices.

Thus the latter can be changed quickly and safe (without damaging the running application) because each new version of microservice assemble is a different process-template (a formal description of the process). Each process-template may be enacted as several process-instances.

The distinction between process template and process instance is very important. The lifecycle of process-template is controlled at design-time. The lifecycle of process instance is controlled at run-time. A process instance is created, maybe suspended & resumed and finally terminated. Many process instances from various templates may co-exist at the same time as shown below.

3 Conclusion

Microservice architecture, together with BPM, resolves two fundamental problems of the agile development:

building blocks (which are discovered by BPM) are to be implemented à la agile development and

some building blocks are to be implemented as microservice thus enables agility of enterprise systems (quick and safe changing of production applications).

2 Service 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:

An domain-of-interest (e.g. business unit, group of processes, etc.) whose unsatisfactory behaviour is qualified as a problem.

An explicit and machine-executable model of this domain-of-interest.

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.

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.

2016-08-06

Ability to work together is one of the essential enablers for the civilisation. At present, countries, companies and individuals can work together. Considering the current huge interest to the IoT, this blogpost outlines how to enable the things also working together with other things and people.

From the three following definitions of IoT, the last one is the better fit with this blogpost goal.

Wikipedia states that “the internet of things (IoT) is the network of physical devices, vehicles, buildings and other items—embedded with electronics, software, sensors, actuators, and network connectivity that enable these objects to collect and exchange data”

The IoT European Research Cluster (IERC) definition states that IoT is “A dynamic global network infrastructure with self-configuring capabilities based on standard and interoperable communication protocols where physical and virtual “things” have identities, physical attributes, and virtual personalities and use intelligent interfaces, and are seamlessly integrated into the information network.”.

The Alliance for IOT Innovation (AIOTI) report http://ec.europa.eu/newsroom/dae/document.cfm?action=display&doc_id=11810 says “The IoT represents a concept and a paradigm that considers pervasive presence in the environment of a variety of things/objects that through wireless and wired connections and unique addressing schemes are able to interact with each other and cooperate with other things/objects to create new applications/services and reach common goals.”

A typical pattern for working together is the following – establish a contract, carry it out and close it. Considering that the things understand very well digital information, a contract must be digital to be used by the things.

For example, a new future household fridge will have as minimum four types of contract simultaneously: 1) with people who are living a particular household, 2) with a producer and service company for this fridge, 3) with some online shops to order various food, and 4) with all other things within a particular household to achieve together some goals of energy consumptions.

In general, the things are contracted to cooperate with other things and people differently:

orchestration of several “slaves” by one “master” (also known as strong coordination)

choreography of two or more business-entities (also known as contractual coordination)

goal-achieving by a group of participants, like a football team (also known as weak coordination)

Of course, the same thing holds different roles in different digital contracts.

Fortunately, digital contracts as explicit and machine-executable processes are powered by BPM which already knows how to handle all these complexities.

But, can BPM-centric digital contracts provide necessary processing for high data volumes are being generated? Yes, with the help from microservices. Let us consider that all automation activities in a process are implemented as microservices (which are potentially externalised from a business process engine).

Firstly, each process (actually a digital contract) may be executed in a partially independent environment – only a common part would be a blockchain with all the records (or audit trails).

Secondly, each running process can anticipate what microservices will be required and can prepare secured and individual instances of microservices (with one-time passwords).

Imagine a football match. The venue starts an individual “customer” process for each person on the stadium. Knowing the customer, such a process prepares microservices which are the most probably used by this person.