Is it really useful to have a framework ?

13th International HL7 Interoperability Conference 27th-28th September 2012 , Vienna, Austria

Stefano Lotti HL7 Italia Chair Enterprise Architect at Invitalia – Government Agency for Inward Investment Promotion and Enterprise Development

“Is it really useful

to have a framework ?”

Agen

da

IT Go

vernan

ce

«Spending on information technology – again, within the bounding of

virtually every project, program and management initiative – is at an

all time high in the public sector and will continue to increase. With

that increasing investment, government will also continue to depend

more and more on information technology to achieve efficiencies,

collaborative information sharing, business intelligence, and

information socialization …

In parallel with these trends, state government is entering a period of

fiscal stress and constrained budgets, the end of which is unknown.

With declining state revenues, state government will be called upon for

greater transparency and accountability.»

“IT Governance and Business Outcomes – A Shared Responsibility between IT and Business Leadership” NASCIO – National Association of State Chief Information Officers, March 2008

• In the issue of September 2011 of the Harvard Business Review, Flyvbjerg and Budzier in «Why your IT project may be riskier than you think» presents the results of a research based on an analysis of 1.471 IT projects, U.S. and European (mainly in public sector)

• In the research, the authors noted that the average cost overrun was 27%, but that figure masks a far more alarming one.

• one out of six of the analyzed projects is a «black swan», with a cost overrun of 200%, on average, and a schedule overrun of almost 70%.

• So the real problem is that the so-called «black swan» seems to be a rare phenomenon in which you think a little, but they are dramatically frequent.

Wh

y you

r IT pro

ject may b

e riskier than

you

thin

k

• We should stress the point that the issue is not so much in the cost average overruns

• The fact is that there is a high percentage of catastrophic results and projects completely out of control with damage ranging beyond the single project.

• A «black swan» has a magnitude that can destroy the organization itself

• The literature on the subject often has been focused on the increased costs and has obscured the real problem

• The point that should be stressed is that the issues do not emerge normally from the technology in itself but from the lack of management in the IT project and among the different projects of an organization and the organization in itself.

Wh

y you

r IT pro

ject may b

e riskier than

you

thin

k

A Stress Test

• Flyvbjerg and Budzier suggest a stress test for any organization that want to build a large IT project, to assess if it is suitable for the organization:

«

1. is the company strong enough to absorb the hit if its biggest technology project goes over budget by 400% or more and if only 25% to 50% of the projected benefits are realized?

2. can the company take the hit if 15% of its medium-sized tech projects (not the ones that get all the executive attention but the secondary ones that are often overlooked) exceed cost estimates by 200%?

»

• Although the organization has passed the stress test we can suspect that can be more appropriate a different approach than the traditional one.

• It's surely interesting that frequently there are some common characteristics that have projects that do not become a «black swan»

Black sw

an m

anagem

ent

Are framed as business projects and not only as a technological projects

Large projects are broken into smaller sub-projects and anyhow well modularized

You need to give yourself an organization to coordinate and manage conflicts and overlap among projects and deal with emergencies

These are some of the key characteristics of

Service Oriented Architectures (SOA),

Enterprise Architecture (EA) and Interoperability

Framework

• IT projects are stratified accidentally, the knowledge is fragmented and dispersed among various people and different, not updated, documents

«We don't really know what has been done»

• Business processes are not well known and only partially documented in various ways and frequently defined only by consuetude

«We don't know how the things work»

• The boundaries of responsibility are unclear and are dispersed among different actors

«We don't know who is doing what»

• The changes (new systems, new processes and organization) are decided but impacts are often not measured and therefore we are not able to assess any progress and make adjustments

«We don't even know if we improve»

• Now let's step back.

• First we should consider that frequently the reality starts from context like this:

“welco

me in

the real w

orld

"

The ven

erable trad

ition

al app

roach

• Moreover healthcare space has an high

intrinsic complexity. We have many actors in many different cooperating organizations, information complexity, process complexity (sometime in an ad hoc structure) and plenty of legacy systems at work.

• Paradoxically this strengthened the traditional approach of the old informatics

Integration

requirements

task

Integration

Application

Application

generates

“spaghetti integration”

Application

ApplicationApplication

Application

Application

Application

We have in any case:

Identification of task/integration to be automated

Task Requirement definition

Realization of an application and/or an integration to automate a specific task or a process segment.

Spagh

etti • The integrations is created with a

“point to point” based mindset (resulting in a “spaghetti integration”).

• EAI and middleware approach are attempts of a technological solution but the design approach is an invariant.

• Also the practical use of standards, frequently, is simply inserted into this logic.

• Frequently, even if we speak of integrated systems, SOA and so on, in our practical behavior we use the traditional use case by use case approach

