SOA At Work

Fiat SavaFiat Sava

Fidis Retail Italia at a glance

•Fidis Retail Italia (“FRI”) is the result of the spin-off in May 2003 of the European retail car financing activity from Fiat Auto and the subsequent sale of 51% to the four major Italian banks (Banca Intesa, Capitalia, San Paolo-IMI, UniCredit)

100%

•FRI is a non-bank financial institution regulated by the Central Bank of Italy. It operates under various degrees of regulatory supervision in 13 Europeandegrees of regulatory supervision in 13 European countries.

•The company focuses on retail and lease finance•The company focuses on retail and lease finance for cars and has a very diverse customer base of over 1.5m clients with an average exposure of approximately €5,700 and average residual life of some 18 months.

2

SAVA at a glance

•Sava was established in Turin on 1925 as Fiat Auto’s captive finance company•More than 2 millions of circulating vehicles in Italy were financed by SAVA:g y y

• 427 employees• 9 branch offices• more than 700 point of sales through the Fiat Auto dealer networkmore than 700 point of sales through the Fiat Auto dealer network• 250.000 + new contracts per year

•Core products:•Core products:• Hire Purchase• PCP

P l L• Personal Loans• Leasing

3

So What for SAVA

• Italian Consumer Credit Market is changing:

•Indirect products (i.e. loan contracts at the point of sale) are decreasing their market share and/or growth rate (automotive +2,7%, -10% credit loans on 2005)10% credit loans on 2005)•Direct Loans are increasing their market share (personal loans by 15%, revolving cards by 20%, Loans on one’s wage by 29%)

• Finance Companies are defining strategies and policies that are strongly based on an effective customer relation, while shifting competing pressure ffrom dealers to customers and to the competitor’s customer base

4

The Action Plan by DepartmentsTime to Market Multi Channel Multi Device Lower CostsTime to Market

CR

MRetention and loyalty programs

Multi Channel Multi Device Lower CostsEnabling new B2B partners, Adding B2C channels with

Switching contacts to lower cost devices (e-mail, sms)

Lower Cost Per Contact

Cs

channels with self-service features

Easier contact with the field

Reaching assigned volume

mail, sms)

Opening new non-captive

Sale

s

l f

with the field force. New tools for supporting salesmen (PDA)

gtargets,

Better reaction to competitors

Quick launch of

non captive distribution networks

L t f

Mar

ketin

g Development of new “per channel” offering

Quick launch of new products, Tactical response to market and

Lower cost for developing new products

MT

market and competitorsReuse of existing software assets,

Flexible front-end,

Ad hoc

Preserving of back end systems,

Consolidation of IT infrastructures

IT Quick integration of “best of breed” solutions

Ad hoc customization by business line and business channel

“Per device” front end customization

Lowering maintenance costs

5

SOA: Reason Why

Issue Requirement

Multichannel Separating channel The Choice

Multichannel Management logic from back end

systemsMulti device Separating interface

Managementp g

logic from presentation

Lower Costs -> Reuse of existing assets

Legacy must be a service provider

SOA & J2EEof existing assets service provider

Time To Market -> rapid integration of third party Open integration

standards

J2EE

solutions standards

At present, in our opinion, no approach other than SOA can satisfy these requirements

6

Channel Applications Before SOA

Fiat Auto Dealer

Other Partners Contact C. B2C

CaptiveFriendWebFriend C/S

sava.itVantive FIN2000

Near Captive FinPlus Net FIN2000Vantive

Other Biz

LinesFIN2000Vantive

Applications were specialized by product and channel, based on many standards (ASP, PHP, C/S) and integrated ith th b k d t b i diff t t h l iwith the back end systems by using different technologies

7

Incremental The Project Approach

Design of First ApplicationsSOA Design Development of New

Applications

Design of processes, definition of front and back

d i

Definition of architecture functionalities and characteristics

Design of new processes, reuse of existing services, development of new services to fill the gaps

Main Phases

end services

R f t i f l d tDefinition of technical Ch

services to fill the gaps

Refactoring of legacy code to separate logic from presentation, devel. of front and middle tier functionalities on the J2EE environment

Technology Development

Definition of technical standards, development of the Capacity Planning

Change or development of back end services, middle tier and front end functionson the J2EE environment

Creating efficiency by reusing legacy codeTechnical

Ch ll

Technical Partner Selection: strong background on SOA t h l i d hi h

functions

Maximizing reuse of code by balancing changes to g g y

Integration and no regression test

Challenge technologies and high market reputation are key selection factors

existing software and new developments

8

SAVA’s SOA Architecture

• It includes the FUNCTIONS, a set of components directly interacting with the final user (pages, screens, reports)

It l k il bl th t f diff tPresentation

Web Layer • It also makes available the same set of pages on different channels and devices

Web Layer

• It is an architectural layer, with no application components

• It makes possible the call of services regardless of their l ti (diff t l tf ) It l t t ll d

Architectural Layer location (different platforms…), It also supports a controlled

and safe development of application components (functions and services)

Layer

