2016-08-26

Beauty of #microservices: part 4 from agile development to agility of enterprise systems

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.

2 Agility during the whole application lifecycle


This blogpost is named after my 10 years old presentation “From agile development to agile evolution of enterprise systems” ( see http://www.slideshare.net/samarin/from-agile-development-to-agile-evolution-of-enterprise-systems ) with a small change to introduce the word “agility”.

This done because of one of Matthew Kern’s blogpost “Fixing Agile with Architecture” (see https://www.linkedin.com/pulse/fixing-agile-architecture-part-4-matthew-kern-cea-cissp-issap-pmp- ). Obviously, architecture works with a longer timespan, e.g. the whole application lifecycle ( see also http://improving-bpm-systems.blogspot.ch/2014/03/enterprise-patterns-ear.html ) and application development covers only the delivery of the first production version. Thus architecture must guide the application development.

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.

The table below compares the level of frequency of changes for various application building blocks ( see the part 3 -- http://improving-bpm-systems.blogspot.ch/2016/08/beauty-of-microservices-part-3-employ.html ) during different phases of the application lifecycle.



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:
  1. building blocks (which are discovered by BPM) are to be implemented à la agile development and 
  2. some building blocks are to be implemented as microservice thus enables agility of enterprise systems (quick and safe changing of production applications).
Thanks,
AS
Posted by Alex at 14:27
Labels: , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)