Abstract This practitioners' report describes Credit Suisse's new - - PDF document

Design and Implementation of an agile Price Management Platform for Banking

Date: 2011-05-19 Produced by: Thipor Kong

Account & Product Management / Domain Architecture, Extended Pricing Platform

Ulrich Hildebrand

Core Banking Architecture, IT Private Banking Architecture

FINAL

Public Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 2

Abstract

This practitioners' report describes Credit Suisse's new client-centric price management platform, with the aim of replacing over 20 heterogeneous older applications with an integrated

• solution. We plan to improve business agility and to enable new ways of creating, controlling,

and governing prices across all the bank's businesses. We have decided to employ the federated architecture pattern as an enabler for a stepwise inside-out renewal. This approach leads to a highly distributed platform, with customizable components for specific business needs. As a result, the platform is designed and managed as a software product line. A software product line leverages reuse potential and helps to enforce required commonalities—but a product line also requires a dedicated design and management

• approach. We'll present our approach, which is based on model-driven engineering and

domain-driven design, and will show how a clean separation and customizability of both domain-dependent and domain-independent aspects are supported.

$Id:: XPP_SEI_SATURN_20110519.ppt 6758 2011-05-19 21:17:41Z $ $URL:: https://svn01.csintra.net/svnrep/xpp/trunk/doc/pm/XPP_SEI_SATURN_20110519.ppt $

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 3

Content The Federated Architecture of the Extended Pricing Platform Federated Architecture in the wider Context of Credit Suisse

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 4

Enable innovative price models by building an integrated IT platform for client-centric price management

Brokerage Payments Custody ... Pricing CRM Regulatory Support ... Core Banking Processes Client-centric Banking Processes But: The matrix of core banking processes and client-centric banking processes must be carefully organized!

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 5

The disconnected and highly heterogenous structure

• f legacy pricing functionality has to be overcome

Standard Tariffs

XPP Integrated Pricing Platform

Mgmt & Financial Accounting

* all numbers approximate

Special Terms & Tariffs

40 services; 200 variants 500 revenue-related types of posting records; 90 consignments 50 product groups; 130 products

Feeders Feeders Feeders 20 Product Areas call But: A monolithic, centralized architecture is not an option! Efficient Business/IT rollouts have to be enabled; product area specialities and operational independence have to facilitated.

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 6

Custody

While more complex, a Federated Architecture is required to balance client-centric, integrated price management vs. feeder variety/independence and rollout complexity

Brokerage Payments Price Calc Price Calc Price Calc Service Mgmt Tariff Mgmt Tariff Mgmt Tariff Mgmt

Relationship Manager, Service Manager, Product Manager

Straight-through processing But: The Federated Architecture implies a high degree of componentization, resulting in the risk of high SW cost and conceptual/operational fractionation.

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 7

The Software Product Line approach provides the tools to enforce required commonalities and to leverage reuse potential Core Asset Development

– Developing components and

accompanying artifacts

Product Development

– Developing customized

products by composing customized components

Organizational and

Technical Management – Keeping everything in check

But: Effective reuse can only be achieved by a careful and differentiated analysis

• f all conceptual and technical aspects of the architecture.

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 8

Example: The value of a proper and properly executed global IT reuse strategy

Source: IT Plan; classification of projects not validated w/ providers

2006-2008 Strategy: "Evolutionary"

x mCHF 6 countries + CH

• ne common

code base for all locations & CH

2008-today Strategy: "Disruptive" Reorganization / Strategy change

3*x mCHF 1+3+1 countries + CH four separate and irreconcilable code bases

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 9

The XPP reuse strategy is based on differentiated approaches to price model management and price calculation

Price Calculation

getTariff

Service & Contract Management Product & STT Management

ProductCombinations, Products, Tariffs, STTs ServiceArea, ServiceGroup, Service, ServiceAssignment (Contract)

Feeder-specific Universal

Business Objects Applications

data-driven logic-driven

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 10

The common concepts for structuring integrated price models across all product areas

