1. Synchronize work on DEXs and reference data between PLCS pilots and OASIS/PLCS - Background, Lessons learned, Conclusions, Recommendations, Plan forward

2. 2 PLCS Inc. (c) 2002 Background

3. 3 PLCS Inc. (c) 2002 Background – DEX ballot process The DEX development team Chair recommends on 3 september 2004, at the OASIS TC in Norfolk, not to send DEXs out for ballot The main issues leading to the statement were  Existing DEXs are not specific enough for unambiguous implementations (open data exchange)  Business needs are inadequately resolved in the solutions  The toolset in DEXLib needs improvements

4. 4 PLCS Inc. (c) 2002 Background – the Synchronization project Based on an NDLO/DNV initiative, the synchronization project was initiated under the OASIS umbrella to address the concerns raised in Norfolk Participants were UK MOD, NDLO, Swedish Defence, Telub/ Aerotech, Bae systems, LSC, Eurostep, DNV The project had 5 workshops from September till December 2004 Project results will be presented for the OASIS TC in January 2005

5. 5 PLCS Inc. (c) 2002 Lessons learned

6. 6 PLCS Inc. (c) 2002 Lessons learned – Slide 1/2 The workshops have stressed the need for an Implementers Forum to achieve unambiguous DEXs, which is crucial for the success of PLCS Co-operation between PLCS pilots/projects and OASIS TC is crucial A feasible plan for further DEX development needs predictability with respect to funding and resources (today's funding mechanism (voluntary) is not satisfactory) The DEXLib environment works as documentation basis for DEXs, but more development are needed to support all functionalities needed for the DEX development Development of DEXs, capabilities and reference data must be based on real business needs and real data implementations

7. 7 PLCS Inc. (c) 2002 Lessons learned – Slide 2/2 Existing DEXs and capabilities contain useful information, especially with respect to mapping solutions, user guidance for the data model and examples. Although more specializations and business concepts are needed: Existing DEX specifications must be more precise to meet the DEX objectives Existing capabilities must be more precise to represent business ontology There is no stable business ontology for product life cycle support. The upper ontology shall be all PLCS entities with names and definitions Standards for product support can not in the short term be represented by a common ontology

8. 8 PLCS Inc. (c) 2002 Conclusions

9. 9 PLCS Inc. (c) 2002 Main Conclusions The conclusions are grouped into following categories: 1. Specific business requirements are basis for DEX development and shall be part of the DEX specification 2. DEX specification shall be unambiguous 3. An open data exchange architecture was drafted 4. Upper ontology for reference data in OWL are PLCS entity names - lower levels are business terminology 5. DEXLib needs further development 6. Issues for a plan forward were listed 7. The example DEX (DEX 10) shall when uploaded be a draft template for further DEX documentation

10. 10 PLCS Inc. (c) 2002 Conclusions – Slide 1/7 Specific business requirements in DEX Existing DEXs are a basis for development of business driven DEXs as specializations Existing capabilities shall be made more precise to meet objectives for exchange of product support data Business ontology in PLCS OWL should be developed from business needs, not on legacy (systems and standards) New DEXs, capabilities and reference data shall be developed when driven by business needs

11. 11 PLCS Inc. (c) 2002 Conclusions – Slide 2/7 DEX specifications shall be unambiguous Unambiguous DEX specification requires specializations of existing DEXs and capabilities A DEX specification shall provide data for the exchange contract to minimize  Identification of the business concepts that are being used  Identification of the capabilities that is required  Example of the pruned DEX long form schema DEX specifications shall meet defined exchange needs as required by contracts Capabilities shall hold ARM instantiations / templates Rules are needed in DEXs, Capabilities and Business concepts. These need to be documented in both the descriptive sections and incorporated in the EXPRESS long form

12. 12 PLCS Inc. (c) 2002 DEX and DEX specification requirements were agreed  There shall be no room for interpretation by implementers  A DEX shall contain unambiguous and recognisable business concepts  Use of DEX and reference data shall be standardized  DEX and DEX specifications shall be reusable across legacy implementations  A DEX shall meet specific business requirements

13. 13 PLCS Inc. (c) 2002 Conclusions – Slide 3/7 An open data exchange architecture Data exchange in an open environment shall be the main focus for the DEX development The underlying architecture for data exchange in an open environment was agreed

14. 14 PLCS Inc. (c) 2002 Conclusions – Slide 4/7 PLCS OWL ontology for reference data Do not develop reference data unless actually needed OWL was adopted as the basis to hold and grow reference data for PLCS with Protégé as the preferred application A stable business ontology for product support is needed The upper ontology shall be all PLCS entities with names and definitions. External ontologies to be integrated in PLCS will be made specialisations of this upper ontology in OWL. Lower levels shall be recognized and used business terms Business standards must for the short term be allowed to exist in parallell (exchange agreement) DEXs refer to standard reference data only

15. 15 PLCS Inc. (c) 2002 Conclusions – Slide 5/7 DEXLib development needs DEXLib shall be used as platform for DEX and capability development. Improvement issues include;  Enhance user friendliness Especially for business users HTML version  Expand the introduction to DEXLib  Indexing mechanism  Develop templates for main rule types  Develop scripts for business concepts, using rule templates  Extend existing DEXLib functionality to activate and complete scripts with information  Develop template for exchange agreements as part of each specific DEX  Prune of longforms

16. 16 PLCS Inc. (c) 2002 Conclusions – Slide 6/7 Issues for plan ahead 3 forums for further DEX development:  Pilots / projects Development and review activities (DEXs, capabilities and reference data)  Implementers Forum Harmonization and reuse of solutions. Testing  OASIS TC Administration, provision of development tool, ballot and publishing activities Plan and fundings for OASIS TC activities are needed  Separate slides later in this presentation Formalization of an Implementers Forum is needed

17. 17 PLCS Inc. (c) 2002 Conclusions – Slide 7/7 Upload of DEX template to DEXLib DEX10 will be an example DEX defined based on real data needs in the NDLO pilot project, however, the DEX10 upload is not intended to represent a complete DEX for real life use. It will propose standard solutions based on agreements in the synchronization project to represent  Rules  Business concepts  Capabilities  Reference data  DEX

18. 18 PLCS Inc. (c) 2002 Recommendations

19. 19 PLCS Inc. (c) 2002 Recommendations The recommendations are grouped into following categories: 1. DEXLib Architecture 2. DEXLib user-friendliness 3. DEX specification 4. Capabilities 5. Reference data 6. Rules 7. Exchange agreements / contract 8. Translators 9. Model interpretations

20. 20 PLCS Inc. (c) 2002 Recommendations DEXLib Architecture Slide 1/9 DEXLib tool shall be developed to encompass the revised DEX architecture containing  business concepts  specializations of generic capabilities  specialization of generic DEXs  rules The content of DEXLib is recommended to be revised and updated according to new architecture in relation to real business needs When uploaded to DEXLib, the example DEX (Assembly part list) shall be reviewed and used as specification for further development of DEXLib architecture

21. 21 PLCS Inc. (c) 2002 Recommendations DEXLib User-friendliness - Slide 2/9 An indexing mechanism shall be established to increase user-friendliness and ensure easy access to business specific information User-friendly interface to reference data library from DEXLib  Graphical representation of reference data hierarchy Extension of DEXLib introduction is recommended. Shall include information as  Data exchange architecture  Reference data  Global identifiers  Rules Provide frequently updated HTML version of DEXLib Graphical presentation of information in DEXLib shall be considered

22. 22 PLCS Inc. (c) 2002 Recommendations DEX specification – Slide 3/9 DEX specification template  Upload an agreed DEX template for acceptance by OASIS based on the example DEX “Assembly part list” to DEXLib  When accepted by OASIS TC the example DEX shall be considered as template for DEX specifications New DEX specifications to be developed in relation to a business need and documentation to be performed according to agreements

23. 23 PLCS Inc. (c) 2002 Recommendations Capabilities - Slide 4/9 Generic capabilities shall be tailored to specific business domains and business concepts Guidelines for developing capabilities shall be developed Documentation of capabilities and business concepts shall be documented according to agreements

24. 24 PLCS Inc. (c) 2002 Recommendations Reference data – Slide 5/9 Business ontology in PLCS OWL shall be developed from business needs, not on legacy (systems and standards) Establish and standardize one complete, stable ontology for PLCS shall be a long term objective For the short term, harmonization of the Def stan 00-60 based ontology currently uploaded to PLCS OWL is recommended Develop guidelines for creating business domain extensions to the reference data library Separate OWL project files shall be defined for representation of specific projects and their local terms Class of class definitions in PLCS/OASIS RDL may be needed for contracting purposes. How to define class of class in OWL shall be investigated

25. 25 PLCS Inc. (c) 2002 Recommendations Rules – Slide 6/9 Rules shall be part of capability and DEX documentation Rule types that are needed for DEXs and capabilities shall be developed  Establish templates needed for each rule type  Templates shall be used for scripts as required  Scripts to be activated and completed with data Rules shall be uniquely enumerated (in capabilities etc) to allow normative reference to them Rules shall be placed at the lowest possible level, i.e. in capabilities, without mandating PLCS global rules. Experience will show where the lowest level is.

26. 26 PLCS Inc. (c) 2002 Recommendations Exchange / Agreement contracts – Slide 7/9 It is recommended to develop a data exchange template A "data exchange contract" shall require  Identification of the specific DEX(es) that shall exchange the business data – to enable conformance testing  Identification of standards used, and the resulting usage of reference data Involved parties need to agree what is their recognized identifier. A text shall be added in the exchange agreement to note the “preferred” option as the one to be used for globally unique identifiers, e.g. for identifiers that may be used for data merge.

27. 27 PLCS Inc. (c) 2002 Recommendations Translators – Slide 8/9 Translators shall be developed according to agreed data exchange architecture Translators may claim compliance to a DEX, if need be, with exemptions for import or export

28. 28 PLCS Inc. (c) 2002 Recommendations Model interpretations – Slide 9/9 Agreed model interpretations shall be incorporated in DEXLib and existing translators Update of capabilities shall be performed in relation to projects/pilots and not as part of the OASIS TC work  For more details, see complete slide series from the workshops

29. 29 PLCS Inc. (c) 2002 Plan Forward

30. 30 PLCS Inc. (c) 2002 Recommendations Recommended plan forward Step 1 Upload the example DEX from the Synchronization project to DEXLib (NDLO activity, to be completed 25 February) Step 2 Establish a team for administration of activities in OASIS TC. First priority for the team is to propose a detailed plan basen on experiences from the “DEX10” activity Step 3 Establish an Implementers Forum The activities in Implementers forum and OASIS TC will be provided by, and based on, input from PLCS pilots and implementation projects

31. 31 PLCS Inc. (c) 2002 Recommendations Plan forward - OASIS TC Team OASIS TC activities Establish and maintain a detailed project plan Management of activities described in the project plan Administration of  DEXs  Capabilities  Reference data Review DEXs submitted for standardization Ballot activities Establish and maintain guidelines for  Reference data  DEX and capability (DEX Cookbook)  Testing (Test document)  Mapping (UK MOD’s mapping document) Maintain infrastructure as exploder, home page, reference data server, DEXLib tool etc. Publishing and maintain DEXs, Capabilities, Reference data, Guidelines  Performed by a dedicated team, funded by OASIS members

32. 32 PLCS Inc. (c) 2002 Recommendations Plan forward - OASIS TC Team Proposed team for administration of further DEX work: Chair and secretary Technical administration team consisting of  2 tool experts with modeling competence  2 business experts with some technical competence in DEX, capability and reference data NOTE This work requires predictability with respect to funding  Consequence: Changes in OASIS TC organization and funding principles

33. 33 PLCS Inc. (c) 2002 Recommendations Plan forward - OASIS TC Team The resources dedicated to technical administration activities in OASIS TC shall work and co-operate as an integrated team. 4 roles are proposed based on conclusions and lessons learned: Role 1. Responsible for ballot routines, balloting, publishing and regular reporting to OASIS members (Tool expert with modeling competence) Technical architect Role 2. Responsible for DEXLib tool, reference data server (Tool expert with modeling competence) Role 3. Assessment of DEXs, capabilities and reference data to avoid competitive DEXs to existing ones (Business expert) Role 4. Communication with Implementers forum, projects and pilots (Business expert)

34. 34 PLCS Inc. (c) 2002 Recommendations Plan forward – Implementers Forum Implementers forum activities Establish guidelines Test interoperability by round robin test rallies Identify test sets Conduct test rallies Modify / Review  DEXs  Capabilities / business concepts  Reference data Harmonization of  Reference data  Interpretations / mapping solutions Submit DEXs, capabilities and reference data to OASIS for standardization Test DEXs

35. 35 PLCS Inc. (c) 2002 Recommendations Plan forward – PLCS pilots and projects Activities performed by PLCS pilots and projects Development of  DEXs  Capabilities  Reference data Submit DEXs, capabilities and reference data to Implementers forum  Projects must take into consideration findings for participation in Implementers forum

36. 36 PLCS Inc. (c) 2002 Recommendations Plan forward – Draft plan / schedule Upload DEX template Establish detailed project plan Develop tool supporting DEX cap and ref data development Establish and maintain guidelines Feb Mar Apr May June Jan July Aug Sep Oct Nov Dec Administration of DEXs, caps, ref data, tool, publishing Ballot activities To be continued Meetings and conference calls Provided by NDLO, not OASIS TC To be continued Management To be continued

37. 37 PLCS Inc. (c) 2002 Recommendations Plan forward – Detailed plan The detailed plan shall include recommended activities and identified actions that is relevant for the OASIS TC scope

38. 38 PLCS Inc. (c) 2002 Recommendations Plan forward – Main activities – Slide 1 Upload DEX template  Part of NDLO project. Completed until 25 February. Delivery: Identify requirements for the DEXLib architecture Identify the OASIS TC team  To be discussed on the OASIS TC meeting 31 January – 1 February Establish detailed project plan  To be presented and accepted by OASIS TC Management of project according to agreed plan

39. 39 PLCS Inc. (c) 2002 Recommendations Plan forward – Main activities – Slide 2 Develop tool supporting DEX, capability and reference data development Administration of DEXs,capabilities, reference data, documentation tool, publishing  Procedures for publishing Establish how the DEXs are to be published. I.e. what format. Establish how to publish Ref. data. Agree to publish OWL files Set up OWL files on Web server  Agree to publish Core PLCS Ref. Data Identify Business domain extensions that will be published standardized extensions to PLCS Ref. Data

40. 40 PLCS Inc. (c) 2002 Recommendations Plan forward – Main activities – Slide 3 Administration of DEXs,capabilities, reference data, documentation tool, publishing (continued from prev. slide)  Publishing DEX Publication  Extend DEXlib to allow HTML publications  Extend DEXlib to allow individual or sets of DEXs to be published as a standalone package.  Agree how DEXs are published – XML Schema? RDL publication  Establish PLCS web server  Publish OWL files on PLCS web server  Establish PLCS RDL server accessed via APIs from translators

41. 41 PLCS Inc. (c) 2002 Recommendations Plan forward – Main activities – Slide 4 Administration of DEXs,capabilities, reference data, documentation tool, publishing (continued from prev. slide)  Technical publishing DEX Publication  Extend DEXlib to allow HTML publications  Extend DEXlib to allow individual or sets of DEXs to be published as a standalone package. RDL publication  Establish PLCS web server  Publish OWL files on PLCS web server  Establish PLCS RDL server accessed via APIs from translators  Reference data – specify process for handling Review Ballot Update

42. 42 PLCS Inc. (c) 2002 Recommendations Plan forward – Main activities – Slide 5 Ballot activities Maintain guidelines Meetings and conference calls

43. 43 PLCS Inc. (c) 2002 The End