Architecting Web and Mobile Solutions to Meet Modern Customer Expectations A Case Study @ Cigna...

Architecting Web and Mobile Solutions to Meet Modern Customer ExpectationsA Case Study @ Cigna

Brian Mitchell, Ph.D.Enterprise Architecture

@DrBrianMitchell

Who Am I?

Architecture Leader@ Cigna

Research Professor@ Drexel University

object Part2{ def main(args : Array[String]) { println("""

| Somewhat technical content | on what we are doing and | what we are exploring for | the future.""")

Talk Outline

Part 1

Where we were,Where we are,

Where we are going

A “somewhat technical”overview on how we are

getting there…

Recognizing #CignaThoughtLeaders

Clinical ITRTDE

Let’s get started byreviewing some vintage

slides

Our Starting Point (circa 2008)

Integration Server Reporting

Application Server Web Content ManagementPortal Server

Search

Security

Network Enrollment

Op. Financials

Case Installation

DentalMedical

IndividualHealthcare

ProfessionalEmployeeEmployer

myCIGNA

MSS DSS Pharmacy

CIGNAAccessCIGNAforHCP

ESSPSSCIGNA

VoluntaryMyCareAllies

CIGNABehavioral

OneView

YourCIGNA

Choicelinx

Data MHS Data Data

Bluecard

PowerstepData Data DataData Data

Data Data

Print Data

ECMDocGen / Collateral Member

mycignaplans

VieLife

Medical Management

TelDrug

Data Data Data

Database Database Database

Content Management

Security

Integration IntegrationIntegration Integration

Security Security

Reporting

Security

Search

Security

Reporting

Security Security Security

Content Management

Security

Reporting

Integration

HSA/ FSA

CIGNA.comHealthAdvisorItstimetofeelbetterFUSE, NAIC, RRD, CarealliesCIGNAMedicareCIGNASharedAdminMGM, CMG, + 80 other Content sites

VendorACES Vendor

Vendor Vendor

GreatWest

Search

Search Content Management

EmployeeIndividual

Content Management

Reporting

Integration

Hosting

Cigna Datacenter

External Data Center

SaaS Provider 1

SaaS Provider 2

SaaS Provider 3

Web/HTTP

Web/HTTP2

Portal 1

Portal 2

Portal 3

Custom

Contribute

Vendor

Open Source

Database SearchTool 1 Tool 2

Java/J2EE

Vendor App

GreatWest

Integration

Custom

Data Data

IndividualHCP

Employer

So how does this happen?

Meet our Lead Web Architect

Time to Modernize !

Remember when you couldn’t play with the cool kids unless you separated concerns

Cigna moved to a layered “Portal” based architecture…[note the only word changed on the slide was “responsive” – the term did not exist then - it was “personalization” prior]

Presentation Services

Internal Applications

Platform Services

CustomerHealthcare

ProfessionalClient

CignaEmployees Broker

Enterprise ServicesCustomer

IntelligenceSelf-Service Transactions Integrated Constituent Data

Search

Personalization & Customization SyndicationContent Delivery

Social Networking

Constituent Services Constituent Content Workbench

Self ServiceHealth

Coaching

Enrollment Finance

Reporting

Risk Assessment

Claims

Analytics

Information

Education

Marketing

Training

Trusted Partners and Client Sites

Constituent Interactions

ResponsivePortal Server Web Content Management[JSR Standard Portlets] [Custom CSS for Web/Mobile] [Authoring & Publication]

SecurityServices

Availability &Performance

Services

Distributed DataGrid

VirtualizationHypervisors

SOA EndpointVirtualization

Discover, Govern

App Server ClustersJ2EE

Authentication,Authorization &

HTTP Proxy

Federation

Fine-Grained Externalized

Access Control

Runtime Policy Enforcement

XML Gateway

Web Services

Technology Interactions

blog, wiki, forums.

Collaboration

SSO: Registration &

Delegation

Enterprise DataEnterprise DataPortal Data

Books of Record Info FactoryTransaction

StoresPortal

RepositoriesMDM Hubs &

Indexes (Cache)LDAP Security Stores

(Internal/External)Data Grid

IntegrationService Bus Customer Data Integration

Event Processing

Process Orchestration

ChannelsWeb Mobile Call B2B

MonitoringCloud Solution

Web Services

App2AppApp2App

Portals in the cloud,Specialty Vendors, Practice Management Solutions, Consumer enrichment services

…Success will be definedas achieving a

user experience that is

“Scary – 1”…

2010 2011 2012Q1 Q2 Q3 Q4

Project Management Office

2013Q1 Q2 Q3 Q4Q1 Q2 Q3 Q4Q1 Q2 Q3 Q4Q3 Q4Q2

Content Management

Document Management

Single Sign-On

Welcome to CIGNA & Portal Promotion

Constituent Unified View

Future State Platform Definition

Interactive Guidance

Multi-Lingual / Multi-Cultural Portals

Scenario Planning

3rd Party Data Integration

Mobile Assessment

Usability Design

Test & LearnOnline Analytics Channel Metrics

Broker Portal

Communications & Alerts

Reporting

Interactive Demo

Feedback, Comments,&

Ratings

User Profile & Preferences

Social Networking & Forums

Delivery Planning

Program Management

& Governance

Constituent Segmentation & Strategy Refinement

Change Management & Communication Planning

Launch Quick Hits

Health FinancePlatform Strategy

3rd Party Content Delivery

Boulder Data Center Migration

Access Mgmt

Search – Phase 1 & 2 Search – Phase 3

Usability and Consolidation Usability & Consolidation Usability & Consolidation

Personalized search

Enriched Messaging

Provider Directory Improvements

Consolidate Great-West for Individual

Portal

Usability & Consolidation

Consolidate Voluntary, CBH for Individual Portal

Consolidate Great-West. Voluntary, CBH for HCP

Portal

Consolidate Great-West. Voluntary, CBH for

Employer Portal

Mobile Enablement

Access Mgmt

Quick Usability Enhancements

Constituent Transactions

Mobile Enablement

“OH NO…THAT IPHONE IS COOL

WE NEED TOACCELERATE MOBILE!”

Approaching 1,000,000 Downloads

Web Services

Customer

Mobile Endpoint (MSP Layer)

Web AssetsMobile Specific Assets EnterpriseServices

Platform Data

Online-SpecificRepositories

Legacy DataSources

Data GridCache

IntegrationFabric

EAIFramework

Service Framework

APIFramework

MessagingFramework

Mobile Network

Mobile APIs Mobile Enrichment Services(Push, Cache)

ProfileData

TargetingRules

ContentRepository

DigitalAssets

IdentityData

Mobile App

iOS ApplicationAndroid Application

Our High Level Mobile Architecture

We also have APIs for locatinga doctor, medical cost estimation, and pharmacy cost estimation

Publicly accessible at:http://developer.cigna.com

We also love our APIs

Creating our web, mobile and API platforms over time has created a few architecture reuse challenges that we are addressing

eWeb & Mobile WebArchitecture

MobileArchitecture

Thank goodness, write-once, deploy-everywhere.

Is this the solution?

HTML5 is probably part of the solution, but its not

a silver bullet…

Figuring out the right balance whilepreserving a great user experience

0% < HTML5 < 100%

A more sensible mix probably looks more like this:

SharedWeb & MobileArchitecture

Mobile

Architecture

Our Revisited Reference Architecture

Platform Services

CustomerHealthcare

ProfessionalClient

CignaEmployees Broker

Entitlement RecommendationTargeting

App Framework (Common Business Logic)

Personalization Services

Customization &Content

Notification & Eventing

Identity

Platform Data

Online-SpecificRepositories

Legacy DataSources

Data GridCache

IntegrationFabric

EAIFramework

Service Framework

APIFramework

MessagingFramework

ChannelsWeb Mobile Call B2BWeb Services

StaticContent

UX Framework Mobile Framework

Other Cigna APIs and Services

Other Cigna Apps

App Data

Security &Registration

SecurityMobile

EnrichmentSearchCaching DynamicContent

ProfileData

TargetingRules

ContentRepository

DigitalAssets

IdentityData

Network (Internet & Mobile)

Web & Responsive Web App Native / Hybrid Mobile Apps

Business Objects

API Gateway

3rd Party Apps

Business Objects Business Objects

EnterpriseData

Sources

Warehouse

Looks like our Web Architect Picked Up Some New Skills

2007 2015

How are we doing this?Warning: Some Technical

Content Ahead

The nature of applications is changing, this is driving the refactoring of modern enterprise architectures

On the Front End: On the Back End:

New Application Architectures

3rd Party Integration Requirements

Refactoring our SOA Approach to…

…Move from Course Grained “Big” SOAP services to Composable RESTful Services

Mobile

Supporting diverse customer experience needs becomes a primary objective of our underlying solution architecture

Web & Mobile Web

Native & Hybrid

Customer-Initiated

Cigna-Initiated

“Apps” – Task Oriented

Cigna initiates outreach to customer. Goal is awareness, and to get the customer to “take action now”

We need the customer to complete a task – it has a beginning, a middle and an end.

Customer comes to Cigna to “do something”. Goal is to make it easy and fast for them to find what they want

Solutio

I need to

find a doctor!

What is th

is bill about?

I need a new ID

Am I elig

ible for th

You can save money

Take advantage of incentiv

Enroll in th

is program

Take the HRA

Order Rx Refill

s Online

Product Enrollm

The goal is to have the customer experience drive the technical architecture, and not the other way around

At the same time Front-end Architecture Changes are Driving Back-End Architecture Changes

Moving from a traditional Web architecture…

Browser

Server

APIs Services

Server

Controller

Browser

App Runs in Browser

App Rendered in Browser

To a modern “Client-Centric” architecture…

Services

Native

App Runs in Device

These new apps requirerethinking the integration

Getting it correct isessential for success!

For us, that is here…

We also are interested in concepts inspired by the Reactive Community

http://www.reactivemanifesto.org/

the system responds timelywith consistent responsiveness

component boundaries traversedusing asynchronous messages

responsiveness maintainedunder varied workloads

responsiveness maintainedin the face of failure

Message Driven

Responsive

Elastic Resilient

Step 1 was to define an overall reference architecture that we could use to ground and educate the organization

object HTML5 and SOA Reference Architecture

HTML5 Enabled Browser or Embeded Viewer

External Internal

HTML5 App

Javascript Libraries

View (HTML,CSS,

Javascript)

Responsive Libraries / CSS (Bootstrap)

Client Side MVC Framework (e.g., Angular)

Module Config

Routes

Controller

Injectable Components

Services Provider Factory Value

Partials

Framework Services

Futures(Async)

SOA(REST)

Security LocalStorage

InboundAPI Gateway

Content Server(Cigna and/or

ApplicationDeployment

Service Integrationand Composition

Information Layer

Enterprise Data

LightweightContainer (Spring

Integration, Camel,etc)

Robust Container(Fuse, ESB, WPS,

BRMS, etc)

Security

Policy

HTML5 App

External Partners

Partner 3

Partner 1

Partner 4

Others...Partner 2

Partner 5

API Layer

Name: HTML5 and SOA Reference ArchitectureAuthor: Brian MitchellVersion: 1.0Created: 3/7/2014 12:22:43 PMUpdated: 10/7/2014 10:52:15 AM

Mobile Cache

MobileEnrichment

Mobile Push

REST Front-EndServ ices

ContainerTBD(Node, Spray,Spring, etc)

Web ContentManagement

MessagingContainer (MQ,

WMB, AMQ, etc) -Pub/Sub, Async,

Eventing, etc.

ServiceImplementation

Application/DomainServices

Enterprise Services

ASG SpecificData

Local Data

Partner API Gateway

Security Policy

Mobile Device

Cigna Native App

Mobile OS / Mobile OS Services

GPS Local StorageContact List

Security Native MVC Assets(non HTML5 Views)

Reusable FrameworkComponents

Overall Cigna App Storyboard (AppNavigation)

Responsive Web App

HTML5 App

Portal-Based Web App

Traditional Portlet

Static Content

HTML5 Enabled Portlet

HTML5 App

14Note that the green box titled "HTML5 App" to the right represents the detailed view in each of the green boxes in other deployment scenarios to highlight the nature of the hybrid solution driving reuse of common components.

Native ViewsWebView withHTML5 App

HTML5 App Container

Core SOA Component

Legend

Notification,Eventing, andWebSockets

CommonServices

Logging

API Developer Portal

API Documentation,Registration, API Keys,

Runtime Governance, etc

ctive S

OB Only

REST or SOAP

sync E

IB / OB OB Only

This architecture promotes 5 key areas of focus

External Internal

HTML5 App

View (HTML,CSS,

Javascript)

Module Config

Routes

Controller

Partials

Framework Services

Futures(Async)

SOA(REST)

InboundAPI Gateway

Information Layer

Enterprise Data

BRMS, etc)

Security

Policy

HTML5 App

External Partners

Partner 3

Partner 1

Partner 4

Others...Partner 2

Partner 5

API Layer

Mobile Cache

MobileEnrichment

Mobile Push

Eventing, etc.

Enterprise Services

ASG SpecificData

Local Data

Partner API Gateway

Security Policy

Mobile Device

Cigna Native App

Responsive Web App

HTML5 App

Traditional Portlet

Static Content

HTML5 App

HTML5 App Container

Core SOA Component

Legend

CommonServices

Logging

ctive S

OB Only

REST or SOAP

sync E

IB / OB OB Only

1Create

2Compose

3Enrich

4Manage

& Secure

5Consume

To get started we needed to clearly define how we wanted our new REST services to be designed

External Internal

HTML5 App

View (HTML,CSS,

Javascript)

Module Config

Routes

Controller

Partials

Framework Services

Futures(Async)

SOA(REST)

InboundAPI Gateway

Information Layer

Enterprise Data

BRMS, etc)

Security

Policy

HTML5 App

External Partners

Partner 3

Partner 1

Partner 4

Others...Partner 2

Partner 5

API Layer

Mobile Cache

MobileEnrichment

Mobile Push

Eventing, etc.

Enterprise Services

ASG SpecificData

Local Data

Partner API Gateway

Security Policy

Mobile Device

Cigna Native App

Responsive Web App

HTML5 App

Traditional Portlet

Static Content

HTML5 App

HTML5 App Container

Core SOA Component

Legend

CommonServices

Logging

ctive S

OB Only

REST or SOAP

sync E

IB / OB OB Only

1Create

We like others have found SOAP abstractions make reuse difficult.

w/SOAP “Extension is via Addition”

Does this belong here?

REST = Reuse via CompositionBuild higher level abstractions from

granular reusable parts

As typically happens – early adopters who dabbled in REST created services at Level 0 of

the Richardson Maturity Model

Guidance was required to educate our development community on creating services at Level 2 and Level 3

Our focus is on “Pragmatic” REST

Using Composition == Speedup Required

ClientApplication

Server

Contract-OrientedSOAP Services

ClientApplication

Server

Resource-OrientedREST Services

FROM TO

Performance Increase Target

[Note that we currently execute about 4.5 billion web service calls per year]

Our new REST services run in 10-100msOur Traditional SOAP Services run about 500ms-3 seconds

Education Required: “REST in a Box” Workshop

class BoundedContext Example

Product Resource

«ContentBasedRouter»ProductResourceRouter

+ ResourceFactory(): Resource

«abstract»Product

«RestService»SupportProduct

«RestService»MarketingProduct

«RestService»AccountingProduct

«RestService»BillingProduct

«instantiate»

Eric Evans

Martin Fowler

We took concepts of Bounded Context from DDD and applied them to REST

Inspiration from Thought Leaders: Business Context + REST

External Internal

HTML5 App

View (HTML,CSS,

Javascript)

Module Config

Routes

Controller

Partials

Framework Services

Futures(Async)

SOA(REST)

InboundAPI Gateway

Information Layer

Enterprise Data

BRMS, etc)

