Interoperability is about:

Transcription

1

2 2

3 Interoperability is about: Two (or more) independant organizations (enterprises, governmental bodies, divisions, departments, ) Without any common or shared authority and governance With independent and potentially incompatible architecture governance frameworks With a need (desire, obligation, necessity, stake, ) to collaborate by means of independently purchased/developed automated systems Without a prior agreement how to do that Applicability examples: two (semi-)public organizations in different countries with a common or similar or related mission; service orientation using ad hoc third parties; incident response involving multiple organisations by coincidence; due diligence before merger or takeover; 3

4 Governance Domain A Architecture Governance Framework of A Manages Enterprise Architecture of Domain A Consists of Architecture building blocks defined in Architecture Continuum A Governance Domain B Architecture Governance Framework of B Manages Enterprise Architecture of Domain B Consists of Architecture building blocks defined in Architecture Continuum B Implemented by Solution building blocks in Solution Continuum of A Implemented by Solution building blocks in Solution Continuum of B Interoperability Requirement 4

5 Human Individual A Code of ethics / religion / cultural background of A Manages Human Individual B Code of ethics / religion / cultural background of B Manages Personality / character / behavioural capabilities of A Consists of Inherited, acquired and educated (communication) skills and abilities of A Personality / character / behavioural capabilities of B Consists of Inherited, acquired and educated (communication) skills and abilities of B Implemented by Behaviour and communication patterns exhibited by A Implemented by Behaviour and communication patterns exhibited by B Interoperability Requirement 5

6 Interoperability No common authority to impose standards Need for mutual contribution to business process Need for unambiguous information exchange Mutual content oriented addressing Communication Imposed or obvious common standards Optional contribution to mutual business processes Ambiguity in information exchange can be solved later External addressbook available 6

7 7

8 Integration of authority distributed organisations 27 Member States, 23 Official languages (sofar) 27 legal frameworks 27 implementations of European guidelines citizins [2007] (?) businesses (?) civil servants local governments (Eurostat, 2005) (est.) other public institutions Integration of geographically European level National level distributed locations Regional level Source: eurostat Local level Lots of legacy systems in all public institutions and governmental agencies Democratic authority prevents imposition of rigorous standardisation Many initiatives and point-to-point solutions Ongoing harmonizations efforts slowly drive towards an ever changing convergent landscape (PHEPA, TEN4HEALTH, epsos, HITCH, EHIC, ) 8

9 document/3473/ document/3760/5585 9

10 10

11 Three different contexts in which interoperability has to be modeled: The (traditional) ICT context describes how information systems owned by different organizations can interoperate, using a layered (OSI like) interaction model The administrative context describes the interoperability governance across enterprises for different classes of objectives The policy context describes how legislation determines what must, can or cannot be done in terms of enforceability, civil rights and legislation (also using a layered model) across jurisdictions 11

