Interoperability defined by its reason d'être
-
Upload
aalforum -
Category
Healthcare
-
view
159 -
download
2
Transcript of Interoperability defined by its reason d'être
Interoperability defined by its reason d’être
Paul Valckenaers and Patrick De Maziére
Overview
• Introduction: What is interoperability expected to deliver?
• Interactive: small groups compile a use case/example.
All (15’) – organisers coach the groups. • Use case presentations:
Group speakers (3’ each) • Presentation:
Design for the unexpected and interoperability • Applying design for the unexpected to use cases:
All (15’) – organisers visit groups and collect info • End of session (5’).
The team
• Paul Valckenaers, UCLL, [email protected]• Bart Haex, KU Leuven, [email protected] • Joan Van Loon, IBM, [email protected]
• Patrick De Mazière UCLL, Patrick,[email protected]
What is interoperability expected to deliver? • Commonly assumed / expressed :
“Plug and play” Achieved by means of a “connector” Or by complying with a “standard”
• Fact: this is only a matter of (not a lot of) time provided that: It is possible (without redeveloping …) There is sufficient demand (i.e. there is a market) We enjoy a relatively conflict-free situation …
What is interoperability expected to deliver? • Implicitly assumed :
Potential of what is available• Resources (finite, access rights, …) • …
Coordinated activities, interventions• Activities • Interactions through resources • Orchestrated interactions • …
Interactive session 1 Propose and select a (few simple) use case(s)
from your own experience
Identify the resources, including embedded within … Identify the services/tools/… to execute
activities on those resources
Assess the accessibility of the resources Assess the ‘program-ability’ of activities and interactions
Compile a short presentation.
Design for the unexpected and interoperability • Scientific laws or universal principles for the
artificial H. Simon: Flexible (aggregation) hierarchies Origin of life: Autocatalysis …These scientific laws follow from bounded rationality
• Design for the unexpected Design choices introduce constraints Repeating design choices builds up inertia Incompatible constraints cause an inherent
inability to interoperate effectively• E.g. an interoperability standard incompatible with reality
Autocatalysis and the Valley of Death
• Ratio of User mass Complexity of the artefact
• Two types of self-reinforcing Economic ($$$, €€€): paying customers Information: active users, in a variety of manners
• For all services offering “programmability” Either (very) simple Or “mainstream” Or “decisive features” and …
• In the VoD: many of de jure but not de facto standards
Design for the unexpected: Resources
• The real world is coherent and consistent• Real-world resources …• Suitable models reflecting real-world resources …
“It is possible” This always will be “the case” / true
• Ensure/manage access/ownership (also for embedded resources) Explicit and mandatory resource allocation
• Over time (a reservation service?)• Accounting for state (transitions)
• Programming features/services stay outside the VoD !!!
Problem domain is stable; user requirements not at all
Design for the unexpected:Activities
• Again: real-world reflection > “it is possible” Preserve the inherent solution space (observe and maximize)
• E.g. robustness in large flexible systems (MIT, axiomatic design) Manageable solution space for decision-making (must be clever)
• Do not bundle with resources VIP architecture: activity has a butler making arrangements with …
• Stay out of VoD Programming services / features
• Interactions Through resources – provides independance Proactive (beyond the current discussion)
• SSOT and the D-MAS architectural pattern
Interactive session 2 Revisit your results from session 1 What changes? What issues are recognized?
Identify real-world resources and their counterparts in the ICT domain.
Idem ditto for activities and interactions How “invariant” are they? Foundation for lasting
developments? Improvements instead of replacements?
Organisers take notes for reporting.
Interactive session 2
• Real world resources Organs People …
• Real world activities Therapy Travel …
• Real world interactions Multi-pharmacy …
Discussion
• Interoperability is more than Data model Communication Standards
• It is about (absence of) constraints• It is about low inertia (undo) of constraints• System architecture and architectural patterns
Provide the “it is possible” Allow reality (the world of interest) to be visible in the IT
• The science behind it (next slide).
Design for the Unexpected, 1st Edition
From Holonic Manufacturing Systems towards a Humane Mechatronics Society Paul Valckenaers,Hendrik Van Brussel
Expected Release Date: 02 Nov 2015
Imprint: Butterworth-Heinemann
Print Book ISBN : 9780128036624