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.

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.

How to control your privacy architecture?

In the previous chapters we have discussed the details on how to document and measure privacy in a mid/large company. However, on key aspect is always governance.

A short definition of governance is: making decisions and then assuring they follow compliance mechanisms via strong organizational and operational metrics. The functional parts of a governance structure are:

1. Organizational model: The purpose and the structure of the body that manages and partitions responsibilities for each company priority area across the different organizational entities -- corporate, functional groups, and geographies

2. Decision making: Definition of the decision making and funding processes for on-going planning and management of privacy activities

3. Process and people: Infrastructure and capabilities for pre and post-deployment support

Typically, in the field of GDPR you have the following roles/people:

1. DPO (Data protection officer): is the point of contact for the body of authority and normally issues recommendations and best practice for the rest of the organisation.

2. Controller: is the responsible for processing privacy data and in this model, we have allocated the process owner. The reason is two folded 1) privacy is a business issue not and IT issue 2) each process owner has the means and purpose of the actual data processing.

3. Processor: is responsible for processing data given by the controller. In our model we do not have that role. The reason is that it normally is the same as the controller from a governance point of view, however limited to what the controller has given permission to execute.