AG Insurance | Case Study on Software Flexibility | 01/03/2010 | page 1 Flexibility brings...

AG Insurance | Case Study on Software Flexibility |

01/03/2010 | page 1

Flexibility brings ComplexitySimplicity brings Flexibility

AG Insurance

The “iFlex” – “ELIA” Case Study

Capita Selecta Software Engineering

AG Insurance | Case Study on Software Flexibility | 01/03/2010 | page 2AG Insurance | Case Study on Software Flexibility | 01/03/2010 | page 2

Agenda

►AG insurance►The flexibility challenge►Case study: iFlex program – Xtreme flexibility►Xtreme consequences of Xtreme flexibility►Master complexity before implementing flexibility►Flexibility in AG Insurance


AG Insurance


IS AG Insurance in a NutshellKey Strengths: Flexible systems support product differentiation on a competitive and mature market

• Highly Integrated systems supporting Non Life products for both brokers and bank channels• All externally exposed front-ends are Web Based and considered as Market References• Very short time to market Mass Customization through an integrated business rules engine• Straight Trough Processing from offer to contract realization and from claims notification to settlement

Record Time to any Market, any Distribution

• iFlex is a major bank channel re-engineering project aiming for a better product flexibility, shorter time to market, lower cost and better customer services (Cross -Channel), facilitate also convergence with broker channel• iFlex program is moving from a bank channel platform to a multi-channel platform .

From even more Products & Services Innovation to Record Time to any Market

• Clients Tailored Products and Services through Products flexibility management Model of business concepts and engines• For new Cafetaria et Unit linked products : a full web based systems allowing external & very user-friendly access •Self–Servicing abilities for the clients (employers & employees) to allow STP

Excellence in clients tailored Products and services

• Common Insurance services to support all business lines• Expertise centres to reinforce productivity and quality on Software development (e.g. front-end development) • Interfaces with I&O

Flexible services supporting lines efficiency

• Flexible to support Multi Channels & Multi Businesses• Fully Integrated with BNP Paribas Branch Systems and Broker Office System• Multi–tier service oriented architecture

IS Insurance

IS Non Life

IS Life

IS Employee Benefits

(incl. Health Care)

IS General Systems &ExpertiseCenters


Agenda



No flexibility challenge

►The most flexible system is no system at all► A blank page/screen allows everything and anything to be built

► An architecture once defined restricts the flexibility in some directions

►Solo programming► Anyone can imagine a flexible application and develop it on it’s own

Developing a flexible system from scratch on your ownIn real life, this is NOT the challenge


The real flexibility challengeDeveloping► A flexible system

► Time to market► Cost efficient► Multi-Channel► …

► Integrated with existing systems► client databases► financial applications► accounting systems► …

► With a group of (typically) 20 - 50 developers► collaboration different teams► make a big application in little time► take into account the average programmer

► Using market standard development language/tools► risk related (continuity): use proven & supported technology if 6000 people use your

application daily (.NET – COBOL – DB2)► That works for at least the next 20 years

► return on investment: development is expensive

Developing with a big team a robust application that is flexible and runs for the next 20 years

In AG Insurance, this is the REAL challenge


Develop with 50 developersseveral 100s of modules/routines/components

50?

1500?

How can we guaranteeFlexibility at this scale?


Agenda



Case study: iFlex programBusiness pushes to Xtreme flexibility

Modernisation program for distribution of life insurance contracts►Goal is to have a very flexible system to easily define new life

insurance products►Time to market for new product definition is key►Give the product definitions entirely in hands of the business


►Business drilled down from end-2-end business process to automatable business rules.

► Modelling of the process done with Provision

► Output: set of rules

.

Figures - Illustration

SousProcess

SousProcess

ActivityActivity

TaskTask

Business IT

Business Rules

Business Rules

Business Rules

Business Rules

1:1

E2EProcess

E2EProcess

►IT took the challenge to build an engine to interprete and execute those rules.

► Transform rules in automatable and interpretable rules for the engine

► Build the engine

► Transfer the offer to the legacy system once contract is signed

iFlex flexibilityBusiness requirements will be delivered in form of rules


iFlex engineOnce the engine built, business is master of the application

Generalized rule concept►Very granular►Different functions

► Workflow rules

► Business logic rules

► Data rules

►Front-end behaviour also defined by rules

• Rule Examples:

