ABN AMRO’s Service Oriented Architecture 2.0

When I published the ABN AMRO’s Integration Architecture article, I quickly mentioned ‘Service Orientation’ as one of the three integration patterns of our DIAL integration architecture. Spending only 10 lines about this pattern isn’t fair, since within ABN AMRO we have an entire program running named ‘SOA 2.0’. With this blogpost I want to dive a little bit deeper into our vision at how ABN AMRO sees the future ‘Service Oriented Architecture’.

Since SOA is a widely used concept, let’s start with my understanding of Service Oriented Architecture (SOA) first:

• SOA is about exposing ‘functionality’ through web services. Some people call these Services, while others like to use the terminology API’s.
• SOA is about abstraction. Applications (and complexity) disappear towards the background and instead business functionality is provided.
• SOA is about allowing applications to communicate using a form of standard structure (REST based).
• SOA is about exchanging data, but also about processes and functions.
• SOA is about synchronous communication (wait for something to finish in order to continue) and asynchronous communication (don’t wait).
• SOA is about decoupling, allowing applications to independently change without the need to change all other applications.

About the application decoupling it is good to mention that ‘ data coupling ‘ is most often unavoidable. Services often rely on other services’ data, e.g. account information or customer information requires many other services to pull data out of systems. Since there is no workaround for not having the data, there’s always some form of coupling.

Before we look at our future state architecture and initiatives, it’s good to go rewind back to the point where our SOA journey started. Our SOA journey started just like many other enterprises, aiming to make the IT landscape more flexible, rationalize systems and provide real-time communication.

During that time no enterprise integration platforms were available, so we started to build one ourselves. It is comparable with building ‘one large system’. The large system uses a single data model, has many shared libraries, takes care of security, does processing & orchestration, does data integration and many other things.

Somewhere down the line the concept of an Enterprise Service Bus (ESB) was introduced. The ESB promoted our agility and flexibility because it enabled us to more quickly deliver services using the adapters and support for protocol conversions. On the other hand, it had to work and comply with the ‘one large system’, so all services delivered by the ESB had to comply with the (canonical) data model, processing models, security models, etc.

Meanwhile doing SOA we also noticed that the world was changing. Concepts like API Economy, Open Banking and PSD2 were introduced, applications started equipping modern (REST) interfaces on the fly and the agility became much more important. Our ‘optimize for re-use principle’ came under a lot of pressure. Consequently, we had to come up with a new approach. Based on our experiences and observations we concluded that a refreshment regarding SOA was needed.

Agility of our internal ecosystem

One of the cornerstones of our new SOA 2.0 model is that it had to improve the agility. Transformation of enterprise architecture is an ongoing process. Eliminating dependencies and removing complexity is a crucial part of this larger transition. Breaking up the monolith was unavoidable.

This also led to an important decision that we had to let go the single canonical model and to replace it with the concept of multiple canonical evolving at the same time.

Breaking up the monolith also resulted into another important decision. We had to give back the responsibility of the business logic, execution of the process, persistency of data, etc. With a decentralized model, domains can evolve at their own speed, without holding up other domains. Principles such as ‘Optimize as close as possible to the data’, ‘Exposing functionality instead of systems’ and ‘Keep domain logic in your domain’ were set.

Connecting to other ecosystems

With the modernization of applications using modern decoupling patterns (REST) we also had to look critical at our current integration platform, the Enterprise Service Bus (ESB). In cases of no heavy lifting, is the ESB always required? A lightweight API Gateway is more attractive, since it doesn’t have the overhead, while at the same time giving flexibility of decoupling, control and security. As a result, we introduced the API Gateway into our architecture as an enhancement for the future Service Oriented Architecture. The API Gateway also has another benefit. Cloud, (SAAS, PAAS) offerings and the external data consumption and distribution will push the connectivity even further. Having a point of control over all APIs makes sense. The API Gateway is expected to have an important role in our architecture. Eventually the API Gateway will become more important than our ESB since most of all communication is expected to be modern. Consequently, we positioned the ESB solely to solve the problem of legacy system modernization and heavy integration. To complete the modernization and comply with the demands of data consumption we set additional principles such as: ‘Services are built for the consumers’ and ‘Simplicity and usage of community modern standards’.

In our architecture you can see a clear split between ‘internal’ consumers and ‘external’ consumers. The language we speak internally is under our control, but externally this isn’t often the case. The ‘format’ we use for internal communication differs very much from the ‘formats’ that are being used in the outside world. This results in an additional translation when re-using internal services. Therefore, we positioned an External API Gateway in our architecture to do this external translation and to cope with the additional security measures that are needed when exposing externally.

To finalize our SOA architecture, we distinguished our ‘internal’ consumers into AAB Applications and Channels. AAB Applications typically consume direct, but for our Channels environment it is completely different ball game. Channels is where communication happens directly with our customers. It’s about human interaction, web & mobile experience and machines (Bots, Alexa, IFTTT, etc.). To offer the best experience additional components are needed, such as entitlement checks, request handling and validation, state management, caching, etc. These components are part of the Channels domain and are expected to play nicely with our API Gateway.

Service Orientation Architecture 2.0 is a refresh of our SOA strategy. It is worth sharing that the fundamentals of SOA remains the same, so we’re not changing the SOA philosophy. Mainly the techniques have changed.

By having clearer responsibilities, using modern patterns and standards we believe to have a more flexible and scalable architecture. The Service Orientation Architecture 2.0 is for ABN AMRO the reference architecture for our architects, developers, engineers and solution designers. It will enable them to deliver the highest value for the business and our customers.

SOA 2.0 is part of our DIAL architecture. DIAL stands for Digital Integration & Access Layer, which is our reference architecture for Ecosystem integration. We recently ‘open sourced’ a large part of this architecture and by sharing our SOA 2.0 reference architecture you should have a pretty good insight in how we look at Data Management & Data Integration.

About the author(s):
Piethein Strengholt, Technology Architect
Piethein is Technology Architect for ABN AMRO. He is part of a high performing team of technology enthusiasts with a passion for the latest developments and trends. Are you interested to join me on this journey? Please let us know!

Big heads up also for Maarten Spit, Peter Goosen, Michel Kroon and Wim Janse.