Download Presentation

Truly Agile Actuarial Applications 

CAE Fall Mee*ng Zurich 

28 September 2012 

Roland Bürgi

What is the Meaning of Agile? 

1: marked by ready ability to move with quick easy grace 

 

2: having a quick resourceful and adaptable character 

 

Source: Merriam-‐Webster 

28.09.2012 Truly Agile Actuarial Applica*ons 2

Systemorph at a glance 

Founded March 2011 

Head Office Zurich 

Mission Systemorph outperforms tradi*onal development by 

• providing ready-‐to-‐use implementa*ons 

• delivering cuSng edge architecture 

• using modern design paTerns 

• avoiding heavy specifica*on and documenta*on 

• reducing development *me by factors 

Organisa*on Scalable start-‐up, agile, decentralised team, 

onshore and nearshore 

Business Model Partnering with SW-‐houses (Integrators) 

09.10.12 Systemorph Company & Pla\orm 3

Agility in Small Projects 

• For small projects, the choice of technology and process hardly 

maTers 

• They are focused around an individual; leverage personal skills 


Challenges in the Actuarial Profession 

IFRS SST 

28.09.2012 Truly Agile Actuarial Applica*ons 5 

Global 

Communica*on 

Solvency II 

• Several challenges cannot be mastered by individuals 

• Many diverse skill sets are required to accomplish the task 

• Collabora*on and communica*on is vital 

Group Pricing 

and Reserving 

• Interfaces are generally difficult and require careful engineering

Project Method: The Waterfall 


Characteris*cs 

• Heavy specifica*on and documenta*on 

(paper programming); Business Analyst 

has to an*cipate everything 

• Sequen*al process steps, revisi*ng 

hardly possible 

• Big itera*ons (releases every 3-‐4 months) 

• Programming with light-‐weight 

architecture at low abstrac*on possible 

Consequences 

• Project becomes heavy and in-‐agile 

• Lacking flexibility is blamed on bad 

business specifica*ons 

• Projects are long and expensive

Project Method: Agile Development 

Characteris*cs 

• Small itera*ons (1-‐3 weeks) 

• Strong user involvement 

• Con*nuous refactoring 

(keep code in mo*on) 

• High extensibility 

• Very intensive tes*ng 

Consequences 

• Sohware at an early stage 

• Visibility of progress 

• Con*nuous refactoring 

• Con*nuous improvement 

• High user sa*sfac*on 


Does Agile Development always work? 

• Agile Development is primarily a wish: Develop in small cycles, release ohen and 

keep everything flexible 

• How do you achieve a common architecture when you have to start producing 

sohware in sprint 1? 

• How do you guarantee consistency in the applica*on when many persons work 

with liTle specifica*on? 


The Agile Process (e.g. Scrum) 


• Organise your team like a rugby team 

• High degree of self organisa*on of the team 

• Itera*ons are called sprints (1-‐4 weeks) 

• Each sprint starts with planning 

• Each sprint ends with retrospec*ve/review 

• Each day, the daily scrum (15’) is held where 

each team member answers three ques*ons: 

1. What did I do yesterday? 

2. What will I do today? 

3. Where am I blocked? 

• Scrum supports the agile development with a light-‐weight process 

• However, Scrum is not the only enabler needed!

Team Culture 


• Team members must be observant that the 

concepts are always consistent and the code is 

always clean 

• No one must be shy to redo their work. It is 

highly important that the work fits into the 

context and that it is maintainable 

• Each individual must be concerned to reach the 

team goals 

• Team members can speak up at any *me, the 

management should listen and react 

• Agile development is a cultural effort by the team 

• The agile culture has to be fostered and enforced by management

Don’t Repeat Yourself (DRY) 

Source: ibm.com 


• In classical specifica*ons, a number of 

artefacts are involved 

• The existence of a certain field can occur in 

all these artefacts 

• Furthermore, this field will occur in mul*ple 

implementa*on and tes*ng artefacts 

• If the field needs to be changed, the change 

has to be adapted in all these documents 

• All these artefacts have to be kept up to 

date è several management resources are 

needed 

• A unique source of truth should contain all aspects 

• Avoid any duplica*on of informa*on – Duplica*on Is Evil (DIE)

Convention over Configuration 

All sheep are white 

This sheep is black 


• 80% of the specifica*on are not substan*al but can 

be described with conven*ons 

• Examples: 

• Fields are called the same in the data model, on 

the database, in the UI, etc. 

• En**es and their proper*es are visible to 

everyone 

• Excep*ons can be specified in configura*on 

• Overall, this enhances extensibility: 

• New en**es get sensible defaults 

• Defaults can be changed transparently 