Security

Policy

HTML5 App

External Partners

Partner 3

Partner 1

Partner 4

Others...Partner 2

Partner 5

API Layer

Mobile Cache

MobileEnrichment

Mobile Push

Eventing, etc.

Enterprise Services

ASG SpecificData

Local Data

Partner API Gateway

Security Policy

Mobile Device

Cigna Native App

Responsive Web App

HTML5 App

Traditional Portlet

Static Content

HTML5 App

HTML5 App Container

Core SOA Component

Legend

CommonServices

Logging

ctive S

OB Only

REST or SOAP

sync E

IB / OB OB Only

Use established EAI Frameworks? Use Functional Reactive Methods? Use Both?

Options….

2Compose

The “Composition” Layer

Composition is required because we don’t want to…

ClientApplication Server

SOAP Request

SOAP Response

• SOAP Semantics are too abstract• Extension via contract addition• Large message sizes• Over time services become harder to

call and there is a need to filter out response data based on what is needed

ClientApplication Server

RESTCalls

• REST Services are more granular• Promote composition over reuse• Problematic if the client is

responsible for all of the composition• Need a solution to create higher-

level abstractions from granular REST Services

Replace the problems associated with this (Course-Grained Services)…

With new problems associated with this (Granular Services)…

SPLIT AGGREGATE

