Fundamentals in Interoperability Lectured by: Ricardo Gonçalves
Course Structure • • What is Interoperability? Interoperability Problems Analysis of requirements and Piloting Solutions for Interoperability – In the area of Enterprise Modelling • Enterprise Modelling in the Context of Collaborative Enterprises • Cross-Organisational Business Processes – In the area of Ontology • Knowledge Support and Semantic Mediation Solutions – In the area of Architecture and Platforms • Application Planned and Customisable Service-Oriented Architectures • Model-Driven and Adaptive Interoperability Architectures • The Interoperability Framework • Conclusions 2
Section 1 What is Interoperability? 3
Holistic Approach to Interoperability Enterprise systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations – European Group for Research on Interoperability, 2002 • – Business layer: business environment and business processes – Knowledge layer: organisational roles, skills and competencies of employees and knowledge assets – Applications, data and communication components – Semantics: support mutual understanding on all layers Interoperability (Def) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged” – IEEE Standard Computer Dictionary, 1990 Enterprise A Business Knowledge Application Enterprise B Business Knowledge Application Semantics To achieve meaningful interoperability between enterprises, Interoperability must be achieved on all layers: • Semantics • Data Communication 4
Motivations • There is an abundance of technical solutions and standards, but implementations: – are far from pervasive – are more often than not isolated efforts and lack interoperability • Business drivers for increased collaboration between enterprises: – – – • Processing cost reduction time to interoperability optimization focus on core competencies flexibility to engage in partnerships and seek business opportunities leverage IT investments Interoperability There is a need – to go back to the technical basics of what enables business practices in a given context – to re-evaluate interoperability problems – to re-assess the models and value propositions of ecommerce businesses – to build industry confidence and buy-in Processing 5
Economic and technical dimension Interoperability Capability of IT systems to exchange and use information Technical Dimension Economic Dimension „Business Interoperability“ 6
Analysts’ Perspective 30% of the entire IT budget is spent on building, maintaining, and supporting application integration (Forrester, 2003) 61% of CIO’s consider integration of systems and processes a key priority (CIO Magazine, 2003) US$29 billion by 2006 for application integration by IT professional services (Gartner Group, 2003) 7
Lack of Interoperability: Impact Limited Access to Valuable Business Relationships Limited Bargaining Power Cost Disadvantage Opportunistic Behaviour Sub-optimal Integration Level Lock-In Relation Specificity High Integration Costs Lack of Interoperability 8
Potential benefits of Interoperability IT Benefits Strategic Benefits Lower Integration Costs Increased Stability Lower Operational Costs Less Time effort More Bargaining Power on suppliers Broader Access to Suppliers Direct Integration with Customers Integration with e. Markets 9
Interoperability: A Strategic Vision Objective: Concentration on Core Competencies Virtualization Outsourcing Vertical Integration Prerequisite: Lower Transaction Costs 10
Section 2 Interoperability Problems 11
Interoperability Problems: Scenarios and sectors • 4 different scenarios and sectors are going to present their interoperability problems – Supply Chain Management Aerospace – Collaborative Product Development Automotive – Product Portfolio Management Telecom – e-Procurement - Furniture • These scenarios are represented in 2 situations: – AS-IS situation: Where a description of the current scenario is given. – TO-BE situation : Where a description of the future and desirable situation of the scenario is foreseen Telecommunication Interoperability Aeronautics Furniture Automotive 12
Scenario 1 Supply Chain Management 13
Supply Chain Management (SCM): Aerospace • Collaborative Product Development in a Virtual Networked Enterprise – Industrial sharing of the design between numerous partners – Management and Integration of all the Product Data, all along the lifecycle – Piloted by Change Management, eventually supported by workflow engines – Technical information sharing and exchange between heterogeneous tools of the partners 14
Demonstrating scenario • Establishment of a collaboration environment between the Aeronautic integrator and the other design partners based on : – Cooperation process : Change Management process interconnecting local change process of each partner – Shared PLM services based on standards (OMG PLM services and PDM Enablers) – Shared Product Data, with standardized formats (ISO STEP manufacturing ontologies) 15
Scenario 2 Collaborative Product Development 16
Collaborative Product Development (CPD): Automotive • Rapid economic scenario changes and short time in response to diverse markets demand throughout the supply chain • Suppliers involved in collaborations with different customers should necessary adapt their system to guarantee compatibility with different non-standard protocols of each customer. • Lack of synchronization between OEM and Suppliers processes • The speed of data flowing through the supply chain is slow • Suppliers often use outdated information to guide design. 17
Scenario 3 Product Portfolio Management 18
Product Portfolio Management (PPM): Telecommunications • PPM is a process involving decisions made at different levels, whereby the list of active product development projects is constantly updated and revised. • Main Processes Involved – – – • New product Development Product Management Project Management Support Activities Resource Management Quality Management Main Actors – – – – Business Unit Manager Business Development Manager Product Manager Project Manager Team Manager Engineer Quality Engineers 19
PPM requirements for interoperability • The focus is on intra-enterprise level – Collaboration of various teams inside the same business unit or corporate environment – Efficient support of users in various positions and with different roles – Relevant data and information needed by the PPM participants are spread across several systems. • Requirements for information coming from sales and marketing, project execution, as well as from product operation (MOL) • Knowledge intensive process: – strategy and objectives – skills and competences – experience coming from previous projects • Many different aspects of interoperability to be covered – Business aspects – Knowledge Aspect – ICT aspects 20
PPM - The as-is situation 21
PPM - The to-be situation 22
Scenario 4 e-Procurement 23
e-Procurement: Furniture • Actors: furniture manufacturer, raw-material supplier, retailer and customer • Deals with the document flow of the buying/selling processes: Quotations, Orders, Invoices, Delivery notes – Furniture product list, descriptions and special specifications – additionally, inclusion of an interior Decoration Project • Till now – Manual management of the documents – Hard-copy transfers • Desired – Automated management of the documents – Electronic copies • Possible errors produced in the daily activities – configuration errors, missing information, non-legible characters, … 24
Selling Process: Customer oriented scenario RETAILER R 1. Request for Quotation R 2. Quotation R 3. Order Delivery Interior Decoration Project R 4. Order Confirmation Customer communication Looks for furniture Delivery Invoice R 5. Delivery Note R 6. Packing List MANUFACTURER R 7. Invoice 25
Procurement Process: Supplier oriented scenario PROVIDER M 1. Request for Quotation M 2. Quotation M 3. Order M 4. Order Confirmation Delivery M 5. Delivery Note M 6. Invoice MANUFACTURER 26
Section 3 Analysis of requirements and Piloting 27
Requirements: Handling, Research and Piloting • Objectives Scenarios – Register interoperability requirements – Influence research – Search for existing solutions – Experiment with pilots and prototypes – Through portal services on the web 1 Collect requirement Specific handling Requirements 3 Elaborate The Requirements 2 Collect Generic Requirements 6 Develop Generic IT Products research 4 Search for Generic Solutions 5 Develop Generic Solutions piloting 7 Develop Specific IT Products External World 28
The Handling • Based on the scenarios presented – Requirements – Extraction from scenarios • Collection of Generic Requirements • Elaboration of the Requirements • Upload requirements on DRDS – Dynamic Requirements Definition System Scenarios requirement 1 Collect handling Specific Requirements 3 Elaborate Requirements 2 Collect Generic Requirements External World 29
The Research: Search for generic solutions • Based on the Requirements • Search for Generic Solutions • Three domains – Enterprise Modeling – Architecture & Platforms – Ontology research 4 Search for Generic Solutions 5 Develop Generic Solutions 30
The Piloting • Take solutions and test the requirements • Based on fulfillment: – Develop Specific IT Products for each proposed scenario – Develop Generic IT Products for all scenarios 6 Develop Generic IT Products 5 Develop Generic Solutions piloting 7 Develop Specific IT Products 31
Visual Requirements Analysis • Requirements are classified according to features from the business, knowledge and technology levels • Requirements can be browsed by category • Search criteria help you identify related requirements, additional information and available solutions 32
Piloting and Testing • Utilize test beds to assess interoperability between – Your ICT systems – The ICT systems of your company and its business partners – The knowledge sharing and business interaction practices of the companies • It is promoted a model-driven approach piloting and testing – Model your joint enterprise, its business processes, organizational roles, the products and services exchanged and the underlying ICT infrastructure – Execute part and aspects of the model on the Interoperability testbed • Identify interoperability problems • Identify available solutions • Negotiate and jointly develop or customize local solutions yourself 33
Section 4 Solutions for Interoperability in the area of : - Enterprise Modelling - Ontology - Architecture and Platforms 34
In the area of Enterprise Modelling i - Enterprise Modelling in the Context of Collaborative Enterprises 35
Enterprise Modeling in the Context of Collaborative Enterprises Vision – “Collaborative Enterprises will be supported seamlessly by modeling during all life-cycles” • Objectives Partial Process Model (OEM View) – The discipline of Enterprise Modeling provides solutions to enable collaborative enterprises. – To this end, results will be delivered that can be summarized in a simplified manner as: • methodologies, core languages and architectures for enterprise model exchange (initially process oriented) and capturing missing enterprise knowledge and assets. • services for establishing Collaborative Enterprises. – A Collaborative Enterprise is an enterprise where teams work together across boundaries, e. g. life-cycle phases, sharing results and knowledge to improve common understanding and enable better performance and quality results. Sourcing Partial Process Model (Supplier View) Changes (external/ internal) Customer Order accepted Market trends Change accepted OEM Innovation Acquisition and offer generation Design order accepted Product Life Cycle Target Setting V • ARIS Model Technology predevelopment Concrete Product idea IEM Model Different aspects of the same process from different perspectives 36
Recognized Problems • Addressed problems – Incompatible Enterprise Modeling Platforms, Methodologies and Tools. • Too much time is needed to create a model, and when finished, it doesn’t reflect the reality in a proper way anymore. • The users of the models often have to deal with the problem that the models don’t fit their requirements, e. g. the model is not detailed enough or the level of formalization is not appropriate. • It is often not possible to use the modeling results to support the daily business of employees. The users often do not have the skills to read the models properly and to deduce the implications for their further work. Modelling each Enterprise Model exchange and merging Model establishment and maintenance Takes too long and is too expensive • What exists – Large amount of different modeling frameworks: ZACHMAN, ISO 15704, modeling languages, (to-be) standards: PSL, ISO 19440, methodologies: ISO 19439, IEC 62264, modeling platforms available and in use: (METIS, ARIS, MO²GO, GRAI Tools). 37
Results and Expectations • Results – EM model exchange – The MGWP is an application that provides a model based flexible front-end for supporting the daily business of people in different roles in the enterprise, according to the collaboration processes (e. g. operating a process or manage and control a process). • Establishment of Enterprise Modeling Establish POP* will enable enterprises to interchange enterprise models among different Enterprise Modeling Tools. • MPCE (Modeling Platform for Collaborative Enterprises) will be a generic platform for collaborative modeling, layered architectures, and providing services to concurrently build, extend, adapt and manage platforms, meta-models and solution models. • Model generated Workplaces (MGWP) ment of E nterprise Modelling • EM m od el ex ch an ge es ac kpl or d. W te ra e gen l de Mo – The purpose is: » to improve the overall ability of the enterprise to interoperate with others. » to define the enterprise modeling approach to establish collaboration in an specific context. 38
In the area of Enterprise Modelling ii - Cross-Organizational Business Processes 39
Vision and recognized problems • Vision – “Enterprises are able to flexibly model and execute crossorganizational business processes by interweaving external public business process views of their internal private business processes to achieve interoperability and controlled visibility of heterogeneous applications. ” • Problems – Controlled external visibility of internal business processes for cross-organizational business processes – Turning implicit, hidden, and hard-coded business processes into explicit interoperable executable process models – Cross-organizational business process monitoring – Relating diverse business process specific terminologies, languages, and standards used in different industries – Linking process models supporting different levels of abstraction and user roles for the same business process 40
BPM Driven Interoperability Process Logic Business Process Management Configure, Coordinate, Collaborate, Integrate Presentation Logic User Interaction Business Logic Data Logic • Application Services and Components Execute Database Management Persist Present, Interact Use the process view approach to: – ensure the controlled external visibility of private business processes – turn implicit business processes into explicit interoperable business processes – support the linkage of internal processes to cross-organizational business processes • Business process modeling methodology: – supports process modeling from different perspectives (e. g. business analyst, IT consultant, IT specialist perspectives) – combines it with process view approach 41
Process View Approach CBP 1 CBP 2 CBP 3 CBP: Cross-Organizational Business Processes PV: Public Process Views PP: Private Processes AS: Applications and Services PV 1 PV 2 PV 3 PV 4 PV 5 PV 6 PP 1 PP 2 PP 3 PP 4 PP 5 PP 6 AS AS AS Organization A Organization B Organization C 42
Selected Process Visibility CBP Externally. Visible Processes Internal Processes Externally. Visible Processes CBP 43
Internal Architecture for CBPs Cross-Organizational Business Processes Internal Public Process Views Private Business Processes External Application Components with Embedded Private Business Processes Business Services including Core Stateless Services and composed / Orchestrated Stateful Services Database Application Components Business Services Application Components Database 44
Available Technologies • Business process modelling tools – supports the user in applying the above modeling method – supports different types of users: • companies that use a business process management system to automate their internal processes • companies that use hard-coded business processes • Business process enactment architecture – executes the cross-organizational business processes and links them to internal, private business process instances – monitors the cross-organizational business processes during execution 45
In the area of Ontology Knowledge Support and Semantic Mediation Solutions 46
Vision and Objectives • Vision – The objective is to provide Semantics-based solutions for solving interoperability problems driven by Semantic Annotation and Semantic Reconciliation. • Objectives Coop level Solution H L L H Diversity – Such solutions do not intend to Fax/Phone EAI completely substitute existing Custom approaches, but they should be used where they really can bring O(n 2) Cost additional advantages, also respect to the setup costs. 1000 EAI solution – Existing approaches work well in certain cases, but sometimes they 100 The semantic need a strong human intervention solution 10 (Fax/Telephone), they solve ad-hoc 100 Peers 10 problems (Custom solutions), they are not easily scalable (EAI). 47
Semantic Annotation: Framework • Semantic Annotation Athos Conceptual Model (e. g. , B – Semantic Ontologybased annotation is to give meaning to any Ontology Management System kind of resources (i. e. , BPs), in terms of the shared Reference Ontology. A* – Such an activity is a pre. Semantic Annotation System requisite for Semantic search and Reconciliation Rules Semantic Annotation Expressions (SAX) generation. Semantic Annotation Repository 48
Semantic Annotation: Multilevel methodology Description Lev 4 Full SA (OWL DL) Lev 3 The Annotation expression is a complex OWL DL expression. Ex: (for. All rel. Country. Code_is. Part. Of. (for. All Telephone_is. Part. Of. (for. All Contac. Info_is. Attribute. Of. Buyer))) intersection ( for. All rel. Area. Code_is. Part. Of. (for. All Telephone_is. Part. Of. (for. All Contac. Info_is. Attribute. Of. Buyer))) The annotation expression is built on SP previously identified and applying some abstract operators (i. e. , + ) Structured SA Lev 2 Path-based SA Lev 1 Terminology-based SA Ex: Buyer_BA. HContact. Info. HPTelephone. HPArea. Code + Buyer_BA. HContact. Info. HPTelephone. HPLocal. Phone. Number Users Knowledge Engineering Domain Expert/ Knowledge Engineering Is built a vector Semantic Paths (SP) using terms previous identified. Domain Expert (O. O. expert) Ex: [Buyer_BA. HContact. Info. HPTelephone. HPArea. Code, Buyer_BA. HContact. Info. HPTelephone. HPLocal. Phone. Number ] To annotate resource we use a vector of keywords (selected Business from the ontology terminology) people Ex: [Buyer, Telephone, Contact. Info, has. Area. Code, has. Country. Code] 49
Generation of Reconciliation Rules • Starting from Annotation Expressions, Reconciliation Rules (RR) are specified • RR represent a procedural way of transforming ground resources (i. e. , data) into ontology instances (forward transf. ) and vice versa (backward transf. ) • Complexity of the rules syntax is shielded by the ARGOS tool which is based on a set of rules templates. 50
Reconciliation: An example SW Appl A Semantic Reconciliation Engine (ARES) SW Appl B GB MS Sem Rec Rules Repos G MS C From C to B Forward Rec Rules SW Appl C Backward Rec Rules 51
Reconciliation: rule application SPLIT order. has_order. Header. has_buyer. Info. has_organisation. Info. has_contact. Person. has_name INTO Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_First. Name Purchase. Order_BOD. rel. To_Buyer. rel. To_Contact. Person. has. Part_Surname An instance of the e-Procurement order <ai: order rdf: ID="ex_e. Procurement_order_1"> <ai: has_order. Header> <ai: order. Header rdf: ID="ord. Hea_ID 1"> <ai: has_buyer. Info> <ai: buyer. Info rdf: ID="buy. Inf_ID 1"> <ai: has_organisation. Info> <ai: organisation. Info rdf: ID="org. Inf_ID 1"> <ai: has_contact. Person> <ai: contact. Person rdf: ID="con. Per_ID 1"> <ai: has_name>John Smith</has_name> Name. Splitting Transform Rule The e-Procurement order in the Ontology format <ro: Purchase. Order_BOD rdf: ID="ex_e. Procurement_order_1”> Name <ro: rel. To_Buyer> Splitting <ro: Buyer_BA rdf: ID=“buy. Inf_ID 1”> Rule <ro: rel. To_Contact. Person> Application <ro: Contact. Person_BA rdf: ID=“con. Per_ID 1”> <ro: has. Part_First. Name>John</ro: has. Part_Fir st. Name> <ro: has. Part_Surname>Smith</ro: has. Part_Su rname> </ro: Contact. Person_BA … 52
Possible Applications of Semantic services • • • Business Message Reconciliation Business Protocol Mediation Models Transformation and Mapping Semantic Searching and Retrieval Web Services Composition and Execution • Useful Semantic Services – – Consistency checking (absence of contradictions) Semantic matchmaking Semantic query and retrieval Semantic compatibility among resources (models, web-services, etc. ) – Transformation and Mappings, among conceptual models – Semantic reconciliation of information structures (and messages) – Semantic mediation of behaviours 53
In the area of Application and Platforms Planned and Customisable Service-Oriented Architectures and Model-Driven and Adaptive Interoperability Architectures 54
Vision and Objectives • Three main integration areas – Conceptual integration – Technical integration – Applicative integration • Vision – Enterprises are able to flexibly develop and execute interoperable applications based on model-driven development approaches to serviceoriented and adaptive software solutions. Conceptual Integration • Concepts • Metamodels • Languages • Model relationships Applicative Integration • Methodologies • Standards • Domain models Technical Integration • Development environments • Execution environments • Integrates principles of – Model-driven development – Service-oriented architectures – Adaptive architectures 55
Model-Driven Development (MDD) • Model-driven approach to system engineering where models are used in – understanding – design – construction – deployment – operation – maintenance – modification Model transformation tools and services are used to align the different models. • Business-driven approach to system engineering where models are refined from business needs to software solutions – Computation independent model (CIM) • – Platform independent model (PIM) • – capturing business context and business requirements focusing on software services independent of IT technology Platform specific model (PSM) focusing on • the IT technology realisation of the software services CIM Business Context Models Model transformation PIM Software Specification Models Model transformation PSM Software Realisation Models 56
Results and expectations • System aspects – – Information Service Process Non-functional System abstraction CIM PIM Business Viewpoint Code Specification Viewpoint • Integration dimensions System abstraction Generality Viewpoint Composition Time Model abstraction Product-line, Framework, Pattern PSM Enterprise Viewpoint Realisation Viewpoint – – – Generality In fo e ic ts As rma rv c pe tio ct n Se pe s s A - al Pr n n As oce No tio ts pe ss nc ec ct Fu sp s A System, Product M 0 M 1 M 2 M 3 Model abstraction State Object Component Evolution Service (Virtual) Enterprise Time Composition 57
Operational Vision on Interoperability • Company B Service Wrappers – Provides a standardised way of accessing and using services. A first version of the service wrapper will be based on Web service technology. • Company A Service Wrappers / Interoperability Management Evaluation & Negotiation – Evaluate and negotiate incoming service requests, make use of underlying infrastructure services, and direct requests to the appropriate service deployed on an execution platform. • Evaluation & Negotiation of Available Functionality (using – “Enhanced Registry” & “Broker/Negotiator”) Execution Environment – Concrete platform that is able to execute PSM models, e. g. BPEL, Agent, or Composed Service models. • Repository Service Interconnection Bus Existing Enterprise Applications Service Interconnection Bus – Provides middleware services for integrating the various execution platforms. • Legend – Green – existing (presumed) heterogeneous infrastructure – Yellow – service-oriented components – Blue – model-driven development and execution 58
Service Execution Framework Evaluation Composition Execution Legacy Applications Brokering . . . Service Mediation Platform Models Service Models JACK Composition Models Nehemiah Contract Models Brokering Tool Model Registry ARES Negotiation Interaction Other Company Publishing External Registry Wrappers Internal Service Interconnection Bus 59
The complete Integrated Execution Infrastructure 60
Section 5 The Interoperability Framework 61
Interoperability Framework and Services for Networked Enterprises • Vision – The Interoperability Framework will provide requirements profiles that are mapped to solution profiles, which can be instantiated to support specific user interoperability scenarios. 62
Research Guiding and Evaluation Cycle • • The research guiding and evaluation cycle connects the industrial and research activities. Refined Requirements Validation Scenario The requirements gathering and analysis are used in order to make the appropriate research to validate the results through different pilots. Research Requirements Analysis Pilots Methodology, Guidelines, Reference Architectures 63
The Interoperability Framework integrates technical research results used for further identification of research requirements integrates experience from prototypes and technology testing Conceptual Integration Applicative Integration integrates prototypes for a given profile Technical Integration used for technology testing based on profiles used for transfer of knowledge regarding application of integration technologies 64
The way to Interoperability. . . 65
Making Interoperability a reality Industry / Application Scenarios Business Interoperability Supply Chain Management Integration Research Activities The Interoperability Framework SCM Profile Collaborative Product Development CPD Profile e. Procurement e. Proc. Profile Portfolio Management PM Profile Scenarios represent user requirements - Govern scenario requirements - Define / Manage Profiles - Identify applicable research results Research results are (in)directly applicable / contributing to a profile 66
Section 6 Conclusions 67
Conclusions • Enterprise systems and applications need to be interoperable – – • To achieve meaningful interoperability between enterprises – • Interoperability must be achieved on Business, Knowledge, Applications and Semantics layers During this course, Interoperability problems were analysed in four different industrial sectors – • To achieve seamless operational and business interaction To create networked organizations Aerospace, Automotive, Telecom and Furniture The analysis of requirements to assist to reach solutions concerning Interoperability problems – – For each sector they were analysed the requirements and proposed solutions to move from As-is to To-be situations Using an appropriate methodology for dynamic requirement analysis 68
Conclusions • Generic solutions for Interoperability problems: – Enterprise Modelling • Collaborative Enterprises, and Cross-Organisational Business Processes – Ontology • Knowledge Support and Semantic Mediation Solutions – Architecture and Platforms • Application Planned and Customisable Service-Oriented Architectures – Model-Driven and Adaptive Interoperability Architectures • The Interoperability Framework – Solutions for interoperability problems – Appropriate lifecycle support services for interoperability projects 69
THE END 70
Скачать презентацию Fundamentals in Interoperability Lectured by Ricardo Gonçalves
422872fe201ac61106f2f6ef61f31ab5.ppt