vitality one enabling global delivery - the open group · 2013-09-11 · implement a buy vs. build...

Vitality One – Enabling Global Delivery EA Practitioners Conference September 2013

Agenda

Current Landscape and Challenges

Understanding the Vitality Strategy

Objective of Vitality One

Approach –

• TOGAF – ADM & Phase 1 Scope

• TOGAF – Prelim

• TOGAF – Architectural Vision

• TOGAF – Business Architecture

Critical Success factors

Global Device Layer


International Structure

+1.5 Million Members

+2.5 Million Members

Launched – 2013 onwards

Startup -

15000 Members

+ 400 000 members

450 000 Members


Vitality is not a single global offering –

It is a wellness program that is usually attached to an underlying Financial Services Carrier –

• Carrier relationships are typically joint ventures

• While there may be some consistencies in the overall product structure - the Vitality program needs to be tailored to local requirements and partners

• Each JV entity is responsibility for their own growth and profitability & have their own drivers

The TVG model in the US is unique as it is an Employee Group Wellness Program


Functional Components

• Vitality consists of 3 primary components:

• Member Administration • Member Administration and Management

• Points Allocations, Member Status, Health Attributes etc

• Financial Systems, MDM. Loyalty and Rewards

• User Interactions (Web Site / Mobile App) • Vitality is often exposed to members through carrier or partner

web sites

• Vitality is increasingly being exposed through mobile

• Includes biometric devices

• Partner Interactions • Partners are a key aspect to the Vitality offering

• Partners are typically local not global


Technical Challenges

• The Vitality System was originally built as a benefit of Discovery’s Health Product

• Vitality components were extracted from the Health System and implemented as a stand-alone offering

• Time pressures meant that this was done as expediently as possible

• Maintained Interdependencies with Discovery Corporate Systems;

• Master Data Management

• Communications and Correspondence engines



• A new Vitality instance is required for each JV partner – currently we have 6 Vitality instances;

• The core functionality needs to be kept in sync across all instances (ERP Package)

• Local layer components are modified to cater for regional requirements -

• Partner integrations are implemented in a point to point manner

• Development is often driven by partner capabilities rather than through well defined service contracts



• Markets have implemented functionality independently and are at different levels of maturity

• Markets have their own development capabilities and aspirations of independence

• Different dev teams have different technical capabilities, adhere to different standards and implement on different technology stacks


Implementing Vitality in a new environment is technically challenging, time consuming and not

entirely cost effective

Also

Causes a duplication of effort across regions

Not optimally geared for future rapid roll out in parallel markets

Yet somehow Discovery manages to do this

Vitality Strategy

• Vitality overall goal is to sell more insurance for affiliated carriers / TVG to sell more wellness programs

• Vitality is a wellness program with rewards attached to it – Primary purpose is to make people healthier - It is not primarily a rewards program

• Program must be geared towards a smooth end user experience and enhance the users lives

Business Strategy

• Business directive is to deliver the Vitality strategy within operating markets

• Product value offering should endeavor to be consistent across the regions

• Products and processes must be able to cater for regional requirements and carrier specific expectations

• Products should allow multiple partners to interact with Vitality

Systems

Strategy

• Systems should deliver on the Vitality business strategy –there to enable the business

• Systems should not unnecessarily constrain the business in terms of the execution of its strategies

• Systems delivery should be in an expected, consistent and flexible manner

• Systems delivery costs and delivery timeframes should be managed and consistent

• Systems should not dictate the business process flow – this must be defined by business


Vitality One

Objectives

Objective

Existing

Define a roadmap, approach and design for a Vitality Operating and Systems Environment that is cost effective, flexible and able to service the diverse

requirement of multiple tenants

Irrespective of their location or Carrier Partner

New New New New New

Objective

Define a Standardised Product Offering – across tenants

Standardised Business Processes – across tenants

Re-architect the Systems Environment

Define a roadmap, approach and design for a Vitality Operating and Systems Environment that is cost effective, flexible and able to service the diverse

requirement of multiple tenants

Irrespective of their location or Carrier Partner

Vitality One

Approach

Approach – Framework - TOGAF ADM

Approach – Phase 1 Scope

Approach – Prelim

Framework &

Principles

Prelim - Reference Architecture

IBM SOA Reference Architecture

Prelim - High Level Principles

Vitality should be a standalone system that is not

tightly linked to any underlying carrier systems

The Vitality Systems should be defined around the key business objectives and the business operating model

Business should be aware of the architectural design principles and development methods

All development should be designed with re-usability and configurability in mind

System development and enhancements should be based on service oriented principles

Technology stack should be well defined and standardised across regions

• where possible in alignment with the Discovery Group

Implement a Buy vs. Build strategy for commodity and

“plumbing” requirements • For build solutions industry standard frameworks should be