/customers/123?...

/orders/123?...

/bills/123?...

FLOW: CustomerSummary

EAI Server on JVM

DEPLOY

At Cigna we currently are using both Spring Integration, Apache Camel and RxJavain production

Example Composition – Getting a customer summary: GET https://api.cigna.com/v1/customers/123/summary

Reactive Streams

The API layer focuses on convenience, enrichment, and security for our modern apps

External Internal

HTML5 App

View (HTML,CSS,

Javascript)

Module Config

Routes

Controller

Partials

Framework Services

Futures(Async)

SOA(REST)

InboundAPI Gateway

Information Layer

Enterprise Data

BRMS, etc)

Security

Policy

HTML5 App

External Partners

Partner 3

Partner 1

Partner 4

Others...Partner 2

Partner 5

API Layer

Mobile Cache

MobileEnrichment

Mobile Push

Eventing, etc.

Enterprise Services

ASG SpecificData

Local Data

Partner API Gateway

Security Policy

Mobile Device

Cigna Native App

Responsive Web App

HTML5 App

Traditional Portlet

Static Content

HTML5 App

HTML5 App Container

Core SOA Component

Legend

CommonServices

Logging

ctive S

OB Only

REST or SOAP

sync E

IB / OB OB Only

3Enrich

4Manage

