Microservice Architecture and Enterprise Architecture in Banks - The Complex Path of Transformation

Banks today face numerous challenges, from the necessity of digital transformation to growing customer expectations for innovative services. In this context, modernizing IT architecture becomes critically important for banks' success. Two key directions that help banks achieve this goal are microservice architecture and Enterprise Architecture (EA) practice. However, this transformation is not simple and requires a complex approach from both technical and organizational perspectives.

Challenges of Microservice Architecture and the Role of EA

Transitioning to microservices can be a difficult and complex process for banks. First of all, decomposing existing monolithic systems requires deep knowledge of business domains, data models, and dependencies. Incorrect decomposition can lead to suboptimal services, making them difficult to manage and coordinate.

For example, let's consider a bank's core banking system which includes customer accounts, transactions, loans, etc. The EA team must analyze the relationships and business rules between these domains to correctly group functionality into microservices. For instance, the account management microservice might have the following classes:

While the transaction management microservice might look like this:

Here, it's important that one microservice does not take on the responsibilities of another, as this will lead to tight coupling between services.

The second challenge is ensuring data consistency across microservices. Traditionally, in monolithic applications, data consistency is achieved through transactions on a single database. However, microservices often use their own segregated databases, which complicates distributed transaction management. This requires new approaches such as event-driven architecture and eventual consistency models.

For example, if a transaction occurs between two accounts that are in different microservices, we can't use a traditional transaction to update both databases. Instead, we can create a "Transfer" event in the transaction service and send it asynchronously to the account service for processing:

With this approach, we achieve eventual consistency - eventually, both account balances will be correct, but they might be out of sync temporarily.

Another problem is related to API gateways. The proliferation of microservices often requires routing API requests through a single central point, which can become a single point of failure. Also, updating this gateway on every change can be laborious.

For example, let's imagine we have account management, transaction, and payment microservices with the following APIs:

If we want to make all these APIs available to external clients through a central API gateway, the gateway might look like this:

This gateway forwards requests to the appropriate microservices and returns the results. However, this approach has several drawbacks:

1. This is a very naive implementation. In real life, the API gateway has more responsibilities, such as authorization, request validation, response transformation, etc.
2. Every new API or API change requires updating the gateway code. This quickly becomes unmanageable as the number of microservices grows.
3. If any downstream service is unavailable, the entire API will fail. Additional layers are needed to make the API gateway more resilient.

To address such challenges, the EA team works on the following aspects:

• Developing design standards and guiding principles for the API gateway.
• Extracting cross-cutting functionality (such as authorization, and logging) into separate libraries or sidecar containers to avoid code duplication.
• Externalizing variable information (such as API routes) into configuration to minimize required changes in the gateway service.
• Introducing circuit breakers and retry policies to make the API gateway more resilient to downstream server failures.
• Developing an API versioning strategy to ensure backward compatibility and simplify evolution.

Establishing a Governance Framework for Microservices by EA

One of the main challenges in a microservice architecture is its management and governance. With many independent services and teams, there is a risk that the overall system becomes fragmented and chaotic. This is where EA's role is critical, to establish a clear governance framework and policies.

First of all, EA establishes the organizational structure and roles around microservices. This might include a chief architect responsible for the overall direction of the microservice architecture, domain architects who coordinate the development of related services, etc. Clearly defining these roles ensures a clear distribution of responsibilities.

The next step is to formulate governance processes for microservices. This includes aspects such as:

• Service naming and versioning conventions
• API contract management and change process
• Service deployment and update rules
• Security and access control standards
• Quality control and testing requirements
• Logging and monitoring mechanisms
• Incident management and escalation procedures

For example, EA might establish the following convention for service names:

<business-domain>-<service-name>-<version>        

For instance:

accounts-management-v1
transactions-processing-v2
payments-gateway-v1        

This convention ensures consistency in service names and makes them easy to identify.

For API contract management, EA might introduce the following rule: all changes to an API contract must go through the following stages:

1. Propose and discuss the change within the team
2. Get approval for the change from EA
3. Increase the version (for major changes) or plan deprecation (for minor changes)
4. Update documentation
5. Implement and test the change
6. Deploy the change

Code support for this could be the implementation of API versioning, for example:

Here we use the Microsoft.AspNetCore.Mvc.Versioning library for .NET Core to define different versions of the API and specify them in the routes.

For monitoring and logging, EA might recommend an approach like this:

This code uses the Microsoft.Extensions.Logging library to write logs. All microservices would use a similar approach and send logs to a centralized log store (like Elasticsearch), allowing us to analyze and monitor them effectively.

Regarding the non-technical aspects of microservices, EA also plays a significant role here. These include making investment decisions, assessing project risks, and developing migration strategies. The EA team works closely with business leaders to set investment priorities, evaluate expected business benefits, and address potential risks.

For example, the EA team might create a risk register for the transformation project:

EA is also responsible for coordinating changes to microservices. Since there are dependencies between services, implementing changes independently can become a source of risk. The EA team establishes a change management process that will consider the impact of these changes on other services, the required scope of testing, the transition plan, etc.

One tool that EA can use is a dependency matrix. This is a table that shows the interactions between microservices. For example:

This simple diagram shows that:

• The transaction service writes data to the account service
• The payment service reads data from the account service and writes data to the transaction service

This information helps EA analyze the impact of changes and make decisions.

Conclusion

Transitioning to microservices and integrating them with EA practices is a complex and multifaceted process for banks. It involves a wide range of technical, organizational, and management challenges. However, EA's clear role in this transformation is crucial. EA defines the architectural vision for microservices and establishes guiding principles and governance processes to ensure consistency and quality of future development.

At the same time, EA practice itself must adapt to align with the microservice paradigm. EA architects need to develop deep knowledge of microservice design patterns, event-driven architecture, and DevOps practices. They must be able to balance the needs of the business and IT in a way that prioritizes rapid change and innovation.

Ultimately, a microservice-based EA practice helps banks become more agile, adaptable, and customer-centric. It represents a difficult but necessary step on the path to digital transformation.