Accenture/ SAP Survey Results
Accenture and SAP jointly releases the results of their banking study at SIBOS today. And the survey says... replace your aging core banking systems. The survey results suffer a little from imprecision in the questions that are asked, but seems to do a very good job of identifying the business drivers behind major IT initiatives in banking today.
The Problems
Let's examine the problems which are identified:
Flexibility generally means the ability of the systems to adapt to new requirements. The particular pain varies from one institution to another but generally falls into one (or both) of two buckets.
The first is the pain of new product introduction. Many banks have grown by acquisition and the IT department looks like Noah's ark - two of everything. They are often running two or more CIFs that warehouse customer data, and two or more core processing systems. In some cases - particularly the mega-banks who have gone on acquisition binges - it is many more than just two.
Introducing a new product means writing code to incorporate that product offering into multiple systems. Most of the older core processing applications - and some of the newer ones - are COBOL-based mainframe applications. Older systems are often not well documented, do not have easily accessible APIs for getting data in and out, and only a handful of people understand the code. Writing code for mainframe-based high-volume, mission critical applications like core bank processing is a major league headache unto itself. Imagine trying to write it 4-6-8-10 times, manage the testing and deployment in a synchronous manner and by the way, with absolutely no downtime.
The second area where flexibility becomes a major consideration is with the introduction of new regulations. Banks have been subjected to a wave of new regulations in recent years. In the wake of 9-11, anti-terrorism measures such as the USA PATRIOT Act have expanded. In the wake of Enron, banks face expanded accountability under Sarbanes-Oxley. Concerns over privacy and the ability of consumers to opt-out of sharing of personal information have created new information management and reporting requirements. With the imposition of new capital guidelines under Basel II, some of which require enterprise-wide risk assessment, older technologies are hard pressed to keep pace. The pace of innovation in financial markets shows no signs of abating, and it's a safe bet that even more regulations to draw the boundaries for prudent bank operations will not be far behind.
High maintenance costs also typically stem from architectural conditions. If you're maintaining two core processing systems, your costs are going to be roughly twice as high. If you are maintaining customer data that is distributed and replicated across dozens of internal systems, particularly if those systems operate in batch processing mode and don't support real-time communications, you're going to have costs related to keeping that data in synch.
Lack of system integration is the third problem cited. I'm going to go out on a limb here and say that lack of system integration is not due to lack of effort on the part of banks. It's due to the fundamental incapacity of many older mainframe-based, monolithic, proprietary systems to play nicely in a distributed environment. This might be a function of interfaces (e.g. batch only), application design (inability to maintain transaction state or perform intermediate processing), performance, platform - or all of the above. The inability of older systems to play nicely in a loosely coupled BPM environment is a common failing.
The Solution
I'm somewhat concerned that the solution is characterized as "replacement of aging core banking systems". Although it is accurate, it does not go far enough. Simply replacing one application with another - even a more robust, open-architected, standards-compliant one - isn't going to address all the problems identified in the study. It's an important step in the right direction, but not the whole journey.
What is needed in order to provide true flexibility to support rapid testing and rollout of new products, comply with changing regulatory requirements, reduce back office systems maintenance and operations costs, and achieve enterprise-wide real-time integration is an environment built on service oriented architecture principals. Within a SOA, core processing systems can meet modern business requirements. A componentized, services-based architecture allows the development of a complex interactive application environment that is consistent with the business' strategic requirements.
As banks dive deeper into the problems identified in this study, they are going to come to a crossroads. The signpost there says "Beyond here your core processing system cannot go." Whether or not a particular bank decides to undertake replacing core processing systems is a function of where on the road the bank perceives that it needs to be - now and in the future - and where the limitations of existing systems inhibit growth and opportunity.
Paying the Piper
CDI - like core processing - is fundamentally an IT function. CDI - like core processing - has business benefits beyond operational efficiencies and costs savings. For the past five years, we've seen a shift in decision authority and budgets away from IT and out to the business lines. The reason is simple. There is a hard and fast limit to the costs that you can squeeze out of back office operations; costs aren't going below zero no matter how hard you squeeze. And over the past few years most of the easy work - and a lot of the hard work - has already been done. But there is effectively no limit to how much additional money can be made by capturing a greater share of the customer's wallet, reducing churn to near zero, and extending the life of the relationship with each customer. And the study makes this dichotomy between revenues and expenses as business drivers for reengineering clear:
Digging into the root causes behind the issues identified in the survey reveals that CDI would solve a lot of these problems. It isn't that a lot of banks' core banking applications don't need to be replaced - clearly, they do. But marking down a core banking system because it is not working well as a customer master system is a little misguided.
CDI solutions are web-services capable, and typically open-architected and standards compliant. Many CDI solutions support federation, and are capable of managing the interactivity even with batch mainframe systems. And if you can relieve the core processing system of the responsibility for acting as system-of-record to your customer data, you free it up to focus on the kind of high-volume transaction processing for which it is designed.
As CDI becomes better understood in the marketplace, we're going to see customers and market analysts increasingly making these kinds of distinctions. Survey questions will be more focused, and the real culprits behind the dissatisfaction will be exposed. Banks that understand this now are going to be in position to reap substantial rewards. CDI is typically a big project, but compared to overhauling or replacing a core processing system, it is small. And cheap. And fast. Banks which are successfully implementing CDI are solving the very problems identified in this survey, today.
Seventy percent of bank executives surveyed said flexibility was the biggest problem hindering the success of their core banking systems. Almost half of the bank executives surveyed also cited high maintenance costs and lack of system integration as areas that would impede their ability to remain competitive. To address these concerns, a significant number of banks surveyed are planning core banking system replacements within the next five years -- 30 percent in Europe, more than 35 percent in Asia Pacific and more than 20 percent in North America.This is interesting in itself in the ramifications for vendors who offer modern core processing systems. But it goes deeper than core banking system application functionality.
The Problems
Let's examine the problems which are identified:
- Flexibility
- High maintenance costs
- Lack of system integration
Flexibility generally means the ability of the systems to adapt to new requirements. The particular pain varies from one institution to another but generally falls into one (or both) of two buckets.
The first is the pain of new product introduction. Many banks have grown by acquisition and the IT department looks like Noah's ark - two of everything. They are often running two or more CIFs that warehouse customer data, and two or more core processing systems. In some cases - particularly the mega-banks who have gone on acquisition binges - it is many more than just two.
Introducing a new product means writing code to incorporate that product offering into multiple systems. Most of the older core processing applications - and some of the newer ones - are COBOL-based mainframe applications. Older systems are often not well documented, do not have easily accessible APIs for getting data in and out, and only a handful of people understand the code. Writing code for mainframe-based high-volume, mission critical applications like core bank processing is a major league headache unto itself. Imagine trying to write it 4-6-8-10 times, manage the testing and deployment in a synchronous manner and by the way, with absolutely no downtime.
The second area where flexibility becomes a major consideration is with the introduction of new regulations. Banks have been subjected to a wave of new regulations in recent years. In the wake of 9-11, anti-terrorism measures such as the USA PATRIOT Act have expanded. In the wake of Enron, banks face expanded accountability under Sarbanes-Oxley. Concerns over privacy and the ability of consumers to opt-out of sharing of personal information have created new information management and reporting requirements. With the imposition of new capital guidelines under Basel II, some of which require enterprise-wide risk assessment, older technologies are hard pressed to keep pace. The pace of innovation in financial markets shows no signs of abating, and it's a safe bet that even more regulations to draw the boundaries for prudent bank operations will not be far behind.
High maintenance costs also typically stem from architectural conditions. If you're maintaining two core processing systems, your costs are going to be roughly twice as high. If you are maintaining customer data that is distributed and replicated across dozens of internal systems, particularly if those systems operate in batch processing mode and don't support real-time communications, you're going to have costs related to keeping that data in synch.
Lack of system integration is the third problem cited. I'm going to go out on a limb here and say that lack of system integration is not due to lack of effort on the part of banks. It's due to the fundamental incapacity of many older mainframe-based, monolithic, proprietary systems to play nicely in a distributed environment. This might be a function of interfaces (e.g. batch only), application design (inability to maintain transaction state or perform intermediate processing), performance, platform - or all of the above. The inability of older systems to play nicely in a loosely coupled BPM environment is a common failing.
The Solution
I'm somewhat concerned that the solution is characterized as "replacement of aging core banking systems". Although it is accurate, it does not go far enough. Simply replacing one application with another - even a more robust, open-architected, standards-compliant one - isn't going to address all the problems identified in the study. It's an important step in the right direction, but not the whole journey.
What is needed in order to provide true flexibility to support rapid testing and rollout of new products, comply with changing regulatory requirements, reduce back office systems maintenance and operations costs, and achieve enterprise-wide real-time integration is an environment built on service oriented architecture principals. Within a SOA, core processing systems can meet modern business requirements. A componentized, services-based architecture allows the development of a complex interactive application environment that is consistent with the business' strategic requirements.
As banks dive deeper into the problems identified in this study, they are going to come to a crossroads. The signpost there says "Beyond here your core processing system cannot go." Whether or not a particular bank decides to undertake replacing core processing systems is a function of where on the road the bank perceives that it needs to be - now and in the future - and where the limitations of existing systems inhibit growth and opportunity.
Paying the Piper
CDI - like core processing - is fundamentally an IT function. CDI - like core processing - has business benefits beyond operational efficiencies and costs savings. For the past five years, we've seen a shift in decision authority and budgets away from IT and out to the business lines. The reason is simple. There is a hard and fast limit to the costs that you can squeeze out of back office operations; costs aren't going below zero no matter how hard you squeeze. And over the past few years most of the easy work - and a lot of the hard work - has already been done. But there is effectively no limit to how much additional money can be made by capturing a greater share of the customer's wallet, reducing churn to near zero, and extending the life of the relationship with each customer. And the study makes this dichotomy between revenues and expenses as business drivers for reengineering clear:
...business executives and IT executives differed in their expectations of the value a core banking system needs to bring to a bank. Thirty-nine percent of business executives want a system focused on product innovation, while IT respondents primarily want a system that reduces expenses (40 percent).Moving out into the branches where you have daily customer interaction, 50% percent of branch employees cited "frequent and unwanted delays" as the primary culprits in processing inefficiency. While this might be a little misleading since it is not traced back to root causes, it is notable that the only two specific system shortcomings identified were (1) inconsistent customer data, and (2) not understanding customer needs.
Digging into the root causes behind the issues identified in the survey reveals that CDI would solve a lot of these problems. It isn't that a lot of banks' core banking applications don't need to be replaced - clearly, they do. But marking down a core banking system because it is not working well as a customer master system is a little misguided.
CDI solutions are web-services capable, and typically open-architected and standards compliant. Many CDI solutions support federation, and are capable of managing the interactivity even with batch mainframe systems. And if you can relieve the core processing system of the responsibility for acting as system-of-record to your customer data, you free it up to focus on the kind of high-volume transaction processing for which it is designed.
As CDI becomes better understood in the marketplace, we're going to see customers and market analysts increasingly making these kinds of distinctions. Survey questions will be more focused, and the real culprits behind the dissatisfaction will be exposed. Banks that understand this now are going to be in position to reap substantial rewards. CDI is typically a big project, but compared to overhauling or replacing a core processing system, it is small. And cheap. And fast. Banks which are successfully implementing CDI are solving the very problems identified in this survey, today.
0 Comments:
Post a Comment
<< Home