& Secure

Although we are still in the Synchronous-One quadrant, we wanted to position the architecture

for other reactive patterns

One Many

Synchronous Try[T] Iterable[T]

Asynchronous Future[T] Observable[T]

Newer SOA patterns embrace asynchronous processing based on event handling andmessaging. They don’t use store-and-forward queues.

Asynchronous platforms will be critical for keeping up with the Moore’s law curve, we wanted a platform that moves us away from request/response (a.k.a. Servlet Container)

Around 2005 we started to see clock speed and performance of CPUs level off. Performance is now increased by having multiple-cores on a chip, but this causescomplexity that our software needs to deal with…

More Cores = Harder Software

Amdahl’s law also comes into play when trying to determine the maximum speedup that can be achieved

This means to scale we also need to avoid parts of a system that need to be coordinatedacross an async boundary (e.g., shared mutable state)

To enable asynchronous capabilities we wanted to ensure that our API

platform was not layered on a container based on a

pipe-and-filter architecture

Newer asynchronous platforms are inspired by both old and new software

engineering research

ReactorPattern (1995,1999)

ProactorPattern (1997)

LMAX DisruptorPattern (2011)

http://www.cs.wustl.edu/~schmidt/PDF/reactor-siemens.pdf http://www.cs.wustl.edu/~schmidt/PDF/proactor.pdf http://lmax-exchange.github.io/disruptor/files/Disruptor-1.0.pdf

