14
SAP Thought Leadership Paper In-Memory Computing In-Memory Computing for Analytical Banking Bringing Operational, Analytical, and Business Processes Together

In-Memory Computing for Analytical Banking Bringing Operational, Analytical, and Business Processes Together

Embed Size (px)

Citation preview

SAP Thought Leadership PaperIn-Memory Computing

In-Memory Computing for Analytical BankingBringing Operational, Analytical, and Business Processes Together

Table of Contents

5 New Challenges in Analytical BankingIn-Memory Computing Advances Reporting and Decision Making

6 Bringing Analytical, Operational, and Sales Data TogetherUse In-Memory Computing in an Existing Analytical System

Consolidate Analytical Data for In-Memory Computing

Use In-Memory Computing for All Data

11 Changing the GameFinding the Right Path to In-Memory Computing

About the AuthorsKlaus Pohl, Gert Schick, Volker von Seggern, and Drazen Tomic work in the Business Transformation Services group of the SAP® Consulting organization. They provide support for the financial services segment in Europe, the Mid dle East, and Africa. This includes value-based services and methodology that help financial services firms translate business strategy into optimal IT architectures and solutions. The group also helps customers optimize busi ness processes by leveraging enterprise architectures, process models, and benchmarks that are specific to the financial services segment.

Today’s market environment for banks is both volatile and heavily regulated. The agility to manage in these extremes and react quickly to changing conditions is all about having access to the right data at the right time. In-memory computing opens up new possibilities for rapidly aggregating and processing mountains of data from disparate sources. Banks can make well-informed decisions more quickly, preventing losses and capturing more profits, and handle regulatory reporting more effectively.

5SAP Thought Leadership Paper – In-Memory Computing for Analytical Banking

IN-MeMOry COMPuTING ADvANCeS rePOrTING AND DeCISION MAkING

With in-memory computing, banks can address current and future challenges and opportunities in analytical banking. This innovative technology makes it pos-sible to analyze massive quantities of data in local memory. As a result, banks can complete complex analyses and transactions in real time for faster, more effective business decisions.

Up to 3,600 times faster than standard analytical computing, in-memory com-puting also fosters deeper, more granular insight into banks’ data, streamlines the management of large volumes of data, and reduces IT complexity. Banks can base their regulatory reporting and business decisions on reliable information from a single platform while reducing the cost of operating their analytical systems.

PrOvIDING INfOrMATION ThAT IS TIMeLy, reLIABLe, AND rOBuST

New Challenges in Analytical Banking

Banks face tremendous challenges in analytical reporting today. This is due largely to the increasing number and complexity of regulations such as Basel III, the U.S. Dodd Frank Act, and the International Financial Reporting Stan-dards that followed recent market disruptions. This, combined with fast-changing market conditions, requires timely and reliable information, along with predictive analysis, that will help banks prepare for future business changes.

In the past, IT architectures for analyti-cal banking have involved separate systems for business planning, accounting, risk and regulatory evaluation, financial anal-ysis, and reporting (see Figure 1).

As a result, banks found it difficult to fulfill their regulatory requirements and based their measures of risk management on incorrect assumptions or data or both.

They also wasted time understanding and reconciling data, which delayed their business decisions. These architectures must now evolve so that banks can: • Make real-time or near-real-time deci-

sions – Until recently, analyses have mainly been processed overnight.

• Make accurate profit, loss, and risk predictions – Lack of an integrated da-tabase has often created information based on inaccurate assumptions.

• Fulfill their regulatory requirements – The typical practice of having informa-tion in different systems has required considerable time, effort, and expense for reconciliation.

This paper will explain how in-memory computing helps banks accomplish these goals.

figure 1: Overview of Analytical Banking functions

Business functions

Strategic planning

Legal and managementconsolidation

General ledger accounting

Profit and cost calculation

Risk and performance simulation

Credit risk evaluation Financialanalysis

Subledger accounting

core business

Perfor-mance

planning

Risk planning

Subledger accounting

business support

Operational planning

Risk capital allocation

Budgeting Risk limit setting

Statutory reporting

Tax reporting

Regula-tory

reporting

Manage-ment

reporting

Opera-tional

reporting

Perfor-mance

analysis

Forecast-ing and

simulation

Generation of

measures

Market risk evaluation

Banking book riskevaluation

Operational riskevaluation

