Volume 4
Issue 2

Banking and IT Consolidation

Using Services Concepts

By Alpesh Doshi and Bruno Bonati

Large banking organizations are always looking to consolidate IT and improve business efficiency. Historically, banks have developed their business and their technology organically and reactively to meet immediate business needs that have led to extreme and uncoordinated complexity. In the past few years, the regulatory demands placed on banks in the form of MiFiD, Basel II, and Sarbanes-Oxley have clearly demonstrated that these complex environments are extremely difficult to manage and change. Meeting the stringent reporting and regulatory requirements has forced financial organizations to provide transparency, traceability, and auditability across their organizations. Their efforts have been focused on patching together tactical solutions to meet the minimum requirements demanded by these regulators, without consideration to the underlying issues.

To consolidate systems within these banks is a difficult, complex, and risky activity. Consolidation by acquisition is even more complex, especially for cross-border mergers.

Some of the key challenges banks face when trying to deliver to both business and regulators include:

Complexity in the form of functional overlaps (also silos with identical functions as parallel front-end systems).
Multiple systems with similar data that cannot provide a single customer view or end-to-end process integration. For example, how can a customer be uniquely identified across the organization?
Chaotic point-to-point interfaces, which are one reason why changes in the systems require significantly longer change projects and higher costs.

This makes the road to consolidation a rocky one. To further exacerbate the situation:

Most organizations do not have a consistent and documented architecture; therefore, “current state” is not well understood.
There are no consistent methodologies and standards applied across the whole bank.
There are no IT governance processes, or such processes are loosely applied with the discretion of each division.
There is no central architecture function ensuring that, first, a consistent architecture is created and maintained; and, second, the policing and application of policy is weak.
Information and data and internal/external sources have grown exponentially over the past few years as organizations collect vast amounts of data.
Data is held in tens, if not hundreds, of different systems, formats, and data models with masses of duplication. There is no consistent enterprise-wide data architecture.

The Banking Market Landscape and Where the Problems Occur

The industry can be divided into three areas: bank-to-bank relationships where banks interact continuously on transactions; relationships within a bank where the business deals with IT; and relationships between IT groups within a bank. All three are fundamental to the operations of a bank.

Investment banks are more product oriented than private or retail banks, which are more customer-relationship oriented. Both have their own challenges. From a technology viewpoint, retail banks have the problem of a complex integration for dealing with retail customers. Investment banks, however, have the problem that, in the current state, business silos cannot be connected easily (e.g., connecting equities technology with fixed income technology). Further and more obviously, the larger the bank, the bigger the issue is. For larger banks, it is also more difficult to replace existing systems with standard software packages and to integrate these into their existing systems architecture and bank process, even though they have large in-house development resources.

When two or more banks within the same regulatory regime merge, there are normally many parallel and duplicated core systems together with multiple front-end systems. To consolidate front-end systems and connect them to the core systems is extremely costly and difficult because interfacing these systems is reliant upon the ease of integration between each. Further, when a bank is adopting processes relatively quickly because of new products or new organizational or strategic requirements, often the technology change required is a significant barrier. Cross- border banking mergers are even more difficult because the regulatory regime, business model, processes, and systems are even more disparate. With this kind of consolidation currently fashionable in the European market (e.g., RBS consortium of ABN AMRO), the ability to integrate is one of the key factors driving whether a merger succeeds.

What Is the Right Way to Develop a More Flexible IT Landscape?

The characteristics of “flexible” IT should be as follows:

Business processes can be modeled with existing components.
Specific user interfaces can be decoupled from the process layer, but require a planned and migration oriented approach to delivery.
On the business logic layer, all components should have standardized interfaces. The integration of standard software and new in-house software goes faster and with less effort.
An ideal IT architecture of a bank would have a decoupled layer of applications such as user interfaces, process layer, and business logic layer and a clear decoupling between banking functions. In this big picture, the creation of components and the orchestration of business services on process platforms would make an architecture more flexible to support business changes.
Most processes are siloed today; the ability to take these processes and “automate” the cycle from requirements design and toward runtime would make the business more flexible.
In order to come near to this vision, the following elements are necessary:
The legacy has to be developed step by step into a service- or component-oriented architecture. It is important to build services on top of the existing applications in order to get managed interfaces.
To achieve this, a new type of interaction between business and IT in banks—an approach that bridges these areas using structured approaches and decision-making processes—is required. Both investments in the new architecture and in new business functions must be sponsored in a balanced manner from board level.
A metamodel, which must not be adapted or modified with each new requirement, must be developed to build sustainable services. The service landscape, business object model, and business process models are some of the elements of this metamodel.
There must be a systematic definition of the semantic or business functional part of services (a bigger challenge than to provide all the technical components as middleware or as a message broker).
New groups within an IT department are necessary to make this new IT landscape happen, including new processes such as service build, service repository, service versioning, and service governance, as well as new organizational units such as a service authorization unit. Further cultural changes, new skills, and training on how to think in a “services” manner is also central to making this successful.
A service-oriented architecture (SOA) cannot be achieved immediately. Different maturity stages have to be taken into account and properly managed. These maturity stages involve being able to deliver value across silos with reuse of technology and processes.
To support bank-to-bank processes, better standardization of services across the banking industry is required. The driver of this standardization has to be focused mainly on semantics, rather than data or technology standards.

What is the status of SOA in the banking industry?

There are a number of developments toward an SOA world in banking, which can aid the consolidation efforts across IT and through merger activity. Large vendors are developing their offerings in standard software toward a component-oriented architecture (for example, SAP Banking, Sunguard). However, some vendors do not appreciate that opening their functionality outside their system boundaries is a benefit rather than a threat. As large bank platforms become more open, a services approach can enable better integration of systems and reduced duplication.

A number of vendors to banks and end users are looking at BPMN (business process management notation) to provide banks with business process platforms using Web services in order to get fast integration with the existing systems. The challenge is to provide sustainable and generic services that do not change with each new requirement.

There are a number of cross-industry and banking-specific initiatives that will further help develop new banking industry models in order to enable faster breakup of the value chain. These initiatives are being driven by banks and their system vendors for mutual benefit.

Summary

There are few banks that are at a stage where they can become more agile and flexible systems. But they are more of a dream than a reality for business managers. To make this successful, change must be initiated by business rather than technology. This requires a change of mind-set for both business and IT and a structured and concerted approach to deliver this for the benefit of customers, employees, and the industry in general.

SOA is not a product, but an architectural- and business-driven approach to delivering a business that is more agile, flexible, and maintainable.

It could be many years before SOAs make any significant impact and deliver the nirvana of an integrated bank, which can easily and quickly create new products and services, deliver operational efficiency, and, ultimately, service customers better.

Alpesh Doshi is principal consultant and CEO of Fintricity Consulting. He has extensive experience within financial services and providing business-driven SOA solutions to clients globally.

Bruno Bonati, of Bonati Consulting, is an independent consultant focusing on SOA in banking. He was a member of the executive board and head of IT and operations for Credit Suisse between 1996 and 2004.