We are still determining the platform(s) for our API layer buthave been using the following…

We just got started… but Functional Reactive Libraries Take Us to the Next Level

http://reactivex.io/documentation/observable.html

Functional ReactiveLambdasClosures

Pure FunctionsComposable

AsynchronousValuesEventsPush

Warning… I'm a Scala Geek…

and the only real way to see the power of functional reactive techniques is to look at code

Example: Getting a Customer Summary using Service Composition with Functional Reactive Techniquesdef customerSummary(custId: Long) :Observable[Map[String,Any]] = { customerService.getCustomer(custId).flatmap( cust => { val orders: Observable[Map[String,List[Order]]] = orderService.

getOrders(cust.account_id).take(10) map (olist => Map( “orders” -> olist)) val bills: Observable[Map[ String,List[Bill]]] = billService.

getBills(cust.account_id).take(12) map (blist => Map( “bills” -> blist)) val theCust = Observable. just(Map(“customer” -> cust)) theCust ++ orders ++ bills } }}

//Run Itdef custSummaryService(name: String) = customerSumary( lookupCustId(name) ).

toBlocking.toList.reduce( _ ++ _)

Note to better show the concept RESTFul services are wrapped in helper functionsGET /v1/customers/{name}/summary custSummaryService(name)

def customerSummary(custId: Long) :Observable[Map[String,Any]] = { customerService.getCustomer(custId).flatmap( cust => { val orders: Observable[Map[String,List[Order]]] = orderService.

Example: Getting a Customer Summary using Service Composition with Functional Reactive Techniques

STEP 1: Setup a Web Service REST Binding to map to a function

getBills(cust.account_id).take(12) map (blist => Map( “bills” -> blist)) val theCust = Observable. just(Map(“customer” -> customer)) theCust ++ orders ++ bills } }}