Risk limit utilization

Regulatory evaluation

Planning Accounting risk and regulatory evaluation reportingAnalysis

A Three-STeP APPrOACh TO reLIABLe, reAL-TIMe INfOrMATION

Bringing Analytical, Operational, and Sales Data Together

As noted above, most banks have sepa-rate systems for analytical functions and the customer-centric and transactional banking functions that support their sales and operations activities. Managing functions for analytical banking systems in their own centralized system, as opposed to the decentralized systems used for customer-centric and transac-tional banking functions (see Figure 2), can enhance efficiency and effective-ness. However, analytical functions for

accounting, risk and regulatory evaluation, and reporting are often duplicated in systems for customer-centric and trans-actional banking. Examples include operational accounting functions for customer statements or risk calculation functions for deal closure.

Feeding information from customer-centric and transactional banking systems into analytical banking systems requires a cumbersome and costly infrastructure for data replication. This infrastructure

can involve several data marts – or even several data warehouses – and adjacent extract, transform, and load (ETL) sys-tems. Normalizing the data into a single format for calculations and other analy-sis can be time-consuming and costly. To sustain performance for the analytical banking system, the sourced informa-tion is often stripped down or aggregated. Even state-of-the-art technology with service-oriented architecture can require data replication.

figure 2: Typical Architecture for Analytical, Customer-Centric, and Transactional Banking

Analytical Banking

Customer-Centric and Transactional Banking

Business partner/opportunity/position/transaction data

Sales Transactionprocessing

Risk andregulatoryevaluation

(by position manager)

Reporting(operational)Servicing

Accounting(by

operations)

Planning Analysis

Results and reporting data martsPlanningdata mart

Data for finance

Accounting(by finance)

Data for risk and regulatoryevaluation

Risk and regulatoryevaluation

(by finance and risk)

reporting(management and stakeholders)

Data flow

7SAP Thought Leadership Paper – In-Memory Computing for Analytical Banking

To fulfill new requirements for liquidity risk management in analytical banking, for example, current architectures must extract, transform, and load data from customer-centric and transactional banking systems into a central database. Only then can they execute the required evaluations and calculations of liquidity risk.

The following table summarizes the advantages and disadvantages of a sepa-rated architecture for analytical banking.

With in-memory computing, banks can complete complex analyses and transactions in real time for faster, more effective business decisions.

Advantages Disadvantages

It is easier to manage new requirements for analytical banking. An expensive and complex infrastructure for data replication is required.

The impact of change when new requirements for analytical banking are introduced is minimized for customer-centric and transactional banking.

Processing in the analytical banking system is based mainly on overnight batch processing, with results delivered the next day.

It is easier to meet performance requirements for customer-centric, transactional, and analytical banking.

Data changed in customer-centric and transactional banking systems must be replicated in analytical banking applica-tions – requiring increased lead times for IT production.

Significant reconciliation effort is required.

As not all customer-centric and transactional banking data is available in the analytical banking system, the data must be aggregated. Detailed information about this data may be lost and thus unavailable for analysis.

Analysis and reporting functions may be restricted to a few users but unrestricted regarding content or restricted for many users to predefined content.

The disadvantages noted can be over-come – without losing the advantages of a separate analytical system – by introduc-ing in-memory computing and real-time processing into analytical banking sys-tems in the following steps:1. Achieve quick wins with the use of

in-memory computing technology in an existing analytical banking system

2. Consolidate analytical banking data for in-memory computing

3. Use in-memory computing for all data

uSe IN-MeMOry COMPuTING IN AN exISTING ANALyTICAL SySTeM

Banks can achieve quick wins from in-memory computing by leveraging its capabilities in their existing analytical banking systems (see Figure 3). Storing data for financial analysis and risk and regulatory analysis on an in-memory database eliminates the need for aggre-gating data and can increase the gran-ularity of subledger accounting down to the transaction level.

Some replication of customer-centric and transactional banking data is still required. However, banks get accounting results through direct access to post-ings at the transaction level immediately after daily and periodic processing, with-out sourcing this information to report-ing data marts. This provides a deeper understanding of how changes in data for customer-centric and transactional banking affect analytical banking results.

In risk and regulatory evaluation, in-memory computing provides greater freedom in aggregating single positions for different risk and regulatory views within the same time frame and enables real-time simulations and stress testing.