12 Procedural layer (process layer) ensuring that information that has to be shared and is correctly understood can be properly acted upon (legislation, objectives, priorities, resources, retribution, deeds) Semantic layer ensuring that information that has to be shared and is correctly read can be properly understood (context specific metadata, ontologies, taxonomies, masterdata) Technical layer (syntactic layer) ensuring that information that has to be shared and is correctly received and recognised can be properly read (characterset, syntax, data formats, currency, units, presentation language, etc) Media exchange layer ensuring that information that has to be shared can be properly received and recognised (internet, memory cards, CD s etc) The technical interoperability layer handles The procedural interoperability layer all The generic network transformations and media interoperability that are needed The handles Semantic all process Interoperability adaptations layer that handles are in covers order all properly what has read to messages be specified in the all necessary context specific to be able transpositions to process that are transmitted technology by architecture a system deliverables from the external necessary messages to in properly a collaborative understand context. the This domain. (Phase D These of TOGAF) transformations in order to generally ensure information ensures that that all is state meant changes, with any necessary data are that specific data can to be the sent systems and received that need to exchange as a result between of co-operation interoperating between interoperate properly the but technical are independent sense. Today of the enterprises. systems in different The need enterprises for information are business most organizations processes are and connected objectives to as part exchange coordinated is mostly across identified systems during of different the of internet, which transmission and that solution was therefore initiated. The solves elaboration enterprises. of In the order Business to be able Architecture to handle following very often transformations most of the requirements. frequently occur: (TOGAF the collaboration phase B). process, specifications Alternatively, * Change of character or in addition, set and specifications code page In must order be to defined be able for: to handle semantics, for Transformation the use of physical of time-zone media, like data, CD's, e.g. specifications * The states must of all be systems defined involved for: with between DVD's, memory US-time sticks, and European-time memory cards, etc. the * The achievement meaning of of any compatible vocabularies objectives and may * Conversion be part of between the architectural metric and nonmetric requirements. data The requirements their across content enterprises to be used in the exchange of data * The (characters information and/or that symbols must be in available a given specification Conversion must of currency. include the This following: conversion language) in each system and must be synchronised is * usually type of done communication public rates infrastructure applicable or at in * The order meaning to achieve of any a compatible data values objective that can the physical moment media of conversion that can be in used the technical occur * The in governance certain types principles of data exchanges by which layer. mechanisms For Forex to trade address operations the other of banks party, information * The meaning relevant of any to relations collaboration implied is or this in case type of of internet conversion most is often not usable, the DNSconventions, transmit and amounts applicable as fixed URL's; decimal in they expressed managed, as in particular of data the exchanges Master / slave instead relation * The meaning of each of information any classifications element of numbers, case of physical and apply media conversion any logistic outside the data involved implied in collaboration. or expressed Many as part of data realm requirements of interoperability. exchanges organisations implement a Master Data * Mapping naming conventions of language and specific physical Management * The identification strategy of any as part business of their rules alphameric labeling practices data using that predefined apply order to that overall may information be needed governance. to bridge mismatches vocabularies identify the proper disc, memory card, file, between dissimilar data port * Chopping or whatever. and concatenation of data The * The detailed establishment requirements of a context for Procedural and/or * Checksums security requirements and certificates (login to protect domains Interoperability that modify are usually or qualify derived any meaning from data parameters, integrity handshake, certificates, inherent the Busines data Architecture as part of phase firewall * Transposition restrictions) of tables B * Security of TOGAF. attributes Successful of any Semantic data implied or * Reformatting (handling of) shared of structured secrets data in order to involved Interoperability in interoperability is a prerequisite for setup * Syntactical secure connections conversion into when different applicable Procedural Interoperability. syntax standards 12

13 13

14 Procedural layer (process layer) ensuring that information that has to be shared and is correctly understood can be properly acted upon (legislation, objectives, priorities, resources, retribution, deeds) Many attempts around but no universally adopted generic solution that covers all. Many partial solutions are premature pending global adoption of a universal solution for semantic interoperability Semantic layer ensuring that information that has to be shared and is correctly read can be properly understood (context specific metadata, ontologies, taxonomies, masterdata) Many attempts around (HL7, LOINC, SNOMED, EN ) but no universally adopted generic solution that covers all. Focus of many initiatives, including wasted efforts, however a promising standard based on ISO 11179: UDEF Technical layer (syntactic layer) ensuring that information that has to be shared and is correctly received and recognised can be properly read (characterset, syntax, data formats, currency, units, presentation language, etc) Media exchange layer ensuring that information that has to be shared can be properly received and recognised (internet, memory cards, CD s etc) Problem solved by general availability of various middleware solutions. Still dependant on implementation by professionals. Much legacy around that predates generic solutions Problem solved by pervasive use of internet, USB, SD-cards etc Performance improvements anticipated and desired Commoditized for all people > 5-10 yrs 14

15 UDEFs unique Value Proposition Traditionmal Point-to-Point Approach --- n(n-1) UDEFs Global Canonical Standard Approach --- 2n Global Canonical Standard Savings First version published in 2006, continously being extended Multilingual capability first introduced in 2008 Latest version 1.25 (October 2011) Satellite vocabularies approved (February 2012), due to be published as version

16 Object Class Property Representation Data Element Concept Data Element Value Domain Core Data Element Application Data Element 16

17 Syntax Same data definitions Reproduceable interpretation rules Apply to data elements Are language independant (although defaults may be different from country to country) The characteristics that are compressible (Shannon) Syntax errors can be enumerated Semantics Different data definitions Context dependant interpretation rules Apply to data element concepts More often then not convey language/culture specific connotations The characteristics that are the essence (Kolmogorov) Semantic errors can be classified 17

18 Will this Address be Found? Field name Address stored Address requested First name Johann Wolfgang Johann-Wolfgang Last name Goethe Göthe Name extension von Birth day 00/00/ /12/1913 Place of residence Frankfurt (Main) Frankfurt/Main ZIP code Street Schiller Straße Schillerstrasse Street number 24 A 24a Different syntax, different characterset (code page) Same concept, same business object, same classification No relevent understanding of business context required to enable correct mapping 18