• It includes the basic SERVICES (amortization plan development, credit scoring, …). It can be hosted on different platforms (Mainframe, AS/400, Intel …)

Business Logic LayerLegacy System

9

SAVA’s SOA Architecture – The Components Architectural

Layer

User, channel and device authentication; it also identifies the business profile

SecurityLayer

SecurityLayer

also identifies the business profile

D i ll th i ti fl

Preon

Preon

y y

Dynamically manages the navigation flow for each function based on channel and

device information

esentatin Layeresentatin Layer

device information

B i i l ti d ti ti

Integn La

Integn La

Business services location and activation

gratioayergratioayer

10

An Overview of SAVA’s Information System

FinWeb

Sales ExternalActorsCredit Collection

MAIN CHARACTERISTICS

FIN 2000

CACS

CARSFinWeb

B2C

CustomerServices • FIN2000 credit management system: custom application

Biz Services

PS8 CustId Card

StrategyOne

Banks

Postel8

DSSMS

system: custom application (Cobol on IBM iSeries), credit decision engine (Crif S1 package) integrated with FIN2000

MIS Ext.

Credit Bureau(CRIF,

CTC, etc.)

PPTTImagePlusCustomerValue/ Marketing

Ge.Co.Mir

FIN2000• Channel applications: SOA

model on open technologies (J2EE Websphere, AIX UNIX)E t i D t W h

MIS

CDB

DM MIS

SASCM

Ge.Co.Mir • Enterprise Data Warehouse (Oracle 9, SAS 8 for Data Mining, Ascential and Uniserve for data cleaning and

li ti )Credit Policies / Underwriting

Data MiningCM Office Automation normalization)

11

The Back End System: FIN2000 Metrics

• 3.400.000 of COBOL LOC, 1.915 screen files, 412 print files• 3.075 physical tables ,1064 indexes• FIN2000 dates back on 1996 12 000 man days of development• FIN2000 dates back on 1996, 12.000 man days of development

were done on the system over 2003-2005

Creating a SOA is also an opportunity to rewrite or reorganizeCreating a SOA is also an opportunity to rewrite or reorganize large chunks of “old” software

2%5%

high

The 51% of FIN2000 source code has a medium low or low

47%46%

high

medium-high

medium-low

low

medium low or lowmaintenance index (considering McCabe definition of complexity, yLOC and other factors )

12

Getting Services Out of a Large and Traditional Software Base

FIN2000 Software Repository • At the end of the project 70 Business Services were developed by refactoring p y gexisting code or by writing new code

• In total 950 man days were required for the y qtechnical analysis, development and test, around 25% more than the originally budgeted effort

• At present, the 70 business services are used by 4 front-end applications with a consistent integration approach and a fullconsistent integration approach and a full sharing of back end and front end services

We think that in a SOA project most of theWe think that in a SOA project most of the issues are occurring in the back end area

13

Fiat No Fiat Call An Overview of the SAVA Architecture

Dealer No Fiat Dealer

Customer

Center

PartnerPresen

LayPresen

Lay

Finweb

PeopleSoft 8

www.sava.it

Personal LoansPartner

ntation yerntation yer

Services Dispatcher

Integn L

Integn Lp

ServiceCatalogue

COBOL S i Java Services

gratioLayergratio

Layer

ToolBox for Java RMI

COBOL Services Java Services

Bus

LogicB

usLogic

iS i /COBOL W bS h AS

Fin2000 Other Operational

siness c Layersiness c Layer

iSeries/COBOL WebSphere AS

14

Fin2000Databases (CRM)

Other OperationalDatabases (CRM)

Channel Applications After the SOA Project

Fiat Auto Dealer

Other Partners Contact C. B2C

FinWeb New sava.itPeopleSoft 8

Captive

FIN2000

FinWeb FinWeb New sava.it

Near Captive PeopleSoft

8

FinWeb - PL FinWeb - PL New sava.it + Fi b PL

Other Biz

Li

FIN2000

PeopleSoft 8

Single integration architecture (J2EE, Web Services for third ti ’ i t i t ti )

Finweb - PLLines 8

FIN2000

parties’ environment integration )

15

Reuse of Business Services – the Theory

How the reuse of business services can reduce the effort for the design and development of new applications in a consistent functional

domain

• 1st Application needs X Services

domain

needs X Services to be implemented

• 2° Application2 Application need X+∆Y Services to

• Thanks to the efficiency when reusing services, ∆Y < X

16

Reuse of Business Services – The SAVA Point of View

Front EndEffort

Back EndEffort

TotalEffort

Front End/Back End Ratio

Effort by Additional Channel

Finweb 950 550 1.500 173%

Finweb for New 3 New

50 50 3,33%New 3 New ChannelsCustomer Service

600 400 1.000 150%ServiceCS for PS8 Channel

25 25 2,50%

CS f B2C 50 50 5 00%CS for B2C Channel

50 50 5,00%

Total 1.675 950 2.625 176%

Effort in man days for design, development and test

In our experience, the real efficiency is achieved in the development of multi channel applications

17

A Multichannel Example: SAVA eLoyalty Process

Car Configuration

PeopleSoft8

