Microservices Fad or Trend?

When talking to clients and the architecture community the term microservices is gaining traction and attention. So, what are microservices?

“[…] self-contained piece of business functionality with clear interfaces, and may, through its own internal components, implement a layered architecture” (https://en.wikipedia.org/wiki/Microservices)

The definition above is theoretical and leaves the field open for interpretation on how develop an architecture based on microservices. However, this kind of approach is not new if you have been working with IAF (Integrated Architecture Framework).

Many architecture frameworks take a top down approach when creating the architecture. They start with a high level approach and decompose down to the level required to document what the architecture consists of, much like in the figure below.

Hierarchy.JPG

The main drawbacks of this approach are:

  1. It’s not that easy to define and analyse solution alternatives, as thinking is guided and influenced by the hierarchical structure that is being created and the political arena in the company.

  2. The structure makes it harder to think out of the box, since each process leads to stow pipes and no room for shared services.

  3. The architect is implicitly combining the ‘what’ and the ‘how’ question, because the definition of the structure along with the definition of the requirements. Making it difficult to isolate the service without running into a redundancy issue with multiple services that do the same thing but are separated by the process. For example Purchasing has the service “review claim” and Sales process also has a “review claim” service. Here there is a risk of creating redundant services in a large and complex organisation.

IAF takes a different approach.

  • Firstly, we define the services at the level of detail required without explicitly putting them into a hierarchical structure.

  • Then we define grouping criteria that are based on the architecture principles.

  • After that we create components by grouping the services into components based on the grouping criteria. The figure below visualizes the IAF approach.

OK – Claudio this sound theoretical can you give me a practical example? Sure: read Casimirs blog http://disruptivearchitecture.info/blog/2019/12/16/ea-case-study-top-down-or-bottom-up that describes a hands-on example of the topic discussed above.