Technology Management - Core Banking Solutions

Introduction

Dramatic forces of change are sweeping the banking industry. The age of the empowered customer is here, changing the way financial products are being created, delivered, sold and serviced by banks. Relationships with clients, partners and regulators are more complex than ever. The digital world has leveled the competitive environment and the inflexibility of a traditional bank’s core systems has become the major obstacle to achieving sustainable growth in this new environment. Modernizing core systems is a major task that requires significant time and investment. Several different approaches to this challenge exist, and each has its advantages.It is believed that the best way for banks to gain the flexibility and efficiency they need is to create an architecture that separates key constructs and their assets from their core transaction engines. Once this modern core architecture is established, it will be easier and less risky for banks to acquire the necessary capabilities they need to support new business models and new functions. Banks can gain the ability to choose the optimal solution for each need; renovating elements of their existing system, building a customized solution or selecting and implementing a third party software package — in each case based on the rigors of a proper business case built on a single underlying architecture.

Imperative for Banks

To achieve their goals, banks need to get back to basics and re–think how information is acted upon by the business and how data is shared, distributed and maintained across enterprise operations. Drawing on the experience of IBM practitioners and partners, we have built up significant individual and institutional knowledge on the characteristics of successful major core banking transformation programs. Core systems modernization is often presented as a straight choice between ‘build’ and ‘buy’. 

For many banks, the chosen approach may include an element of ‘surround and modernize’, whereby selected legacy components are isolated and used as part of a larger set of processes, then incrementally replaced as required. Regardless, all successful approaches will depend upon the introduction of a centralized foundational architecture that can adapt and grow as the bank’s business changes around it. Wherever banks choose to start, they must act quickly: new technologies and rapidly evolving customer expectations are causing profound changes in the business landscape that have opened this once impenetrable industry to non–traditional entrants. To innovate ahead of competitors, banks need far greater operating dexterity and access to the operating capital currently locked in legacy systems. 

The marketplace has conditioned customers to expect instant service and value from every point of contact. They measure their bank experiences against their everyday interactions with other service providers. Not only are customers looking for more value in banking relationships as individuals; they have also developed their own dialog via social media. The increasing empowerment of the collective voice of customers continues to raise the pressure on banks to improve their relationships, stay relevant and demonstrate their added value.

The complexity of core banking systems makes it difficult for banks to adapt to external change. Simplifying and modernizing legacy core banking systems is not a matter of addressing IT cost and efficiency. Rather, the sustainability of the entire business is at stake.

Three key imperatives: 

• A new focus on the customer through improved customer information, insight and interaction. Banks that invest in these areas will cultivate customer–centrality, build trust and drive profitable growth. 

• The integration of risk management across the enterprise to meet an increasingly complex series of compliance requirements while mitigating operational risk, fighting crime and optimizing financial returns.

 • Re–thinking business, operating models and technology architecture – breaking down the existing complex models into their component parts. To gain the agility required for long– term sustainability, banks must rebuild operations using shared components that balance growth, speed–to–market, efficiency and business resiliency. This third imperative will be a major enabler for the first two, providing the necessary agility in both the infrastructure and the organization.

To drive success, smarter banks are adopting a new architecture for their core banking systems. Specifically, they are modernizing their systems by moving from a vertically integrated product–centric operating model to a horizontally integrated customer–centric operating model. For decades, core systems have been developed on a product– centric design philosophy that catered to delivering operational support for a single product, product line or financial instrument. The product–centric architecture of typical core systems worked adequately when the prevailing go–to–market model was structured around individual products. Each product–centric business line focused on building capabilities to achieve vertical integration from the front office to the back. This model was optimized for throughput and response time but it also introduced duplicated functionality and cost implications across business lines.

Fundamental building blocks: 

Today’s core banking systems need to be freed from their dependencies on front office and operational processes, so that they can do what they were originally designed to do: provide the scalability and throughput required for debit and credit entry workloads. Working with banks around the world, IBM has developed an architectural approach designed to address these issues. Starting with a modular design philosophy, the approach calls for deconstructing the complex legacy systems into their fundamental architectural building blocks, enabling them to be exploited universally. The fundamental building blocks are: 

• Discrete sets of master data for customers, products and contracts