STEP 2: Stage a call to the Customer Web Service

How does it work?Note that the getCustomer() function MUST return an Observable, the actual type is an Observable of a Customer object or Observable[Customer] – nothing happened yet

STEP 3: Use the “flatmap” operator to indicate that you are going to combine some things asynchronously, but need something to happen first. Specifically data for the last

10 orders, billing information for the past 12 bills, and customer profile data are to be obtained but the account number from the getCustomer service is a pre-requisite.

NOTE: (1), (2) and (3) ALL EXECUTE CONCURRENTLY – why?THEY RETURN OBSERVABLES!

STEP 4: At this point we have 3 separate Map objects, we want to combine them to create an Observable of these three Map objects. This operation has the type of

Observable[Map[String,Any]] , which aligns to the return type of the function.

NOTE: In Scala, the last executable statement in a scope is returned, the return keyword is not required

STEP 5: The cusomerSummary function is called but it returns an Observable. Nothing has happened yet! To extract the data we need to do a few functional transformations:

Examples: val custData = customerSummary(lookupCustId("Mitchell"))custData(“customer”).phoneNumbercustData(“bills”)(0).outstandingBalancecustData(“orders”)(0).orderDate

1. toBlocking: This function waits for the customerSummary service to execute2. toList: Since the customerSummary service will return a stream of Map

objects, this will create a List( OrderMap, BillMap, CustMap) object3. reduce: This last operation will take a list of 3 Maps , each with a single

key/value, and combine them into a single Map with three key/values.

subscribe( theObj => send(theObj))

STEP 5a: We can also do this fully asynchronously by calling subscribe() and then sending the individual Map's as they get resolved using Observables

Now how do we consume these APIs from a modern client?

External Internal

HTML5 App

View (HTML,CSS,

Javascript)

Module Config

Routes

Controller

Partials

Framework Services

Futures(Async)

SOA(REST)

InboundAPI Gateway

Information Layer

Enterprise Data

BRMS, etc)

Security

Policy

HTML5 App

External Partners

Partner 3

Partner 1

Partner 4

Others...Partner 2

Partner 5

API Layer

Mobile Cache

MobileEnrichment

Mobile Push

Eventing, etc.

Enterprise Services

ASG SpecificData

Local Data

Partner API Gateway

Security Policy

Mobile Device

Cigna Native App

Responsive Web App

HTML5 App

Traditional Portlet

Static Content

HTML5 App

HTML5 App Container

Core SOA Component

Legend

CommonServices

Logging

ctive S

OB Only

REST or SOAP

sync E

IB / OB OB Only

5Consume

Example: From an internal code-a-thon – Consuming services from a client asynchronously

1. Authenticate2. Get User Information3. Query Surveys4. Pick a Survey5. Take the Survey6. Update the Survey7. Complete Survey8. Get Confirmation

Code9. Ensure that

everything worked or handle failure condition

This solution is declarative versus imperative, while being fully non-blocking and immutable.

From a modern client perspective this architecture works very well on platforms that are optimized to integrate over REST

Browser

Server

APIs ServicesApp Runs in Browser

Native

App Runs in Device

REST Services Secured by oAuth and OpenID Connect

Supporting modern clients, especially SPAs, requires looking at the end-to-end lifecycle

Vendor Tool

Note that the client side development lifecycle heavily uses open source tooling. Due to Cigna policies I have redacted places where we are using commercial tools

Vendor Tool

Wrapping Up! We have been working on many efforts to modernize our web and mobile solutions to scale using modern architecture approaches described in this talk.

PolyglotDevelopment

PolyglotPersistence

Reactive:Async, Eventing &

Notification

DevOps &MicroServices

NextGen Web &Mobile Architecture

Improving theCustomer Experience

SOA RefreshProject

SOA Strategy

Example: Cigna Compass

Example: Health Risk Assessment App

Example: Healthcare Professional Directory Tool

Example: Cost & Quality

Jeffrey, Elsa, MD

Lessons Learned(mainly organizational challenges – debunking myths – managing change)

