This blog is the third 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

Part II –  SOA needs meaningful services – The provisioning platform

Part III – Enterprise Service Bus

Part IV –  SOA in practice – Banking Account Origination

In the previous blog of this series I have promised to come back to a more technical subject, and that’s what we will do today: Focusing on one of the most prominent and known building block of a SOA design: the Enterprise Service Bus. But before we start, let’s get one thing straight: we will not dive deep down into geek talk using numerous TLAs (three letter acronyms), web service standards and technology buzz words but rather consider the reasoning for introducing an ESB in our SOA Banking projects. 

Even in the old days when service orientation was not “en vogue”, a core banking implementation always had lots of integration aspects as part of the project scope. Anti Money Laundry(AML) systems had to be integrated as well as internal and external scoring engines, origination systems and so on. So, integration via interfaces was required, which was (if not done in the spaghetti fashion of point-to-point integration) usually approached by the concept of Enterprise Application Integration (EAI).  This concept essentially assumes that application systems will expose interfaces to their business objects and that a central middleware component will allow to connect the various interfaces to each other handling all the necessary data transformations (mappings) as well as protocol adjustments (one system exposes data as a file interface, another one can receiver data via an message queuing system).

Instead of middleware (or integration layer), today everybody talks about an ESB. This is true for “geeks” as well as “suits”: I have in fact been involved with customers, where the business users praised the benefits of “THE ESB” and how it solves all the integration challenges of their application landscape. Despite all the hype , for me the fundamental questions are 

1. How is the ESB term defined in a particular project environment
2. How does the ESB strategy differentiate from your former EAI strategy

If you have ever tried to find a definition on ESB, you will have noticed there is a common agreement that there is no industry wide accepted definition on what an ESB is. If you talk to your technology people, you will most likely get some answers on key capabilities that are to be expected from an ESB such as:

• Support for synchronous and asynchronous messaging
• Open Standards Support (usually here you get a TLA list thrown at you)
• Ability to wrap non-WS enabled (legacy) applications and expose them as managed and reusable services
• Mediation Capabilities
• All routing patterns including dynamic routing, such as content-based routing
• Data mapping and transformation
• Interoperability between consumers and providers with different bindings, such as SOAP/http as well as proprietary protocols
• Ability to add additional mediation capability for message enrichment
• Support for message-level and transport-level policy-based security

Without discussing these statements in detail, I usually like to look at the different parts of the ESB acronym to give it some more “business” meaning and also like to understand what the implementation project likes to archive with introducing an ESB:

Enterprise: “got to be something big, relevant beyond departmental interests”.

Service: “is a set of benefits delivered from the accountable service provider, mostly in close coaction with his service suppliers, generated by the functions of technical systems and/or by distinct activities of individuals, respectively, commissioned according to the needs of his service consumers by the service customer from the accountable service provider, rendered individually to the authorized service consumers on their dedicated request, and, finally, utilized by the requesting service consumers for executing and/or supporting their day-to-day business tasks or private activities.” (Wikipedia – Economics)

Bus: “Bus services can fit into several classes. Local transit buses provide public transit within a city or one or more counties, usually for trips of only a few kilometers. Intercity, interstate or inter-provincial buses provide transit between cities, towns, rural areas and places usually tens or hundreds of kilometers away. They generally provide fewer bus stops than local bus routes do”. I know this comparison is not 100% technically adequate if we look at various computer bus technologies, but I believe offers a good picture of the idea of ESB as transportation means.

To put it simple, an ESB should provide some transportation mechanism to connect service providers (also known as capabilities) with service consumers (also known as needs) in an enterprise context. A Service provider could be e.g. a Banking Services 6.0 system as mentioned in the last blog, which exposes a service for bank account balance. On the other hand, a channel application (like an Internet Banking Application) might have the need of displaying an up to date account balance to a customer. The ESB connects needs with capabilities and routes the request accordingly.

In my opinion, the most important role of an ESB component in a SOA design is to decouple service provider and service consumer from each other. In the example above this would imply that the Internet Banking channel application sends the account balance inquiry not directly to an account management system such as SAP Banking Services 6.0, but to the ESB component. The ESB itself exposes a service to the channel that provides balance inquiry. Once the request hits the ESB, the bus will then determine which service provider to contact in order to retrieve the requested information. This can be a static routing, or a dynamic one based on some specific content of the request message. The later case is called content based routing. The routing to the provider system is done based on some content of the request message such as a bank key representing a certain branch- (just as an FYI).

Essentially, the service implementation in the backend systems can be done on another system or server tomorrow without impacting the channel application. It would just require a change in the routing logic of the ESB. But of course, this can only work efficiently, if the newly implemented service is semantically identical to the previous one.

Having said this leads us directly to the question on how an ESB differs from the classical EAI approach we have used over the last years. In the EAI practice, we took each interface definition giving by various application systems for granted and made any effort needed on the middleware platform to make those applications “talk to each other”. This is commonly referred to as “Inside-Out” approach as the application systems expose their inner data structures and semantics to the outside world. Designing services via an ESB paradigm makes only sense if services are modeled according to a harmonized data model first before implementation takes place. This is called Outside-in approach, as the model that is developed outside an application context (such as the import and export parameters of that service, its communication patterns and so on) is afterwards propagated to the application systems for implementation. This approach will eventually result in no or only few data mapping requirements on the ESB as the semantically data model is harmonized across various provider and consumer applications based on a commonly shared service model. This is in fact one of the main differentiating factors between a classical EAI and an ESB approach: EAI will heavily depend on data transformations (mappings) on the middleware component; in a service oriented architecture, the ESB ideally does not perform tremendous amounts of data mappings.

To summarize the main take-aways for the ESB component in a SOA design:

• An ESB strategy should primarily allow us to support our SOA deployment. It is not a new integration platform for all integration needs (even though the physical ESB product could support all of those requirements). Of course from an IT operational perspective, you might want to consolidate your various integration platforms to reduce total cost of ownership. However, don’t make this part of the deliverables of your ESB initiative.
• Define your core goals and use case for ESB usage such as
  • decoupling service consumer from service provider
  • using routing capabilities
  • monitoring and runtime governance
• When implementing an ESB, don’t consider only technology aspects. Introduce a solid governance model for modeling services in a canonical way via an outside-in approach. The predefined enterprise services in the SAP platform as well as the underlying Global Data Types (GDT) offer a great methodology for this (see the previous blog of this series).
• Focus on strategic areas for your services provisioning via ESB. Not every new interface needs to be a service. Typical use cases are e.g. channel agnostic services you are going to provide to support your multi-channel strategy, or services you would like to harmonize across the application landscape. I have used the ESB approach e.g. to provide a generic scoring service for a global roll-out scenario. Within a given process step (during account origination) a customer scoring had to be executed. However, when we rolled out the process into various countries, each country had their own local scoring system. But this only meant to adjust the content based routing on the ESB and in this instance develop the mapping to the local scoring service. From an overall origination process, the process flow and process steps kept unchanged.