Customer InformationFile Service Assignment Service Service Area Service Category Service Group Product Tariff Product Area Benchmark oriented Mandates Investment Services Discretionary Mandates ExclusiveSelection Brokerage Equities, Warrants, etc. 1.6% of Transaction Value STT Specialisation 0% (no Transaction Fees for Exlusive Selection) Special Tariff Terms of "John Doe" (if applicable) "John Doe" holds an Exclusive Selection Mandate "John Doe"

XPP BOM (simplified) SMWB TMWB

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 11

Structural Variability: Generic price model structures can be specialized for product areas/feeders

If we support variety in the data models – how to efficiently implement the business layer for managig the data?

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 12

Compositional CRUD: A balanced approach for complex data management

Use Case

• riented

Data

• riented

Compositional CRUD

Arbitrarily complex graph transformations can be represented as

composition of basic transformations

Compositional CRUD: The client composes complex operations from

primitive operations. The composition can be executed w/ one service call

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 13

Model Driven Engineering facilitates efficient implementation

• f data and service layers for price model maintenance

Conceptual Logical BOM LDM (declarative historization)

manual

LDM-H (explicit historization)

generated (model-to-model)

LDM-O (optimized)

generated (model-to-model) Resource Layer (DB) Resource Access Layer (Java)

DB Schema Definition (DDL)

generated (by JPA provider)

Historized Access Support

generated (model-to-code)

Supplemental DDL specifications

generated (model-to-text) generated (model-to-model) generated (model-to-code)

PDM JPA Persistence Unit Physical

uses

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 14

The Economics of MDE

kLoC 0.5 Services 3* Runtime Framework 0.1 PersistentObjects 1.5 TransferObjects 2.5 M2M Generators and Framework 21 6 Services 8 2 PersistentObjects kLoC 52 11 TransferObjects Generated Artifacts 149 50 LDM-H Classes 90 27 LDM FrontNet FNAPPL XPP TMWB Brokerage

* further refinements steps pending

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 15

Step-wise refinement and variablity of pricing logic

XPP Core Domain Logic + Specific Rules Formalism + Brokerage Specific Logic + Brokerage Pricable Brokerage PRICE getPrice() Service Production Infrastructure (Persistence Unit, Oracle, JMS/MQ) Unit Test Test Infrastructure (Persistence Unit, JavaDB, Test Orders in XML)

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 16

Behavioural Variability: Logic of Price calculation can be specialized as well by applying "Stacked Domain Driven Design"

Generic Domain Model Payments Domain Model Custody Domain Model Brokerage Domain Model Custody Infrastructure Binding Payments Infrastructure Binding Brokerage Infrastructure Binding Domain Infrastructure

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 17

SMWB

Distribution of Cost in XPP Architectural Release 1

TMWB PRICE Feeder Integration Price Model Migration 80% 70% 60% 20% 10% 20% 40% 80% 90% 30% Specific for first Feeder Reusable Base Component 45% (33% of platform) 55% (66% of platform) XPP Platform Components Integration & Migration

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 18

Indicative Reuse Base plus Project Cost & Savings

The more feeders integrated...

the higher the base of reusability the lower the cost of every subsequent feeder ( higher cumulated savings) the higher the relative impact of integration and migration cost ('renewal')

Feeder Total

Feeder 1 Feeder 2 Feeders 3-5 Feeder 6 Feeder 7 Total Reuse Base Total Savings Savings due to base Project Specific cost Project reuse potential

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 19

Federated Architecture and Software Product Line: The right strategies to achieve client-centric pricing Integrated, client-centric pricing only feasible with

– efficient rollout/migration paths – proper balancing of harmonization of pricing concepts vs. business variability – proper balancing of pricing integration vs. operational independence

A federated architecture enables balanced designs The software product line approach is highly suitable

to implement a federated architecture

Differently characterized parts of the architecture

require different reuse/variability concepts

Every senior developer trained to be able to technically setup

a new feeder implementation within one day

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 20

Content The Extended Pricing Platform and it's Federated Architecture Federated Architecture in the wider Context of Credit Suisse

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 21