19 Field name Address stored Field name Address requested First name Johann Wolfgang Name Dr J.W. Göthe Last name Goethe Address Schiller Str 24A Name extension von City Frankfurt/Main Birth day 00/00/1913 State Place of residence Frankfurt (Main) Country Deutschland ZIP code Telephone (+49) Street Schiller Straße Street number 24 A Different concept classification Different metadata Will this Address be Found? Some understanding of business context may be required to enable correct mapping External knowledge can be applied to validate the match 19

20 Entity UDEF Naming Convention Enterprise B Product Resources Basic Objects Applicable to Any Enterprise 20

21 UDEF Naming Convention ebxml UDEF Property Agreement on Basic Data Types is Fundamental to Interoperability 21

22 UDEF Object Class List (1318) o Entity o Document o Enterprise o Place o Program o Product o Process o Person o Asset o Law-Rule o Environment o Condition o Liability o Animal o Plant o Substance o Event Object Class Term 0...n qualifiers + 1 or more required Object Class Data Element Concept Name Example UDEF-Based Data Element Concept Names Document Abstract Text Enterprise Name ISO/IEC Naming Convention Product Price Amount Product Scheduled Delivery Date + Engineering Design Process Cost Amount Patient Person Family Name Property Term 0..n qualifiers + 1 required Property Patient Blood Body Substance Glucose Concentration Measure Property List (1443) o Amount o Code o Date o Date -Time o Graphic o Identifier o Indicator o Measure o Name o Percent o Picture o Quantity o Rate o Text o Time o Value o Sound o Video UDEF names follow the rules of the natural language -- each language has its own syntax rules UDEF is currently (version 1.25) available in EN, NL and FR; more languages are being developed 22

23 John Smith In OWL you can say That person is called John Smith This data field contains John Smith This data field describes that person In UDEF you can say This data field contains the name of a person The UDEF is Less expressive than an OWL ontology Simpler and easier to use The UDEF can be represented in RDF To enable automatic reasoning when linked with OWL ontologies 23

24 When a data element concept is not adequately addressed within the current UDEF, follow the procedures in the UDEF Extension Guide 24

25 Many knowledge domain specific concepts not modeled Open Group lacks in depth expertise in many knowledge domains Open Group only models vendor neutral data element concepts Many enterprise specific concepts not modeled Individual enterprises would want to model certain areas differently Governance process not agile due to quality procedures Some required extensions do not exist in other languages Enterprises want to try some extensions now UDEF assumes the context of an Enterprise for all data to be modeled For some required concepts the enterprise concept is not known, not applicable or not relevant Enterprises want flexibility to describe data in multiple contexts UDEF is public domain in its entirity Sometimes the understanding of data conflicts with security requirements The solution: Distributed UDEF UDEF 25

26 Not the same data element concepts in different trees Not a replication of what already is in UDEF Not an unlimited freedom to use some of the UDEF principles with a different flavour of your own choice Not (yet) a complete and ultimate solution for universal semantic interoperability Many more data element concepts not modeled in UDEF today or in future The possibility to define data element concepts in some other context than a generic enterprise Full integration of UDEF / DDEF definitions in an integrated semantic environment A major step forward to overcome the hurdles of universal semantic interoperability 26

27 The Vision: The UDEF-semantic infrastructure will be a distributed set of registries (like the DNS) each managed by its own registrar, using common standards and common and collaborative, partly shared, governance processes. The global (root) UDEF-registry is managed and maintained by the Open Group, who as well has the authority to assign registrars of descendant registries and the authority to define the governance processes. Every system owner can freely use the UDEF on a royalty free basis and can submit extension proposals. Future extensions of the UDEF trees, including descendant registries will enable all systems around the world the exchange data in a semantically consistent manner, without requirements for system managers to make any prior arrangements beyond being UDEF-compliant. National language versions of UDEF extend this vision across language barriers 27

28 Aerospace example B Commercial.Aircraft_Scheduled.On-Arrival.Landing.Weight.Measure A380-Compliant.Docking-Position_Departure-Gate.Identifier Mining example Natural-Gas.Offshore.Well_Production.Performance.Measure Yellow-Cake.Mining-Product_Radiation-Level.Measure Healthcare example Blood-Pressure-Monitor.Measuring.Medical-Equipment_Systolic.Blood-Pressure.Measure Limbal.Stem-Cell.Disorder_Clinical-Finding Energy example Geothermal.Energy.Production.Plant_Operation.License.Expiration.Date High-Voltage.Powerline_Length.Measure Telecommunications example Option.Bundled.Offering.Product_Activity.Indicator 3G.Radio-Coverage_Density.Measure Disaster response example Emergency.Hospital-Service_Nearest.X-Ray.Distance.Length.Measure Earthquake.Event_Ground-Zero.Longitude.Measure 28

