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