• Data situa*on is transparent 

• By choosing clever conven*ons, specifica*on can be reduced to the min 

• In most technologies (e.g. Excel), this approach is not possible

Specification and Documentation 

Traditional Development Don’t Repeat Yourself (DRY) 

• Having specifica*on and documenta*on redundant kills readability. 

• Being able to focus on relevance makes informa*on lean and readable. 


DRY and 

Convention over Configuration

The Systemorph Domain Model 

[RestrictRoleAccess(EditActions.Any^EditActions.Read,“Actuary”,“Specialist”)]! 

public class LossEstimates : EntityWithDescription! 

{! 

![ShortName(“MPL”)] ! 

!/// ! 

!/// The anticipated loss at the Frequency! 

!/// ! 

!public double MaximumProbableLoss {get; set;}! 

!! 

![RestrictRoleAccess(EditActions.Edit, “Actuary”)]! 

![Range(0.01, 10)] ! 

!/// ! 

!/// Frequency at which AnticipatedLoss is spec.! 

!/// ! 

! 

} ! 

!public double Frequency {get; set;}! 

![RestrictRoleAccess(EditActions.Edit, “Actuary”)]! 

![Range(0.7, 10)]! 

!/// ! 

!/// Shape of the severity distribution! 

!/// ! 

!public double ParetoAlpha {get; set;}! 


Don’t Repeat 

Yourself 

Conven*on over 

Configura*on

Architecture 


• The architecture must enforce unity in the team 

• It should not be visible by whom a certain feature is 

programmed; all developers must have a uniform style 

• Extensibility must be kept a core value: Whenever it 

has to be limited, this has to be done consciously and 

transparently 

• The architecture must support modern design 

paTerns (DRY; CoC etc.) 

• The team should be dealing with content, not with low 

level implementa*ons 

• Architecture is a principle enabler for agile development 

• The team should focus on content and not implementa*on details

Programming with Lean Architecture 


• High degree of individualism 

• Low abstrac*on level 

• Duplica*on of code is frequent 

• Code is typically not reusable 

• Concepts are fragile 

• Maintenance is difficult 

• Overall high cost of ownership 

• Developing at low abstrac*on is fast at the beginning, very slow later 

• Applica*ons are inflexible and difficult to maintain and to test

Dilemma: Architeture vs Visibility 

• Adaptability 

• Transparency 

• Simplicity 

• Unity 

• Need for a pla\orm 


• Quick visibility 

• Fast burndown 

• Quick itera*ons 

• LiTle architecture 

• Difficult to extend 

• Difficult maintaince

Choices of Architecture 

Low Abstrac*on 

Pla6orm 

Build Own Pla6orm 


Early visibility of first func*onality 

Easily separable for programming (e.g. one screen each) 

Difficult to test and change 

Overall the most expensive 

Ready-‐made architecture which can be trained 

Clean and standard ways of implementa*on (unity) 

High degree of testability 

Users can focus on your core competences 

Difficult to achieve; requires qualified architect 

High degree of commitment needed from the organisa*on 

Not in the core competence of an insurance company 

Visibility of success only very late in the project è high risk 

• The pla\orm approach allows for lean and agile tool development 

• The users can focus on agile development of their core business

Wikispeed: Modularity and Tools 


• Wikispeed builds 100 miles per gallon cars 

• Process: Scrum 

• Development *me: 6 months 

• Enabler: fully modular car 

• Enabler: contribu*ons of many specialists 

• Enabler: Good toolset which is arranged so 

that it is above the materials it is used with 

è self-‐documen*ng 

• It is even possible to build 100 mpg cars agile with distributed team 

• The results bring you quantum leaps improvement

Unit Testing 


• Unit tes*ng is a good way to provide 

examples of how to use func*onality 

• Unit tests are wriTen during the development 

• They will always be up to date, as execu*on is 

required to guarantee quality 

• The unit tests are a perfect security net for 

refactoring, which again is an enabler for 

agility 

• The test suite is security net for refactoring 

• The test cases serve as compilable and executable documenta*on

Summary 

The following enablers are needed to run lean and agile development: 

• Team culture of con*nuous changing (refactoring) 

• Agile process framework (e.g. Scrum) 

• Modern design paTerns: 

• Don’t Repeat Yourself (DRY) 

• Conven*on over Configura*on 

• Systemorph Domain Model 

• Architecture suppor*ng agile development 

• Unit tes*ng enabling refactoring 


Systemorph Pla6orm provides: 

• Standard Implementa*ons 

• Ready-‐made Architecture 

• Consistent User Experience

Thank you very much for your attention! 

Questions are highly appreciated!

Download Presentation

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?