• De–duplicated and isolated business processes, business logic and the business rules that govern their relationships. 

Principles of core banking modernisation:

Successful core banking modernization projects adhere to six principles: 

1. Based on a program roadmap and governance policy jointly developed by business and IT leadership 

2. Founded on a well–defined business case with quantifiable business outcomes 

3. Committed to achieve a modular architecture linking business processes with IT capabilities in a way that dramatically increases agility and reliability 

4.Executed using an approach that minimizes disruption while addressing change and mitigating risk 5. Architected on an optimized infrastructure that can evolve with proven technology innovations 

6. Delivered using scalable, industrial–strength ‘factory’ and project–management concepts.

Key considerations for successful banking solution

Business Requirement Management: 

Businesses are not static and their requirements evolve with the marketplace. It should be assumed from the outset that there will be change requests driven by new business or functional requirements. There should be periodic reviews and common governance to keep goals aligned and directly linked to the core financial metrics of the program. This can mitigate the impact of skills gaps and potential business disruptions, protecting against significant costs increases, delayed delivery and diminished benefits. Requirements should be captured and managed centrally, allowing banks with multi–line business units or other global bank entities to centralize their requirements and de–duplicate development efforts. A common vocabulary to discuss, capture and understand business requirements greatly improves the clarity of communication and is critical to the process. Banks that agree to standardize on a uniform taxonomy of terms, defined by the same terms that appear in their data, process and services, tend to be more successful.

Integrated Tooling Workbench: 

A standard set of tools and technology will improve control over the systems development lifecycle process. An integrated tooling workbench can help drive every aspect of the project, from business architecture design to process and data modeling, from system and service design to coding, and from integration and testing to packaging software components for deployment. A common centralized repository of all IT assets should be used to post, publish and read the output of the design and/or development work effort for each phase of the software development lifecycle. An integrated tooling workbench allows the flow of effort to be managed in a seamless manner, improving governance and oversight in order to reduce risk. Equally, an integrated workbench will allow all parties in the effort to use common project artifacts, a common vocabulary, and a single source of truth to speed development and reduce time spent in testing and integration.

Design process:

To effectively manage the risk of disruption, time to market and cost to transform, banks must combine a top–down approach with the traditional bottom–up approach to legacy modernization. The top–down approach uses banking industry process, service and data models to accelerate the definition of the future state. The bottom–up approach analyzes existing legacy systems, aiming to harvest re–usable components, logic and any other differentiating capabilities built in the past. The ‘surround and modernize’ approach allows the bank to create and mature the middleware infrastructure in which both top–down design and bottom–up legacy assets can be combined to quickly deliver the business needs. By pursuing both top–down and bottom–up approaches, banks can ensure that they leverage the best of the past while meeting the requirements of the future. Without a top–down business–driven process, service and data models providing an anchor point, a bottom–up method cannot accurately determine which legacy assets would be useful and which would be redundant in the future state. This is effectively the first step in bridging the functional and non–functional requirements, and emphasizes again the need for the business and IT functions to work closely together. 

Proof of concept: 

To validate the transformation objectives, the bank should conduct a controlled proof of concept with its chosen design principles and integrated tooling. The scope of the proof of concept should completely mirror all the elements that will be faced during the full execution. In addition to the usual proof–points around architectural constructs, design process, time to deliver business functionality, and overall viability of the effort, the proof of concept should test aspects such as the governance, change and risk management, staffing mix, skills sustainability, technology adoption and method selection. It will then be possible to refine the case for change based on lessons learned, to revisit the effort estimates, and to determine if the chosen method can be scaled up. At this stage, the bank should assess risks to the roadmap related to any likely skills gap, and assess the potential disruption and amount of change that can be successfully handled at any given point in time. The bank should determine the outcomes along the roadmap that will help with the ongoing decision–making process, and determine the appropriate pace of change to the system and the operating environment surrounding it. 

Legacy disposition:

As modernization is progressed and new systems evolve, the old legacy systems have to be decommissioned for the full benefit of the cost case to be realized. A decommissioning strategy should therefore be defined at the outset of the modernization journey. The decision to fully and/ or partially decommission legacy systems should be a business decision based on variety of factors. In some cases, the old systems may be determined to be too costly to modernize and may simply be allowed co–exist with the newer part of the modernized systems. In other cases, the old legacy systems may be completely stripped of their useful assets and the remaining portions sunsetted. The stripped assets may be re–platformed and retrofitted into newer architectural constructs. 