• Controleren Aanvrager.IsInLeven• 2000073 {D} Afleiden Procesaanvraag.KantoorNaam• 2000016 {H} Ophalen Aanvrager.KlantID

• Large amount of Rules: currently 20006• Number of rules:


Variable location (DB) defined in rules

Owner CodeText AG MA MI Grand TotalBUS By Default 11 266 52 329

Calculation 76 76Deduction 166 766 92 1024Path 69 5 74Pre-Condition 635 78 713Processing 3 88 30 121ScreenRule 982 116 1098TaskRule 6010 6010Unknown 33 28 61Validation 652 652

BUS Total 1830 2139 6189 10158IS By Default 6 2 25 33

Calculation 6 6Deduction 98 70 153 321Doc 3 0 3260 3263IM 33 2 35Msg 53 35 2013 2101OM 62 196 256 514Path 4 4Pre-Condition 1519 555 2074Processing 21 32 508 561ScreenRule 55 26 38 119TaskRule 686 686Unknown 5 1 124 130Validation 1 1

IS Total 1822 961 7065 9848Grand Total 3652 3100 13254


LISA

External Systems

RC Rules(IM/BL/OM)

Data Rules(RD/SD)

Portfolio Dispatcher

LISA DBs:Finalized Contracts

LISADispatcher

Temp DemandSimulation &Contract Info

PresentationRules

(IM/OM)

Screen I/O Blocks

Document / Presentation

Blocks

Horizontal System

Services

DOC1

Business Rules(IM/BL/OM)

Parameter Dispatcher

Parameter Tables

Restore Data(RD)

Output Msg(OM)

Store Data(SD)

Business Logic(BL)

Input Msg(IM)

Rule Processor

Service Dispatcher

Communication Layer

ExceptionsExceptionDispatcher

Temp DBs:Working Data

Rules

Front End (NFE)

IT ArchitectureIT put in place a technical architecture around rule engine


iFlex project progress – end 20082 years of development of business and IT

►Engine is in place►Testing phase is running►Push to delivery in production – deployment in bank agencies

foreseen for 1st quarter 2009►Investments until then: approx 15000 mandays ~ € 10Mio

Only a small step to delivery of Xtremely flexible iFlex application


Agenda



iFlex PerformanceResponse times are incredibly high

General application performance- 40 times slower than other existing applications- 2000 rules executed with each user-interaction

Symptom: Menu page takes 10 seconds to display a choice of 7 menu-items

Lessons learned: - Flexibility generates overhead: designtime vs. runtime decisions - Flexible data interfaces: meta-data interpretation takes overhead - Flexible IO is killing data access performance


iFlex debuggingTesting phase is never ending

Symptoms: - Increasing stock of bugs - Increasing bug resolution time

Evolution daily stock "Urgent + High"

0

10

20

30

40

50

60

70

80

1/d

ec

4/d

ec

9/d

ec

12

/de

c

17

/de

c

22

/de

c

29

/de

c

5/ja

n

8/ja

n

13

/jan

16

/jan

21

/jan

26

/jan

29

/jan

3/f

eb

6/f

eb

11

/fe

b

16

/fe

b

19

/fe

b

24

/fe

b

27

/fe

b

4/m

rt

9/m

rt

12

/mrt

17

/mrt

20

/mrt

25

/mrt

30

/mrt

2/a

pr

Facts:

Upward trend in graph:• backlog increasing• no forecast for the end of the tunnel...• Due to amount of Urgent + High and priority => little time to fix low+medium defects• Heroes are bottlenecks in bugfixing

Lessons learned: - Xtreme flexibility generates unlimited possibilities - Flexibility brings complexity - Xtreme flexibility brings Xtreme complexity - Tests are all or nothing: we cannot test subsystems


iFlex integrationAssembly to full application fails

► Building the application only by knowing the very granular rules seems to be impossible

► Generic interfaces are generating major communication issues► Not clear how to use it, what is expected

Symptom: We don’t succeed in the final integration phase


T1 T2

Lessons learned: - If you don’t know the big picture it is extremely difficult to build it - Generic interfaces bring extra complexity


iFlex project progress – may 20092,5 years of development of business and IT

►iFlex program stopped►All code has been eliminated►Assessment of iFlex application

failure

►Restart from scratch►Using lessons learned and using

best practices

The ELIA program is born


Agenda