used to facilitate development efforts

Integration will be facilitated through a set of common and standardised integration mechanisms

Industry Standard Protocols will be used where possible


The systems must meet the defined non functional

requirements, including: • Security

• Operability

• Performance,

• Reliability,

• Extensibility,

• Manageability,

• Scalability,

• Availability

• Maintainability


Approach – Architectural Vision


Build vs. Buy Continuum

Custom Package

Built to spec

Highly Flexible

Unique

Longer development

Evolve

Increasing complexity

Fragmented configurability

Generic

Less flexible

More Configurable

Complex but formal

architecture

Faster delivery

Enabling Technologies

Development tools

Frameworks

Methodologies

Vitality

www.purewellness.com

http://mobihealthnews.com/11717/five-competitors-to-humanas-new-wellness-platform/

http://www.selfoptima.com/solutions/corporate/wello-the-wellness-platform/

http://www.pdhi.com/

http://www.purewellness.com/





















http://www.pdhi.com/

Vitality Inputs Outputs

Carriers

Health Partners

Rewards Partners

Clients

Financial

Carriers

Health Partners

Rewards Partners

Clients Servicing

Financial Data

Reporting

Client and Admin screens

Policy Administration

New Business

Servicing

Premium calc and debit

Health Reviews and

Assessments

Vitality Age and Points

Calculations

Reward Redemptions and

Cash backs

Etc

Security

Document management

Workflow

Business to Business

processes


Vitality

Policy Master –

Administration and

Maintenance

Client Interactions

Web / Mobile/ Call C

Process Management

(Workflow)

B2B

Health Partner

Interactions

B2B

Financial Interactions

B2B

Rewards Partner

Interactions

Security and Access

Control

Unstructured -

Information

Management

B2B

Carrier Interactions


High Level Functions

Vitality

Policy Master –

Administration and

Maintenance

Client Interactions Workflow and Process

Services

Security and Access

Control

Unstructured -

Information

Management

B2B

(Partner

Services)


High Level Functions – Consolidated

Vitality

Policy Master –

Administration and

Maintenance


Services

Security and Access

Control

Unstructured -

Information

Management

B2B – Carrier

Interactions B2B

Partner

Services


High Level Functions – Integration Points

Architectural Vision

Vitality

Policy Master –

Administration and

Maintenance


Services

Security and Access

Control

Unstructured -

Information

Management

B2B

Partner

Services

Integration Layer

High Level Functions – Integration Layer

Vitality

Back Office

Front Office

Policy Master –

Administration and

Maintenance


Services

Security and Access

Control

Unstructured -

Information

Management

B2B

Partner

Services

Integration Layer

Syste

ms M

an

ag

em

en

t an

d

Mo

nito

ring

De

ve

lop

me

nt S

erv

ice

s


Strategy and Planning

Business Services and Events

High Level Functions – Mapping to SOA Ref Arch


Vitality

Front Office:

Client Interactions

Client Interactions

What:

User Interfaces and

services –

• Vitality Admin and Call

Centre

• Vitality client web sites

• Vitality Client Mobile

• Carrier Web sites

• Carrier Mobile

• Partner Web sites

• Partner Mobile Sites

Cost, Resources, Effort

How:


Business Architecture

Systems Architecture

Technology Architecture

Migration Planning

Governance

Change management

Principles – Client functionality should be

repeatable and configurable

Client interactions must be

facilitated through a Client

Gateway / Service Layer


Vitality

Front Office:

Workflow and Process

Services

Workflow and Process Services

What:

Business Process

Management

Orchestration of Business

Processes

Manage the business

service from inception to

completion.

Policy Servicing


How:





Migration Planning

Governance

Change management

Principles –

Process Services – should

implement a Lightweight

workflow

Integration with Carrier

enabled through the B2B layer


Vitality

Front Office

Information Services

Information Services

What:

Content Management and

management of

unstructured data

Document management

Imaging and Indexing

Email requests

Who:

Business

Systems


How:





Migration Planning

Governance

Change management

Principles – Information Services

Must be provided by Vitality or

must be able to integrate with

Carrier Information Systems

Candidate for buy


Vitality

Back Office

B2B Partner Services

B2B Partner Services

What:

Enables Integration

between Vitality and

various Partner systems

•Carriers Partners

•Health Partners

•Devices

•Rewards Partners

•Financial Partners

Principles: - B2B Services

Industry standards

Standardised Service

Contracts for partner

categories

Decoupled services for

partner categories


How:





Migration Planning

Governance

Change management


Vitality

Back Office

Application Services

Application Services

What:

Policy Master Systems –

Policy Servicing and New

Business

Vitality Policy

Administration

Financials and Ledger

Loyalty and Rewards

Warehouse and

Reporting


How:





Migration Planning