• Time to get everybody aligned with the fact that SOA 1.0 is over (ESB as the center of the universe is so 2005)

• Can't we just add another layer?• Challenges with breaking free of the

verb-centric SOAP mindset (POX != REST)• Dogmatic RESTafrianism• Polyglot – I need to learn a new

language?• Why can’t we stuff data into that RDMS

(Not considering "best-fit persistence" )• Can't we at least keep the XML?• Async Really? We are not google• Threads, Immutability, Non-Blocking –

doesn't the container do that?

Again, thanks to #CignaThoughtLeaders

Global Solutions GroupClinical ITRTDE

E AEnterprise Architecture

Questions?

Architecting Web and Mobile Solutions to Meet Modern Customer Expectations A Case Study @ Cigna...

Documents

Real Doctors. Real Results. - Cigna“Cigna” and the "Tree of Life" logo are registered service marks of Cigna Intellectual Property, Inc., licensed for use by Cigna Corporation

Cigna Health and Life Insurance Company (“Cigna”) Cigna ... · tnindepo052017 cigna connect-0 tnindepocopay052017 miep0326 miep0414 miep0243 miep0125 miep0330

Cigna Health and Life Insurance Company (“Cigna”) · Cigna Dental Preventive DENTAL INSURANCE Industrial Policy Cigna Health and Life Insurance Company may change the premiums

Cigna Health and Life Insurance Company (“Cigna”) Tennessee Cigna …€¦ · phone Us at the number shown on Your Cigna identification card if You have any questions regarding

Architecting Participation

Module 3 Architecting & Transformation...Module 3 Architecting & Transformation Appreciate VariousVarious architecting architecting transformationtransformation with with tthhee businessbusiness

Cigna Producer Agreement - Cigna Official Site | Global

· Unit 8 ANTHEM/CIGNA Table of Contents . Anthem/Cigna . The transaction . Anthem, Inc. and Cigna Corp., Press Release, Anthem Announces Definitive Agreement To Acquire Cigna Corpor

a Prepaid Limited Health Services Organization P.O. Box ... · 1 CIGNA Dental Companies CIGNA Dental Health Plan of Arizona, Inc. CIGNA Dental Health of Colorado, Inc. CIGNA Dental

CIGNA CORPORATION FOURTH QUARTER 2011 INVESTOR ...€¦ · INVESTOR RELATIONS NOTE: Cigna has made editorial changes to this transcript. As used herein, “Cigna” refers to Cigna

Cigna-HealthSpring Rx Secure (PDP)ecu Cigna-HealthSpring Rx … · 2020-02-28 · Cigna-HealthSpring Rx Secure (PDP)ecu Cigna-HealthSpring Rx Secure-Essential (PDP) 2020 Pharmacy

CIGNA HEALTH AND LIFE INSURANCE COMPANY€¦ · Mailing Address: Hartford, Connecticut 06152 CIGNA HEALTH AND LIFE INSURANCE COMPANY a Cigna company (hereinafter called Cigna) CERTIFICATE

Cigna Health and Life Insurance Company (“Cigna”) an Exclusive Provider …€¦ · Cigna Health and Life Insurance Company (“Cigna”) an Exclusive Provider Organization (EPO)

Cigna Health and Life Insurance Company (“Cigna ......Cigna Health and Life Insurance Company (“Cigna”) 900 Cottage Grove Road Bloomfield CT 06002 Cigna Connect 0-4A Plan If

Cigna Health and Life Insurance Company (“Cigna”) Cigna US ...€¦ · Cigna Health and Life Insurance Company (“Cigna”) Individual Services 900 Cottage Grove Road Bloomfield

Cigna Health and Life Insurance Company (“Cigna”) …...NV DP002 01-2019 Cigna Dental Preventive Cigna Health and Life Insurance Company may change the premiums of this Policy

CIGNA HEALTH AND LIFE INSURANCE COMPANY · 1/1/2021 · CIGNA HEALTH AND LIFE INSURANCE COMPANY a Cigna company (hereinafter called Cigna) CERTIFICATE RIDER No. CR7BIASO10-1

Global Health Service Company - Cigna Dental Preventive Plan · 2018. 9. 17. · Cigna Health and Life Insurance Company (“Cigna”) Cigna Dental Preventive Plan. If You Wish To

Architecting Speed

Architecting RIAs