This blog is the second part of a series of four introducing the concepts and building blocks of a service oriented architecture in a banking environment.
Introduction to Service Oriented Architecture in Banking
Part II – SOA needs meaningful services – The provisioning platform
Part III – Enterprise Service Bus
Part IV – SOA in practice – Banking Account Origination
As we have discussion in the introductory blog, there are different aspects to a SOA strategy, which need to be addressed when introducing SOA design concepts into an organization. One of the core aspect in any implementation is the question on service provisioning capabilities such as
- which services do I have available in my portfolio
- what is the granularity and the boundary of a service
- to which business domain does a service belong
- in which areas can I reuse a given service
Quite often it can be observed that SOA strategy is driven by the IT departments, as IT most likely is observing trends and development in the information technology space. However, this can lead to an imbalance towards the technological aspects of SOA. As much as a sound technology infrastructure is required to realize your SOA strategy, it is as important to have a provisioning platform that provides industry specific services. So, let’s have a look into how services are provisioned on the SAP platform.
Banking Services from SAP 6.0 is the most current release of SAP’s Business Process Platform for Banking. Based on the NetWeaver 7.1 technology foundation it offers banking process content for deposit management, loan management, collaterals management, bundled pricing, etc to name just a few.
From a software perspective, how are those functions provided in the context of Service Oriented Architecture? The Banking Services Platform is divided into different Process Components. These process components group functionalities together belonging to the same business (sub) domain, like e.g. Bank Account Contract Processing.
Each Process Component contains at least one (or many) business objects that expose business functionality. These functionalities are grouped into service interfaces based on interface patterns. Within a given service interface, one or more service operations are defined, which represent encapsulated, self-contained and executable functionality of a business object.
The picture above shows an extract on this taxonomy to visualize the overall concept.
Within the Process Component “Bank Account Contract Processing” e.g. the Business Object “Current Account Contract” is available. This Business Object provides a Service Interface “Manage Current Account Contract In” that groups all the read/write operations on a given business object such as “Create Current Account Contract” or “Read Current Account Contract Basic Data”.
The service cut as well as definition of names and pattern follows a consistent methodology at SAP called the PIC (Process Integration Content) process to ensure business functionality is provided in a meaningful and non-redundant form on the platform. Also, it ensures consistencies of names and semantics. For more information on semantic harmonization, search for Global Data Types (GDT) on SAP Developer Network.
Futhermore, SAP Banking Services has been modeled to reflect Process Component interactions. These models describe how different process components interact with each other by means of using service operations.
For example the figure above shows how Collateral Agreement Processing will access loan contract and account balance figures, which are the concern of a different process component and therefore are not modeled within the collaterals domain.
From these models, which are by the way delivered in the SAP Enterprise Services Repository (ESR), a direct navigation to the service definition is possible (see below).
Let’s wrap up.
Banking Services from SAP was clearly developed based on a Service Oriented Architecture design paradigm. It is structured into various domains and implements the architectural principle of separation of concern. Domain functionality is exposed as services. These can subsequently be used e.g. to create composite applications as part of your multi channel strategy working with real-time data of your core banking application and providing channel agnostic business functionalities to your users and customers.
In the next blog we will get back into a more technical aspect and look into one of the major building blocks of a SOA design – the Enterprise Service Bus.
