ihic 2012 - key note - hl7 italia - s.lotti - is it really useful to have a framework?
DESCRIPTION
S. Lotti Key Note at 13th International HL7 Interoperability Conference, September 27 – 28, 2012 in Vienna, Austria.TRANSCRIPT
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