29 UDEF Object Class List o Entity o Document o Enterprise o Place o Program o Product o Process o Person o Asset o Law-Rule o Environment o Condition o Liability o Animal o Plant o Substance o Event Public Domain / Knowledge domain specific ISO/IEC Naming Convention Object Class Term 0...n qualifiers + 1 or more required Object Class Data Element Concept Name + Enterprise specific Property Term 0..n qualifiers + 1 required Property Property List o Amount o Code o Date o DateTime o Graphic o Identifier o Indicator o Measure o Name o Percent o Picture o Quantity o Rate o Text o Time o Value o Sound o Video Public Domain / Knowledge domain specific SDEF object class list Aerospace o Aircraft o Spacecraft o Airportequipment o Aviation supplies o etc tbd SDEF object class list Medical o Medical equipment o Medical Supplies o Observations o Medical conditions o Medical Staff o Etc tbd SDEF object class list xxx o o o PDEF object class list Capgemini o Employee o Skill o Portfolio o o Etc tbd PDEF property list Capgemini o KPI o o o Etc tbd SDEF property list Aerospace o In flight supplies o o Etc tbd SDEF property list Medical o Health o Treatment o Treatment response o Anatomy o o Etc tbd SDEF property list xxx o o o 29

30 Aerospace Healthcare Telecom-Media AIA SNOMED HL7 EN13606 Tmforum s SID How Knowledge Domain specific initiatives can benefit from UDEF: Enabling interoperability with other domains Separation of meaning and representation Transcends language barriers Enables interoperability across different vocabularies and knowledge domains Unlocks UDEF tools to explore semantics How UDEF can benefit from Knowledge Domain specific initiatives: Extends scope of applicability to specific knowledge domains Accelerates the extension process to include additional data element concepts Provides additional context and examples to develop solutions for other semantic conflicts Enhances the business case for early adopters (networking effect) 30

31 The Open Group retains responsibility for the root UDEF trees UDEF-tree connectors Descendant tree Potential candidate descendant tree registrar Potential candidate descendant tree registrar Descendant tree Connectors represent root of descendant tree in parent tree Root concept in descendant tree matches extension position in parent tree Root of descendant tree and connector in parent tree are aliases whenever the context of the parent tree applies Descendant tree registrar has received accreditation by parent registrar Concept domain of descendant tree agreed with parent registrar Parent registrar defines roots of descendant trees; descendant registrars define branches in their trees 31

32 Combine any object tree with any property tree ISO/IEC Naming Convention Data Element Concept Name Multiple trees collaborate in a single governance framework UDEF object SDEV object PDEV object SDEV-extended UDEF object PDEV-extended UDEF object PDEV-extended SDEV object Object Class Term 0...n qualifiers + 1 or more required Object Class + Property Term 0..n qualifiers + 1 required Property UDEF property SDEV property PDEV property SDEV-extended UDEF property PDEV-extended UDEF property PDEV-extended SDEV property Registry switching allows to combine different vocabularies on the fly, even within a data element concept UDEF object + SDEV property UDEF object + PDEV property SDEV object + PDEV property SDEV object + SDEV property SDEV object + UDEF property PDEV object + UDEF property PDEV object + SDEV property PDEV object + PDEV property 32

33 UDEF 1.25 formally approved and published (English, Dutch and French) UDEF 1.30 approved (soon to be published) (English, Dutch and French) UDEF 1.31 extension proposal being prepared for review German, Chinese, South-African and Spanish UDEF versions being Developed; Italian, Greek, Polish and Bulgarian versions planned Pilot key vendor(s) & end user(s) Training Baseline UDEF in usable form Controlled extension process Ready Started Launch Demonstrated benefits Support by key vendors (IBM, SAP, Oracle..) Early adopters use the UDEF Distributed UDEF Electronic Health Record, Homeland Security Promotion All enterprises use the UDEF UDEF in other languages 33

34 34

35 35

36 Contributors: Ron L Schuldt, UDEF-IT Chris Harding, The Open Group Contact: arnold.van.overeem@capgemini.com 36