Master complexity before implementing flexibility The 4 basics of mastering complexity

1. Divide & Conquer► Abstraction level

► Architecture vs. Design

2. Encapsulation

3. Flexible interfaces

4. Limit flexibility


1. Divide and Conquer: Abstraction Levels


Mastering complexity : Abstraction Levels


1. Divide and Conquer: Architecture vs. Design

Complexity reduced to a smaller scale(only combined with loose coupling this can result in flexibility)


1. Divide and Conquer: ELIA program

Simulation & Underwriting

Process

Modification

Medical Acceptation

Financial

Referential

Products& PricingUnit &

Fund Mgt

Technical Support

Portfolio

Management Information

Security

Claims & Settlement

Service & Information Delivery

Co

re B

us

ine

ss

No

n C

ore

Bu

sin

es

sOutputsChannels

ELIA application

5.1.2.1 Plan

5.1.2.2 Contract & Addendum

5.1.2.3 Garantee

& Risk

5.1.2.4 Beneficiary

Clauses

5.1.2.5 Premium

Plan

5.1.2.6 Withdrawal

Plan

5.1.2.7 Party

5.1.2.8 Credit


2. Encapsulation

►Protect the different domains

►Write public services & interfaces

►Hide internal complexity

of the domain

►Limit the number of entry points!

Complexity hidden for service consumers


2. Encapsulation: ELIA program

Some example services of a domain►CreateLifeInsuranceContract►CalculateContractDuration►ProposeContractDuration►ProposeStartingDate►ProcessContractBasicData►CreateUpdateAddendum►ProposeBeneficiaryRightsTransfer

Portfolio


3. Flexible interfaces

Keep interfaces►Strict►Clean►Small ►Simple

►Explicit is better than implicit

Do not try to build “generic” interfaces ► it generates unnecessary complexity

► meta-knowledge generates overhead


3. Flexible interfaces: ELIA program

Public interfaces of services are explicitly defined with the least amount of business data needed.

CreatePolicyHolder

Language

Name

Firstname

Birthdate

Sex

PersonType

Riskprofile

RequestorID

…


4. Limit flexibility

Flexibility brings complexity

Limit it to the domains where you really need it!

How long before wemaster this very

flexible tool?


4. Limit flexibility: ELIA program

Simulation & Underwriting

Process

Modification

Medical Acceptation

Products& PricingUnit &

Fund Mgt

Portfolio

Claims & Settlement

Co

re B

us

ine

ss

ELIA application

In green you find the domains where we really need to implement flexibility


Agenda

►AG insurance►The flexibility challenge►Case study: iFlex program – Xtreme flexibility►Xtreme consequences of Xtreme flexibility►Mastering complexity before implementing flexibility►Flexibility in AG Insurance


Flexibility in AG insuranceOur best practice to implement flexibility

►Define the business entities that will pilot your flexibility►Define the characteristics of these entities that will influence

decisions►Parametrize in function of the characteristics using

► Conditional logic► Derivation tables

Note: A recent market study done by AG Insurance for rule engine software learns that mature packages on the market currently not offer more than this!

Simplicity brings Flexibility


Flexibility in the ELIA Program

►Parametrization itself is modeled in data model of 25 tables►Eg. Product definition is parametrized by 250 characteristics

► Payment plan: unique premium / recurrent premium

► DurationType: fixed / until pension

► InvestmentType: branch21 / branch23

► DistributionChannels: BNP Paribas Fortis / Brokers / Internet / …

► TaxRegime: deductible / non-deductible

► Commissions: % of commissions


ELIA project progress – TodaySuccess story

►10 months since restart►Intensive architecture follow-up►180.000 new lines of code in core application►Integration with more than 5 existing systems

►Used in production since last week (pilot bank agency)!►Fully available in all BNP Paribas Fortis branches as of next week!

►4 products developped►3 – 5 products will be released every 3 months►Deployment in broker channel is being prepared

ELIA is a flexible application!

AG Insurance | Case Study on Software Flexibility | 07/05/2009 | page 37

Questions?Come and build ELIA (or other applications) with us!

www.aginsurance.be/discover

AG Insurance | Case Study on Software Flexibility | 01/03/2010 | page 1 Flexibility brings...

Documents

Transcript of AG Insurance | Case Study on Software Flexibility | 01/03/2010 | page 1 Flexibility brings...