Always-On Services for Consumer Web, Mobile and the Internet of Things

1

Always-On Services for Consumer

Web, Mobile and the Internet of Things

Iver Band July 22, 2015

Open Group Conference, Baltimore, Maryland

© 2015 Cambia Health Solutions, Inc.

2 2 © 2015 Cambia Health Solutions, Inc.

Iver Band

• Enterprise Architect at Cambia Health Solutions

• Chief architect for external web and mobile presence

• Business architect for Digital Solutions organization

• Vice Chair, Open Group ArchiMate Forum

• Co-Chair and Co-Founder, Oregon Enterprise Architects

• TOGAF and ArchiMate certified, CISSP, Certified Information Professional, AHIP Certified IT Professional

[email protected]

http://www.linkedin.com/in/iverpdx

http://www.cambiahealth.com/

http://www.twitter.com/iverband

mailto:[email protected]

http://www.linkedin.com/in/iverpdx

http://www.cambiahealth.com/

http://www.twitter.com/iverband

3 3

Agenda

•Background

•Principles

•Patterns

•Implementation

•Conclusion


4 4

BACKGROUND


5 5

About Cambia

22 companies

and growing


A tax-paying nonprofit

headquartered in

the Pacific Northwest

Nationally recognized:

Top 100 Healthiest

Workplaces

5,300 employees

in 30 states

100 million people

touched nationwide

6 6 © 2015 Cambia Health Solutions, Inc.

7 7

Cambia Health Solutions


Senior

Services

Health

Insurance

Retail

Enablement

Provider

Enablement

8 8

US Healthcare Payers Must Innovate With

Consumer Applications


9 9

Problem: An Application Characteristics Mismatch

Hinders Consumer App Development

Legacy Application Characteristics

Mobile and IoT App Characteristics

Availability Regular Maintenance Windows

Always Available

Scalability Thousands of Users Predictable Peaks

Millions of Users Unpredictable Bursts

Response Time Keep Users Productive No Wait

Identity and Access Management

Internal User Base with Centralized Administration

Infinite User Base with Multiple Identity Providers

Data Normalized for Integrity

Cached for Performance and Availability

Integration Batch ETL and File Transfer

Lightweight, standards-based APIs


10 10

Solution: Bimodal IT for Healthcare Payers

Requires an Adaptive Service Layer


11 11

Always-On Services are Critical to C2B

Business Development for US Healthcare

Payers


12 12

Definitions of Key System Software Layers

• API Platform – A cloud-based application programming interface (API)

development and execution environment that provides access control,

monitoring, monetization and discovery.

• BaaS – Backend as a Service. A highly available, scalable and

extensible cloud platform that enables applications to interact uniformly

with services and data.

• ESB – Enterprise Service Bus. A platform that integrates applications

through message routing and transformation, guaranteed-delivery

queuing, and other services.


http://www.developereconomics.com/finding-right-baas/

http://www.developereconomics.com/finding-right-baas/

https://en.wikipedia.org/wiki/Enterprise_service_bus

https://en.wikipedia.org/wiki/OAuth

13 13

Additional Definitions • Microservices – An architectural style in which applications are

composed of small, highly decoupled services communicating with each

other via language-agnostic APIs.

• Publish/Subscribe – A message routing and delivery pattern that allows

a publisher to send messages to any number of subscribers, each

whom may consume exactly one copy of each published message

• REST – Representational State Transfer. An architectural style that

requires separation of clients and servers with a uniform interface,

stateless services with cacheable responses, and layered systems.

• OAUTH – An open standard for authorization that enables client

applications to access server resources on behalf of a resource owner,

and allows resource owners to authorize third-party access to their

server resources without sharing their credentials.


https://en.wikipedia.org/wiki/Microservices


http://www.enterpriseintegrationpatterns.com/PublishSubscribeChannel.html

http://rest.elkstein.org/

http://rest.elkstein.org/


14 14

An Integration Stack Enables Always-On Services


15 15

PRINCIPLES


16 16

Architectural Principle: Services are Reliable

• Statement

• Services are continuously available with accurate data and persistent updates, even during component failures and maintenance activities

• Rationale

• Consumers expect applications to function correctly whenever their client devices are operating

• Implications

• Services must function properly even when core business applications are unavailable

• Services must not

• Have single points of failure anywhere in their architectures

• Have unmitigated exposures to unreliable interoperating components


17 17

Architectural Principle: Services are Scalable

• Statement

• Service concurrency and usage capacities keep pace with demand

• Rationale

• Usage patterns and demand cannot always be predicted in immature markets.

• Implications

• Services are

• Stateless

• Low-latency

• Loosely-coupled to interoperating systems

• Built on infrastructures that scale automatically


18 18

Architectural Principle: Services are

Reusable

• Statement

• Services can be reused and recombined in new contexts to meet changing needs

• Rationale

• Business models and the applications that support them change rapidly, requiring flexible choreography

• Implications

• Services are built to execute simple operations that are easy to access and combine

• Services are built with standards-based APIs and security components

• Application designers and developers consider the performance and scalability implications of reusing services in new situations


19 19

Architectural Principle: Services are

Understood

• Statement

• Cambia and partner stakeholders are able to discover services and develop insights from service consumption

• Rationale

• Discovery, development and continuous improvement of innovative consumer-focused business models and applications requires experimentation with new services, along with insight into application behavior as illuminated by service usage

• Implications

• Applications access all services through a single hub that enables straightforward service discovery, and monitors and captures each service execution


20 20

Architectural Principle: Underlying Systems

and Data are Protected

• Statement

• Services allow only properly authenticated and authorized access to core business applications and data

• Rationale

• Consumers expect their interests to be protected, and maintaining consumer trust is essential to successful and sustained adoption.

• Implications

• Access paths for both services and underlying systems are consolidated

• Access control for those paths is least-privilege and transparent.

• Service usage is monitored, governed, traced and tracked as necessary to mitigate the risk of misuse

• Services examine user profile information to make additional authorization decisions


21 21

Always-On Services Principle Realization


22 22

ALWAYS-ON SERVICE

PATTERNS


23 23

Four Patterns Support Always-On Services


24 24

Always-On

Read

Pattern


25 25

Always-On Publish Pattern


26 26

Always-On Subscribe Pattern


27 27

Pass-Through Pattern


28 28

IMPLEMENTATION


29 29

Some Always-On Services At Cambia


Consuming Application Always-On Service Core Business Application

Consumer Mobile Payment

Member Information Member Administration

Provider Clearinghouse Member Documents Enterprise Content Management

Consumer Portal

Personalization Member Administration

Product Product Management

Claims Claims Processing

Member Information Member Administration

Identity Enterprise Directory

Benefits Member Administration

30 30

Facilitating Service Reuse with an Enterprise

Repository


Service Usage Patterns are key components of TOGAF Solution Building Blocks

31 31

Conclusion

• US healthcare payers must develop innovative consumer businesses while

continuing their core business operations

• This requires a bimodal IT architecture with an Adaptive Service Layer between

consumer and core business applications

• This layer must enable reliable, scalable and reusable services

• These Always-On services must protect core business systems and data

• Organizations must understand service usage to build successful consumer apps

• An Adaptive Service Layer can consist of an API Platform, BaaS and ESB

• The Read, Publish, and Subscribe patterns enable a broad range of services

• The Pass-Through pattern gives existing services added reusability, visibility and

security

• An Enterprise Repository can facilitate service reuse

• Standards-based Enterprise Architecture can persuasively link business

strategies to specific IT investments


Technology

Always-On Services for Consumer Web, Mobile and the Internet of Things