Reserved Area

g

ActualCONTACT CENTER

Car Configuration Data entry Evaluation

Dealer RatesVirtual

Show Room FinancialCalculator

B2C WEBSITE Loan Quotation

FinWeb

CDEALER FinalCar Price

ContractPrinting

18

ReleaseRelease • Collection of User Requirement by

SOA vs Traditional IT Organizations

SUBPROCESS 1SUBPROCESS 1 UtenteUtente

BusinessAnalyst

BusinessAnalyst

ManagerManagerReleaseManagerReleaseManager

ReleaseManagerReleaseManager

Y AZI

ON

I

q ySubprocess(user oriented)

• Functional Analysis by Application

D i d D l t b A li ti

SUBPROCESS 2SUBPROCESS 2 UtenteUtente ReleaseManagerReleaseManager

ReleaseRelease

TOD

AY

APP

LIC

A• Design and Development by Application• New programs• Changes or evolution of existing

programsT t

SUBPROCESS 3SUBPROCESS 3 UtenteUtente BusinessAnalyst

BusinessAnalyst

ManagerManager

ReleaseManagerReleaseManager

• Test• Integration test• No regression test

• Collection of User Requirement by Biz

B iB i

AnalysisPool

W

SOA Mgmt Pool

..

Collection of User Requirement by Biz Process(Business channel oriented)

• Functional Analysis • By Browsing the service catalog

BusinessProcessBusinessProcess us

ines

sui

rem

ents

usin

ess

uire

men

ts BusinessAnalyst

BusinessAnalyst

BusinessAnalyst

BusinessAnalyst

OR

RO

W (reuse)• By Designing new services

• Development by Components• New Parameters for Existing servicesProcessProcess

Bu

Req

uB

uR

equ

BusinessAnalyst

BusinessAnalyst

TOM

O • Easier integration test• Higher complexity for no regression

test

19

The Role of SOA Management Pool

The “SOA Pool” must be independent from the Application group and p pp g pmust have the following roles:

• Development and management of technology infrastructure

• Definition and nurturing of SOA competencies

• Support to the application design

• Management of Service ReposItory (Services, Flows, Metadata)Metadata)

• Auditing and validation of implementations

20

The Competencies of the SOA Management PoolIn order to be effective the SOA Pool must have:In order to be effective, the SOA Pool must have:

• Deep knowledge of company’s business processes and li tiapplication coverage

• Understanding of the Enterprise Data Model and CommonUnderstanding of the Enterprise Data Model and Common Information Files

• Responsibility of the Central Repository maintenance

Knowledge of methodologies and best practices• Knowledge of methodologies and best practices

• Awareness on the technologies in scopeAwareness on the technologies in scope

21

Evolution of Software Life Cycle (1/2)

SOA model adoption requires changes to the traditional development processes:

• The requirement analysis Is “by process” and no longer “by application”

• Repository is cross checked to identify every opportunity to reuse existing services, interfaces etc; new services and interfaces are defined when needed

• An impact analysis on the existing implementations and processes has to be performed

• The Application Flow Diagram is extended to include:pp g•The Function (user interaction)•The Services (business logic)•The Entities (to define the Conceptual Data Model)

22

Evolution of Software Life Cycle (2/2)

In Service Oriented Architectute the No Regression Test is a key point

• Repository is the key to identify side effects and impacts on different business and application areas created by changes or new developmentsy g p

• When planning development activities on services, the hole application portfolio has to be consideredthe whole application portfolio has to be considered, and not just the applications that are requiring changes to the back end.

• The SOA pool has the responsibility of defining the no regression test cycles, to ccordinate the test

i d th d l t ti iti t thsessions and the deployment activities to the production environment

23

Lessons LearnedBusiness Perspective

How ROI of SOA Solution can be Justified ?

• Opening of business channels with• Opening of business channels with new business partners

• Improving efficiency of BtoC (self-service approach)

Diff ti ti k ti h• Differentiating marketing approach by business channel

Organizational PerspectiveTechnical PerspectiveLegacy systems can be a good service provider with the reuse of existing assets

Organizational PerspectiveThe role of the SOA Management pool is the key to:

• Work with a process-centric i t d f li ti t iReuse of component can be

achieved when Front-End Tier and Back-End tier are strongly decoupled (role of service Dispatcher)

instead of an application-centric approach

• Effective adoption of Service/Function Catalog (for Reuse)Dispatcher)

Integration and No-Regression Test need a different approach

Reuse)

• Auditing and supporting the activity of other teams

24

Where We Are Today

• We are strongly convinced that we have achieved our objectives both on the business and IT sideobjectives both on the business and IT side

• Activities are still ongoing on these areas:•Building the SOA poolBuilding the SOA pool•Completion of service Repository with Matadata and Information flows maps

• The key issues we are addressing now are the limited internal competencies on SOA, and the complexity of building the new organization with the pressure of day by day operations and deliveryby day operations and delivery.

• At the end, building a SOA is like a never ending story when the most of your business functions are still encapsulated into large and complex legacy systemsencapsulated into large and complex legacy systems.

25