Testing and data migration: 

In most transformation efforts, testing consumes significant resources, effort and budget. Investing in a testing strategy and using industrial–strength testing processes and facilities can cut costs and reduce lag times in development and deployment. Proper method adoption in the development lifecycle for upstream systems will help ensure that testing efforts are better managed. Equally, data migration can become very complex, especially if legacy data sources are inconsistent or incomplete. Creating a coherent data migration strategy at the outset will help reduce risk. Using industry models for defining critical banking data elements for customers, products, and contracts can help. Equally, using pre–built models for analytics and insights can accelerate deployment and reduce costs. Industry data models can provide anchor reference points during the migration of data to new systems, enabling duplicate, redundant and non–required data fields to be discarded.

Managing change: 

To ensure that risk is adequately managed, banks need to invest time and resources in robust change management. Change will result not only from the effect of modernization programs, but also from business–as–usual initiatives that have to be accommodated within the transformation journey. Senior management should be actively engaged in ensuring that all employees understand what will change, why it will change and how embracing that change will make the bank better. Critically, the post–implementation benefits of any modernization effort will scale according to the strength of change management during the program. For the bank that understands and adapts to new ways of working, modernizing the core systems will yield the significant improvements and new capabilities that were intended. 

Build versus buy:

When deciding whether to build or buy, banks should consider the fit between business requirements and the available functionality in packaged solutions. They should also consider the effort required to customize a generic package or to streamline and redeploy existing functionality. Other decision factors may include the overall maturity of the IT organization, the availability of skills, and the long-term commitment to support and maintain newly built systems. The bank will want to understand how the new system will continue to address regulatory and business requirements in each operating territory, its ability to localize common banking practices, and its support for the institution’s regional and corporate operating models. Ideally, these decisions will be made on the basis of architectural fit, and on the potential for increased operating leverage and overall return on investment. Banks that have successfully componentized their business model and applied similar principles to their IT architecture will minimize the work required to progressively revise components of the existing systems, as well as to adapt packages as appropriate

Execution approach, addressing change and mitigating risk

Modernizing core systems is a complex task that will consume significant time and resources for any bank. In IBM’s experience, successful banks approach modernization as a journey rather than a fixed end–state, and incorporate enough flexibility and understanding of the business to be able to change to meet new requirements along the way. IBM believes that a core banking modernization program should follow a progressive path defined by a well–laid roadmap. Banks need to take a programmatic approach, where smaller projects can deliver new value frequently and where the program is adaptable to emerging requirements. They need to create the right internal organization and incentives to manage complexity. They also need to ensure that the correct resources are in place at the right times throughout all the projects that contribute to the overall program.

 Developing the appropriate approach depends on many specifics, including the objectives, scope, mandate, and timeline. For larger banks with more complex operations and broader operational and geographic scope, the challenge will be proportionately greater. Among other things, these banks will need to consider current and future regulatory controls in their markets, and will need to take into account a larger and more complex set of IT systems, carefully considering how each fits into the regional and corporate operating model. They are also likely to require more effort to model their to–be business and operating environments. 

The experience of major banks points to a clear conclusion: the most important element in the transformation program is the architecture. Specifically, banks gain the flexibility and efficiency they need by creating a componentized architecture that separates out key constructs and their assets from the core transaction engines. Without the necessary discipline to separate the architectural concerns, and without investments to mature the fundamental architectural building blocks, banks are likely to repeat the mistakes of legacy approaches, ending up with a tangle of interconnected systems in which changes in one area are likely to have unintended and unpredictable consequences in another.

Conclusion

Resourcing and skill issues should also be carefully considered – this is a common root cause for failed modernization projects. Core modernization projects are likely to depend on skill–sets that may not be readily available within the bank, and they will encompass techniques that may not have been used previously in the bank. This makes it critical to consider the project methodology and to ensure that the proposed approach is a proven one. Banks that can successfully industrialize their approach – for example, by setting up a transformation factory and/or center of competency, ensuring that it is robust, scalable and not dependent on specific personnel – are more likely to achieve a successful outcome.