Governance

Change management

Principles- Application Services

Single instance multi tenants

Internationalised

Configurability (BRMS)

Componentised development


Vitality

Back Office

Access Services-Security

Access Services - Security

What:

Enables a common

security framework

across components

Directory Services

O-auth

Etc


How:





Migration Planning

Governance

Change management

Principles – Security Services

Standard security protocols

Must enable security across

Chinese walls


Vitality

Integration

Integration

What:

Mediates between

service requestors and

consumers

Decouples the

relationships between

systems

Resolves format and

protocol differences

Enriches

Implements a common

domain model

Principles – Integration

All systems must be enabled

through standard / single ESB

Guranteed delivery, transform,

routing, enrichment


How:





Migration Planning

Governance

Change management

Approach – ADM – Phase 1


Starting Premise

• The success of Vitality One will be enhanced if there is an effort to standardise on product definition and constructs

Business Analysts and Business collaboration is therefore critical in the project

Critical Success Factors

Vitality CSF’s

• Vitality Version 1.0 Aligns to and enables the Vitality Strategy:

• Provides a compelling wellness platform that provides for the rapid / cost effective introduction of Vitality into new regions

Business CSF’s

• Allows the product value offering should be consistent across the regions

• Regional Requirements can be implemented in a configurable, consistent and manageable manner

• Partner integration is easy and consistent

• Workable standardised product spec

Systems

CSF’s

• Systems implementations are consistent and efficient and cost effective

Critical Success Factors

Global Device Integration Layer

The Device Landscape - Fitness

Fitness / wellness / health / medical apps and devices are becoming

increasingly popular and pervasive ABI Research:

Wearable Sports and Fitness Devices will hit 90 million shipments in 2017

Device proliferation means that there is no dominant market leader

and there are a large number of consumer devices available This includes physical devices as well as in-phone apps

New devices and apps with enhanced capabilities are released

regularly Barrier to entry is low and without incentivisation to stay –

Users will abandon bad apps in favour of others that are perceived to be better

Trends may emerge where different devices enjoy different levels of popularity in

different regions

The Race is on to own the Wellness Ecosystem . . .

Wellness

TicTrac

Activity –

Strava

Mapmyfitness

Eating

MyFitnessPal

Ifood Diary

Food Diary

Other

Dental

Advice

Exercise

MyWellness Cloud

MyVirginActive

Device Sites

Nike

Fitbit

Jawbone

The Device Landscape - Fitness

Problem Statement

Vitality has no consistent approach to device integration either at a

device level or at a country level- this results in: A duplication of development effort and costs

Inconsistent user experience

Inconsistent approach to data collection across devices and regions

Duplicated negotiations with device manufacturers

Vitality device integration will continue unabated each

time a new model with enhanced functionality is

released – integration costs will need to be allocated for

each new device Vitality will always be playing catch up

The same applies to Health for health devices

Recommended Strategy

What do we want?

Wide offering of integrated devices

Speed to market

Intuitive, clear, slick customer experience for uploading data

Integrated experience (same place for uploads)

Cost effective

Re-use

Consistent process in all markets

Clear servicing strategy


To be able to integrate with many devices or apps to allow us to collect information and award points to members who are tracking their fitness or health through a device

of their choice

Wellness

TicTrac

Activity –

Strava

Mapmyfitness

Eating

MyFitnessPal

Ifood Diary

Food Diary

Other

Dental

Advice

Exercise

MyWellness Cloud

MyVirginActive

Device Sites

Nike

Fitbit

Jawbone

Vitality Global Device Data Store


Vitality Global Device Data Store

Vitality

SA

Vitality

TVG

Vitality

Pru

Vitality

AIA

Vitality

PA

Vitality Humana

Device

Device Device Device Device Device Device

Device Device Device Device Device Device

Device

Aggregator - A Aggregator - B Data Pull –

Vitality collects device data

at predetermined intervals

Vitality Instance applies own rules and allocates required points on activity data received

Aggregators –

Collect data from device

manufacturers on behalf of Vitality

Data Push–

Device manufacturers push data

to Vitality – preferably real time

VI Device Data Store

Device API – used to expose services to

external parties to send the data to Vitality

Data to be verified, de-duplicated,

transformed and standardised


Value of Integrators

• Collecting data from multiple device manufacturers and mobile apps

• Cleaning, scrubbing, validating data

• Matches device owner to Vitality member

• Faster integration with new devices and according to SLA

• Single interface for multiple devices - provides standardsied data structures

• Single security mechanism for multiple devices

• Handles service problems with device manufacturer

• Reduced effort for Vitality to sync with multiple devices

Qualcomm 2NetHub

Questions,

Wrap up and Close

vitality one enabling global delivery - the open group · 2013-09-11 · implement a buy vs. build...

Documents