For analysis and reporting, both the gran-ularity and scope of available information will increase. Banks can lift existing user restrictions on accessing detailed information and making ad hoc queries across all available data in the areas where in-memory computing is imple-mented. The business planning data mart is fed from the results and report-ing data mart, allowing a single source of truth here as well as for analysis and reporting.

CONSOLIDATe ANALyTICAL DATA fOr IN-MeMOry COMPuTING

The second step is to store all analytical data in one in-memory database (see Figure 4). For accounting, this lets banks manage financial positions and generate postings in near real time when they change data in their customer-centric and transactional banking systems and replicate the data in their analytical banking system. Banks can use the

figure 3: Analytical Banking Architecture for Step 1

Analytical Banking

Planning Analysis

Results and reporting data marts (in-memory)Planningdata mart

Data for finance(in-memory)

Accounting(by finance)

Data for risk and regulatory evaluation

(in-memory)

Risk and regulatoryevaluation

(by finance and risk)

reporting(management and stakeholders)

Customer-Centric and Transactional Banking

Business partner/opportunity/position/transaction data

Sales Transactionprocessing

Risk andregulatoryevaluation

(by position manager)

Reporting(operational)Servicing

Accounting(by

operations)

Data flow

9SAP Thought Leadership Paper – In-Memory Computing for Analytical Banking

additional capacity in overnight batch processing to increase valuation frequency from monthly to daily, for example, and allow daily accruals of performance calculations.

This free capacity in overnight process-ing can also be leveraged to handle addi-tional processing for risk and regulatory evaluation or provide results for steering purposes much earlier. It becomes easier to handle upcoming evaluations required by regulatory authorities and support

evaluation methods that are more com-plex. This means, for example, that banks can add aggregations based on different attributes for liquidity risk and credit risk evaluations. They can also make addi-tional intraday evaluations to manage risk more effectively and monitor regulatory compliance in near real time.

Making complex evaluations ad hoc or in parallel with each other and inte-grating additional market scenarios and business simulations lets banks extend

analysis from slicing and dicing actual results to forecasting and simulating future results. All customer-centric and transactional banking data is available for reporting and can be accessed by many users without restricting the gran-ularity or complexity of their queries.

Taking this step offers the following additional advantages:

• The greatest degree of granularity in customer-centric and transactional banking data will be the basis for analytical banking processes.

• Reconciliation is easier between customer-centric and transactional banking systems and analytical banking systems as well as among different analytical systems.

• Intraday evaluations for risk controlling and regulatory supervision will be available for analytical purposes.

• The content of daily evaluations will grow and deliver more financial and risk results on a daily basis.

• Greater simulation is available in analytical banking, thereby increasing the convergence between evaluation and analysis functions.

These capabilities give banks a much clearer picture of their risk positions, in real time, for faster, more-effective business decisions.

figure 4: Analytical Banking Architecture for Step 2

Up to 3,600 times faster than standard database technology, in-memory computing fundamentally changes the way banks can use data to create insight and increase performance. Complex queries yield instant insight, helping you stay ahead of the competition.

Analytical Banking

Business partner/opportunity/position/transaction data

Planning Accounting(by finance)

Reporting(management and

stakeholders)

Risk and regulatoryevaluation

(by finance and risk)Analysis

Simulated businessPlanned business Market scenarios

Customer-Centric and Transactional Banking

Business partner/opportunity/position/transaction data

Sales Transactionprocessing

Risk andregulatoryevaluation

(by position manager)

Reporting(operational)Servicing

Accounting(by

operations)

Data flow

uSe IN-MeMOry COMPuTING fOr ALL DATA

In the third step, customer-centric and transactional banking become fully integrat-ed (see Figure 5). They share the same database, so no replication is required. It is possible to process customer-centric and transactional banking data in analyti-cal banking applica tions in real time and react immediately to changing business and regulatory conditions.

The integrated database lets banks consolidate duplicate functions for accounting and risk and regulatory

eval uation. A bank can use operational accounting information for customer statements, for example, or it can use information for financial reporting and credit risk evaluation for credit deci sions and credit risk reporting.

The integrated database lets banks run accounting, risk and regulatory evaluation, analysis, and reporting functions in real time using data directly from databases for customer-centric and transactional banking. This facilitates closer integration of management pro-cesses with business processes, such as the integration of daily credit risk man-agement and loan decisions.