• Moreover must be stressed the point that this is independent from the dimension of the project.

Wh

y sho

uld

it wo

rk?

• On the other hand, the tendency has often been to make the projects as large as possible under the illusion that this simplifies the integration and makes the system more cohesive

• Otherwise this is only a way to make the complexity unmanageable

• At the end of the day, why should it work?

As HL7 people we are happy for the use of CDA Implementation Guides and standard messages but it’s not enough

Without an effective design of systems of people and technology, the result is at very high risk

A d

esign Issu

e

• Clearly what we can see is not a technology issue, but a design issue and we can identify a couple of relevant aspects of the traditional approach:

• The intertwining between technical details and business requirements

• The design is, in the practical behavior, only at application level. The enterprise system, as a whole, is not a part of the game

«The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate.»

The Law of Requisite Variety W. Ross Ashby

# %

Data Warehouse 16 0 0 0%

Administrative System 268 157 119 44%

Resource Management 108 78 63 58%

Document management 40 40 18 45%

Booking System 133 126 125 94%

Ambulatory Management 37 41 22 59%

Health Reccord Management 161 90 81 50%

Prevention System 182 169 88 48%

Totale 945 701 516 55%

# %

Data Warehouse 29 0 0 0%

Administrative System 39 12 12 31%

Resource Management 25 16 11 44%

Document management 13 2 2 15%

Booking System 16 11 11 69%

Ambulatory Management 7 3 3 43%

Health Reccord Management 67 25 25 37%

Prevention System 49 4 4 8%

Totale 245 73 68 28%

Components

Functional Requirements

TenderDocument

ed

Covered Req

Components

Integration requirements

TenderDocument

ed

Covered Req

A «

bla

ck swa

n»

• Below an example from a real eHealth project with a budged of 20 million of euro

55%

28%

Clearly the project is

out of control

• We can use technical standards (messages, documents, webservices and so on) but we do not use methods and standards for designing and governing systems (systems, not only applications)

• No reference architecture

• No functional and services models (SOA)

• No Interoperability and Enterprise Architecture frameworks

• We should not speak only about computers but we should speak about systems composed by technology and people

The Stairw

ay to H

eaven

«The HL7 Stairway to Heaven»

Agree on common Framework as Reference

Agree on Conceptual view

Agree on Logical view

Agree on Implementable view

Co

mp

on

en

t

Co

mp

on

en

t

SAIF

• The HL7 SAIF (Services Aware Interoperability Framework) can help us to better understand our focal point

• In general, SAIF is as an adjunct to an existing (or planned) Enterprise Architecture frameworks

• SAIF is focused on the various dimensions and perspectives associated with achieving a predictable, scalable, and effective interoperability among the various components that collectively populate an enterprise architecture.

• The SAIF Interoperability Specification Matrix (ISM) defines a matrix that distributes the multiple aspects of a given component’s specification across the various cells of the matrix.

HL7 SAIF ISM

Business (basically computational indipendent)

Achitecture artifacts (basically platform indipendent)

Development (basically platform specific)

Pe

rsp

ect

ive

Dimensions

• Frequently the missing piece in our specs is the weakness of the first two perspectives

• For a classical application silos the issue seems not so serious. However in a complex system we should compose several components and we should make complex decisions about technology

• Again, a real system is more than a progressive task automation: “use case by use case”, “task by task”.

Missin

g pieces in

IT pro

jects

often, at most,

we are here

“The system IS the Enterprise” (John A. Zachman)

Sho

uld

IT be a b

et?

EA Framework (es. Togaf)

• As an example, a set of components specified with SAIF are consistent among them and can really take part in a design process at enterprise level

• Frameworks lead architectures to consistency and more rational decisions

• As the reality of «black swan» has shown us, the alternative are several catastrophic risks.

• The eHealth is complex enough in itself so probably, it’s a bad idea to continue to transform IT in a bet

SAIF an

d Im

plem

entab

le persp

ective

• Below an example of the use of SAIF framework for implementation paradigm analysis taken from HL7 XParadigm project (Cross-Paradigm Interoperability Implementation Guide for Immunizations)

• The technology aspects are pushed down to a pure technical level and the compliance of each paradigm can be mapped on a common conceptual and logical model. This is useful also for environments where different paradigms coexist.

con

clusio

ns

14/05/11

• What emerges in our discussion is the lack of attention in design

• We have methods and frameworks and these are essential tools for the management of complexity

• However our mindset must change

• We must really accept that we live in a technological society

• Information Technology is not a support for organization

• Information Technology IS the organization jointly with people

• Otherwise the «black swans» will emerge

• The change of our habits will not happen naturally … on time