Presentation by Paul Valckenaers and Patrick De Maziére during the workshop Interoperability defined by its reason d'être by Paul Valckenaers - AAL Forum 2015

1. Interoperability
defined by its reason d’être
Paul Valckenaers and Patrick De Maziére
Paul.Valckenaers@ucll.be

2. 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’).

3. The team
• Paul Valckenaers, UCLL, Paul.Valckenaers@ucll.be
• Bart Haex, KU Leuven, Bart.Haex@kuleuven.be
• Joan Van Loon, IBM, Joan.van.loon@be.ibm.com
• Patrick De Mazière UCLL, Patrick,DeMaziere@ucll.be

4. 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
 …

5. 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
• …

6. 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.

7. 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

8. 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

9. 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

10. 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

11. 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.

12. Interactive session 2
• Real world resources
 Organs
 People
 …
• Real world activities
 Therapy
 Travel
 …
• Real world interactions
 Multi-pharmacy
 …

13. 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).

14. 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