Interoperability defined by its reason d'être

Interoperability defined by its reason d’être

Paul Valckenaers and Patrick De Maziére

Paul.Valckenaers@ucll.be

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

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