Microservices Architecture through Enterprise Architecture Framework

Updated: Jan 27

Now days, Microservices is being used as a hot topic, a buzzword, a solution for every kind of pain to reduce complexity, etc. etc. This blog series of mine will be based on “How to develop Microservices Architecture through Zachman’s Enterprise Architecture Framework. The first part of this Microservices Architecture blog is based on Motivation model of the Architecture means let try to understand why Microservices Architecture need in Enterprise IT Architecture and where to place.

Why Microservices Architecture?

First let us understand why Microservices is required. In early days, while I was new to the Zachman Framework, I was trying to relate the order of Primitive or Variable Type to importance in the enterprise architecture. However now I’m very much sure that this is just coincidence, instead of ordering as per importance.

Figure 1: The Enterprise Ontology - The Zachman Framework for Enterprise Architecture
Figure 1: The Enterprise Ontology - The Zachman Framework for Enterprise Architecture

So let me start from “Why/Motivation” column of the framework to understand driving factor of Microservices Architecture. It means that the last column is not the least important as it has the driving capability to choose the right thing and in this context thing is architecture itself. I would like to make it clear that Microservices is not the silver bullet or solution for a thousand issues or complexity reducer, I agree, as it reduces complexity in one tier but increases the complexity many fold in other tiers.

All the factors should be modelled which requires change in Application Architecture from SOA (Service Oriented Architecture) to Microservices Architecture (which is subset of SOA)

Problem and associated Motivation

The following image (Figure 2) depicts what kind of motivation factor could be and how to map problem area with these factors.

Figure 2: Motivation and Microservices Management
Figure 2: Motivation and Microservices Management

Motivation Factor could be as follows to go to SOA with distributed component:

  • Overwhelming complexity; difficulty in maintaining, upgrading, and adding new features

  • Requires the entire application to get down for maintenance

  • Requires the entire application to be scaled, while only some of the services are required to be scaled up

  • Difficult to use new Technology to scale-up few services while entire application will take time while it is not even required

  • Same Technology stacks cannot fit for entire Application

In my opinion, some of Distributed Components can be developed by using Microservices Architecture.

Let me discuss some real case scenarios which encapsulate Quality of Services (QoS) or NFR which leads to Microservices Architecture.

I have tried to map stakeholder’s problem statement associated to corresponding perspectives, which will drive the factor to choose write architecture which can solve these problems. Following image (figure 3) depicts the same.

Figure 3: Stakeholder’s Problem Statement
Figure 3: Stakeholder’s Problem Statement

Motivation as Requirement

All these Problem Statements encapsulate the Motivation and the Decompose motivation as per requirement; all these requirements are actually NFR (Non-Functional Requirement) except one and so all these statements should be captured as Model and should be associated with Requirement model. I have tried to depict the same in the following diagram (Figure 4)

Figure 4: Stakeholders Problem statement and associated Requirements
Figure 4: Stakeholders Problem statement and associated Requirements

The red boundary NFR is not advocated for Microservices Architecture, thus I have marked it red; however it is required for minimising the number of application build and release per CR (Change Request).

Drive Conclusion

Decomposing business processes and identifying services with right granularity and grouping those business services by suitable Microservices related Design Patterns (i.e. LoB, DDD, SRP, etc., which I’ll cover in the Microservices series blog too). Each application should have its own database and application should be scalable independently, and must be governed by distributed governance, distributed data management. All these requirements lead to Microservices Architecture as architecture advocates independent applications, shared service end-points, shared security, distributed governance and continuous integration and deployment (CI/CD is not applicable only to Microservices architecture). So that whole application need not make scalable only ‘part’ (part in context of Enterprise System) of application (complete application in context of Microservices as it is distributed and autonomous component) can be scaled up as per demand (even demand is for shorter period). Any associated CR will impact only the part of application and since it is autonomous so it will not impact rest of the application.

4 views0 comments