Integrated data and process manage-ment offers the following advantages:

• Real-time access to customer-centric and transactional banking data for analytical banking processes

• Full integration of management process functions, like evaluations for risk controlling and regulatory supervision into business processes like operational accounting, financial reporting, and credit decisions

• Full integration of operational and management reporting into a bank’s business processes

figure 5: Consolidate All Data in a Single In-Memory Computing Database for Step 3

Analytical Banking

Business partner/opportunity/position/transaction data

Customer-Centric and Transactional Banking

Sales Transaction processing Servicing

Planning Accounting ReportingRisk and regulatoryevaluation Analysis

Simulated businessPlanned business Market scenarios

11SAP Thought Leadership Paper – In-Memory Computing for Analytical Banking

SAP hANA® DrIveS BANkING TrANSfOrMATION

Changing the Game

By significantly streamlining data analysis, the in-memory computing technology offered by SAP HANA® appliance software can be a major driver for business and IT transformation in banking. SAP HANA combines an in-memory computing engine with commodity hardware systems that are specifically designed to process real-time data using in-memory technology. You can thus process massive quantities of real-time data in the main memory of a server and get immediate results from transactions and analyses for rapid, well-informed business decisions.

We can also help you get the greatest benefit from in-memory computing by identifying the business processes it can

transform and implementing the software that will help you realize that transfor-mation. Together we can:

• Use in-memory computing to align your business and IT strategies

• Discover the areas in your business in which SAP HANA can deliver addi tional benefits and value

• Develop a business case for using SAP HANA

• Develop a target architecture for your business processes and the supporting applications, including SAP HANA

• Derive the best transformation path to integrate SAP HANA into your business

fINDING The rIGhT PATh TO IN-MeMOry COMPuTING

We help you define a road map for each in-memory use case that aligns with your overall business strategy, create a prioritized list of business objectives for in-memory support, and determine how to meet those objectives.

The four steps of this assessment (see Figure 6) answer the following questions:

Step 1: Where can in-memory computing deliver additional benefits and create value?In the first phase, we help you analyze your current business strategy, processes, and software portfolio and align your business and IT strategies. We also explore business requirements and processes where in-memory computing could best be used.

Step 2: What would a target IT architecture using in-memory computing look like?We then develop an in-memory-based target application portfolio and the target architecture for both in-memory com-puting solutions and supplemental solu-tions. We create high-level prerequisites for the technical infrastructure and its blueprint and help you identify the poten-tial risks, strengths, and weak nesses of the new landscape.

figure 6: The Steps of SAP hANA usage Assessment

Midterm vision

Step 2

Develop-ment of solution portfolio

and architecture built on the SAP® HANA

platform

Development strategy

Release strategy

Project experience

Step 3

Develop-ment of

SAP HANA implemen-

tation approach and road

map

Step 1

Analysis of the

busi ness strategy

Evaluation criteria

Process analysis

focused on SAP HANA use cases Process

landscape

System analysisSystem

portfolio

References

Step 4

Cost benefit and risk analysis

JustificationDesign and PlanningAnalysis

Business strategy

Business requirements

IT requirements

Ongoing IT initiatives

Current IT landscape

Step 3: Which is the best transfor-mation path to integrate in-memory computing?In a third phase of the assessment, we define implementation and migration scenarios for the new landscape. We also establish a project framework and master plan that include organization structure and required governance.

Step 4: What are the benefits and risks of implementing SAP hANA, and when will the investment pay off?The last assessment phase weighs your one-time investment and recurring costs against potential tangible and intangible benefits using a return-on-investment calculation and high-level risk analysis.

The in-memory computing technology offered by SAP HANA appliance software can be a major driver for business and IT transformation in banking.

LeArn More

To learn more about the many ways that SAP HANA and in-memory computing can help your institution, contact your SAP representative or visit us online at www.experiencesaphana.com/welcome.

And to learn about the Business Transfor-mation Services group of SAP Consulting, visit www12.sap.com/services-and-support /transformation/business.epx.

www.sap.com/contactsap

50 113 686 (12/06) ©2012 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL Anywhere, and other Sybase products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Sybase Inc. Sybase is an SAP company.

Crossgate, m@gic EDDY, B2B 360°, and B2B 360° Services are registered trademarks of Crossgate AG in Germany and other countries. Crossgate is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies (“SAP Group”) for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.