Creating the Federated Architecture (FA) Vision

analyzing the requirements and answering questions

• Why is it so difficult to implement a comprehensive system streamlining requirements from many

business areas? Why could COTS (replacement approach) not be integrated?

• Are there other ways to solve such problems than a central, monolithic approach which dramatically

reduces agility? (even the agility to find a solution)

• How to reduce the conceptual and technical complexity?

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 22

Federated Architecture Pattern explained

comprehensive models which can be enhanced to local needs

• The Federated Architecture Pattern* describes an approach to enterprise architecture that allows interoperability,

control of and information sharing between semi-autonomous de-centrally organized lines of business and information systems.

• The pattern emphasizes on organizations and systems which require a controlled sharing of information and behavior

among autonomous components and is especially useful for very large organizations and information systems.

• The Federated Architecture Foundation (FAF) defines what has to be shared and centrally controlled. It defines

common concepts and reusable components, standards and principles, a comprehensive BOM which can be enhanced by distributed components of different business areas to their local needs. This allows for central control of defined aspects of behavior and syndication of information.

• Goals
• Reduce complexity: Complexity is usually the result of too many local particularities which are tried to be managed in a

central, one fits all approach. This is the reason why highest possible autonomy shall be given to the different cooperating components.

• Higher agility: The result is a higher degree of flexibility and a larger solution space— which at the end means, taking

local particularities seriously and solve local problems locally whenever possible.

• Implementation: To be able to manage different lifecycles, migration plans and continuous enhancements and changes of

functionality of the participating components, Federated Architecture should be developed as a product line, with a common technical architecture empowered by MDE.

http://en.wikipedia.org/wiki/Federated_Architecture *for a more detailed description of the pattern, see

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 23

Federated Architecture Pattern

a strategy pattern enabling the evolutionary-coexistent migration process*

The pattern solves the functional and non-functional requirements as well as IT architecture

• standards. This is the reason, the FA pattern is regarded as a key architecture strategy

pattern.

*For more details about the approach see Managed Evolution by Stephan Murer, et al.

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 24

Federated Architecture applied

Today

• pportunistic, incoherent com-

ponents, background mapping needed, inflexible towards changes and innovation ... FA applied ... MF MF

Position Position

MF

Product

MF

Product

MF

decentral

• SafeKeep. Debit, Credit, MM,...

Product

JAP

JAP

Service & Contract

JAP

Position

JAP JAP

Order

JAP JAP

Product Product

Accounts = MF

Position renew

MF

Order renew

JAP

Order Position Product

federation

Service & Contract are

delivering the syndicated comprehensive view.

Especially for the federated

core banking objects: master data like product but also transactional objects like orders & positions (accounts) the FA pattern looks promising.

NEW

MF

Payment Orders, etc.

MF

Stock Order

• SafeKeep. Debit, Credit, MM,...

syndication

Credit-Suisse is in the midst of an evolutionary-coexistent, stepwise & risk minimized migration process

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 25

Federated Enterprise Architecture applied

Product definition, order execution and booking are product area specific & vertical (federated) but service & contract management as well as position keeping expand many business and product areas (asset classes) are client centric & horizontal (syndicated) processes and views.

• current project scope
• ther candidates
• proposed candidate

With the help of the FA pattern, IT enables efficiently the harmonization of requirements from different business areas. IT efficiency is the value proposition of IT architecture for the business.

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 26

Appendix

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 27

The stepwise refinement of CRUD to Compositional CRUD w/ Historization/Versioning and Change Management

Isolated Objects Specific Application Policies

simple objects w/ primitive properties

Object References

unidirectional references as special properties

Objects w/ Components

special containment-references

Managed Objects

designated "changeset" objects,

that control modifiability of owned objects Versioned Objects

designated

versioned/version

• bjects

Produced by: Thipor Kong, Ulrich Hildebrand Date: 2011-05-19 Slide 28

Available MDE tools commonly work on model snapshots. But DB change management requires knowledge about deltas!