© 2007 athena confidential 1 between the rock and the hard place – core systems replacement or...

© 2007 Athena Confidential 1

Between the rock and the hard place – core systems replacement or renovation?

Tom Rogerson, CTO Financial Services Sector EMEA

Sydney, March 2008


Agenda

• How we got here

• The cookbook: strategies for replacement or renovation

• Making a success of replacement strategies– Selecting a package vendor

• SOA – the silver bullet?

• Making the decision


How we got here…

• Insurance an early adopter of technology

• Change on change

• M&A

• Relics of previous strategies (CRM, ERP, client/server…)

• Previous (failed) replacement projects

• Weak IT governance

We’re still adding legacy quicker than we’re removing it


... and it’s causing real pain

• Poor flexibility: – speed to market, new distribution channels,

business process improvements, automation

• Costs: – 60%+ of spend on maintaining the old

• Risk: – obsolete technologies, brittle architectures,

poor understanding

• Damaged IT / Business relationship:– IT focused on keeping the lights on

• Challenges different for Life/Wealth Management and P&C (but sufficiently similar to justify a single discussion)

Bjarne Soustrup: “Legacy code often differs from its suggested alternative by actually working and scaling”


The cookbook: strategies for replacement or renovation

Outsource • Application Outsourcing or• Business Process Outsourcing

Re-engineer • Tactical re-engineering or full re-platform

Wrap • e.g. SOA

Replace •Build or buy

Consolidate •Onto one (or a very few) of your existing systems

Componentise •External components


Consolidate or replace?

Consolidate Replaceor

Strategies for replacement or renovation

“pick your best system and convert to it”

better the devil you know replatform then consolidate?old system old system = old system

Commonly considered in Life / Wealth Management for legacy products

Build Buyor

“we know our business best” “it’s about competitive

advantage” “no troublesome vendor

relationships”

“we’re not a software house”

“need to pool investment with others”

“short term priorities will blow us off course”

Build strategies for speciality lines otherwise Buy strategies favoured on risk grounds


Componentise strategies


• Tactical:– hardware re-platforming– Identify / streamline stabilise the 20 percent of code that is:

• invoked the most often and / or• has a history of being changed and / or• has a history of causing problems

• Strategic re-platforming:– code conversion / model-driven development / business rules extraction

• Increasing potential• Re-platform then consolidate?

Re-engineer strategies

• “changing the wheels on the moving train”– Easy: e.g. document production– Medium: e.g. calculations, billing, UI, product rules– Hard: e.g. policy admin

• Very common for the easy stuff …

• … but tends to stop at the hard core of policy administration functionality

Re-engineer

Componentise


Outsource strategies


• Business process outsourcing (BPO):

• Well established• Primarily focused on

cost reduction

• Well established where transformation is to vendor’s strategic

platform

• (Potential) agenda conflict hell

Closed Book Open Book

Without ITTransformation

With IT Transformation

Outsource


Outsource strategies


• Application service provision:

Proven Frees budget to tackle legacy strategy

? Include IT transformation in an Application Outsourcing deal?– Tempting, but best to retain control

Increasing responsibility delegated to the vendor

Staff Augmentation• body shopping

Managed Service• narrow range of service

Application Outsourcing• full accountability• can include transformation

Outsource


Making a success of replacement strategies

• The perils of doing replacement as an IT-only initiative:

IT: “We have the business case, you’ll scarcely notice”

… some time laterBusiness: “We know you’re working hard but we can’t wait, we need to launch new products”

… a little laterBusiness: “Hey, the new functionality we are getting is less than in the old system”

… and not much laterBusiness: “This is too expensive and painful. We need to stop and reassess”

… and an unpredictable amount of time laterBusiness: “Why is our IT landscape so cluttered?”

Replace


Making a success of replacement strategies

• Replacement strategy must be part of a wider business initiative:– shared case for action not just a business case

• Allow time up front to integrate business process designs with IT designs:

– will take longer than you could imagine

• Integrated business & IT plans, program management and governance

• Business change management an integral part of the program, not an afterthought

• Use the package as package, not a tool kit

• Data migration & quality realistically built into the plan:– the older the application, the worse these will be

– proven approaches, tools and vendors exist, use them

Replace


Selecting a package vendor

• Harsh reality: the insurance package market is $MM but highly fragmented

• Highly parameterised (business processes, rules)• Excellent functional fit• Easy to extend, based on standard frameworks• Standard, open technologies• Can be deployed in components but also “in a box”• Flexible integration mechanisms, based on industry standards• Good access to skills• Proven in your line of business at your scale

The ideal insurance package …

… so that’s no problem then.

Replace


The functionality versus architecture dilemma

• Older packages tend to have more functionality but worse architectures

“If we spend five times more on enhancement than on initial implementation shouldn’t I select the best architecture?”

“But if the functional gap for the initial implementation is too great then that’s a major risk in its own right …”

“… and if I can’t deliver value quickly then I’m in trouble”

it depends on the product line (for stable, legacy products, choose a mature package)

never be the first to implement a package (nor the last) watch out for the “draggy-droppy” sales demonstration score packages against weighted criteria that balance function and

architecture for you (but decide these up front)

Replace


Challenges for a package vendor (in addition to the traditional functional / technical checklists)

Your objectives

The vendor

Functionality Technology

The relationship

Thepackage

• How are you different and why does it matter to me?

• What clients do you have and when can I talk to them?

• What’s your biggest implementation?

• Where have you implemented my products before?

• How will you help me achieve speed to market?

• How will your integrate with my legacy?

• How do you separate rules from code?

• Walk me through a typical implementation• How will I benefit from investments other clients are making?

Replace


SOA – the silver bullet?

Wrap


The SOA promise• Allows you to build on your investment in your core systems

• Allows legacy functionality to be orchestrated in new ways

• Allows IT to become more responsive to business needs

• Potentially a way of enabling piece-by-piece legacy replacement strategies

… and the pitfalls• Many more moving parts to manage: reliability, scalability,

performance, security, wide range of skills needed

• The standards soup

• Analysis paralysis

• Harder governance – who owns what?

• Architect wars, vendor hype

Wrap


• Some high profile failures

• SOA not to go away (though the name may change):

– SaaS and BPO will drive adoption

• Package vendors repackaging themselves as component providers (approach with caution)

• Not to become a commodity soon:

– how you design and implement an SOA project still more important than the technology choices you make

You can expect

• Get some experience now – if only on a small scale

• Don’t expect it to solve your underlying legacy issues

• Focus on delivering business benefits early, worry less about getting it right first time

Exploiting SOA

Wrap


Replatform?

BPO?

Making the decision – the right recipe for you?

ApplicationOutsource

Re-engineer

SOA

Replace

Consolidate

Componentise

• … to free up budget

• … and potentially BPO for legacy products

or and

Part of a wider business strategy?Y N

and

• … functionality or architecture?

• … so far but no further?

• … tactical: good benefits but limited• …re-platform

• … long term potential, start now

• …will it address the business issues?


Questions?

© 2007 athena confidential 1 between the rock and the hard place – core systems replacement or...

Documents

strategies strategies

athena confidential

business case

reengineer strategies

business relationship

integrated business

time later business

business process designs