Skip to Content

Introduction to Service Oriented Architecture in Banking

This blog is the first part of a series of four introducing the concepts and building blocks of a service oriented architecture in a banking environment.

Part I. –  Introduction to Service Oriented Architecture in the Banking Industry

II. SOA needs meaningful services – The provisioning platform

III. Enterprise Service Bus in Banking SOA Architecture

Part IV –  SOA in practice – Banking Account Origination



 I. Introduction to Service Oriented Architecture in the Banking Industry 

Service Oriented Architecture (SOA) has been a topic in the IT industry for quite some time now. Over the last years, many (and sometime almost religious) discussions have taken place about the concepts of SOA, its applicability to a companies IT system landscape, whether it is a revolutionary or an evolutionary approach, whether it is just over-hyped and so on.


Despite all discussions, Service Oriented Architecture is real and has itself proven to stay. In this Blog series I’d like to share some of the concepts we apply when implementing service oriented solutions in the banking industry. However, we will not deep dive into the three letter acronym world of IT technology, but rather look at the conceptual ideas and building blocks from an architectural perspective.


As mentioned before, there have been controversial discussions about SOA, so let’s look briefly on what it is. Primarily, Service-Oriented Architecture – as the name implies – is an architectural style for building IT systems. Within this paradigm, a service becomes the centerpiece of the design.

However, even though in the end we will deliver an IT solution, let’s not loose the view on what the essential purpose of IT is: To enable a company executing its business processes more efficiently, with a higher degree of automation, more agile and flexibly. Some of today’s processes would not even be possible without the support of IT systems. Just think about the amount of payment orders being processed across payment networks and between different banks on a daily basis.

So the architectural style of SOA is really about the decomposition of business functionality into dedicated business domains and providing pieces of business activities that make up business processes as “services”.  The benefit of having those services is that the encapsulated business functionality can now be reused in a variety of different processes within and even outside the company boundaries.


As you might have notices, I have not mentioned the word web service yet. That’s because the concepts of SOA do not necessarily require the usage of web service technology. However, this technology has been evolved as the de-factor standard for SOA implementation, as there a many open web service standards that enable interoperability of systems across a heterogeneous landscape.


When implementing a SOA based solution, there are typically four major building blocks that have to be considered:

  • Service Provisioning: Different business domains provide business level functionality in form of services
  • Enterprise Service Bus: Infrastructure for calling and managing services
  • Process Composition: Enables usage for various services to be composed into process flows
  • User Interfaces: Presentation layer determining how a step in a process flow is being presented to the user and how the user interacts with the system within a process step



So, how do these concepts apply to the banking industry?


A typical IT landscape in a bank is highly heterogeneous. We find core banking systems responsible for account management and periodic operational processing. There are other systems focusing on the customer facing processes (sales). In general, there are back-office, mid-office and front-office processes typically supported by more or less independent systems. On top of this, many banks have implemented various channels to allow customers to interact via different communication media (ATM, Branch, Internet, Phone Banking, Call Center). Those channels have evolved over the years on top of the existing system landscape and are often implemented as vertical application silos. The processes reside in the application silos; heavy data synchronization and replication is required. Many processes are batch driven.


One of the benefits a Service Oriented Architecture can offer in this situation is supporting the development of a true multi-channel architecture by re-using channel-agnostic services and allowing process execution transparently across various channels leading to a rather real-time environment.


In the following blogs we will look at the different building block of the architecture


Part I. –  Introduction to Service Oriented Architecture in the Banking Industry

Part II –  SOA needs meaningful services – The provisioning platform

Part III – Enterprise Service Bus

Part IV –  SOA in practice – Banking Account Origination

You must be Logged on to comment or reply to a post.