Synchronize work on DEXs and reference data between PLCS pilots and OASIS/PLCS

Synchronize work on DEXs and reference data between PLCS pilots and OASIS/PLCS

- Background, Lessons learned, Conclusions, Recommendations, Plan forward

2PLCS Inc. (c) 2002

Background

3PLCS 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

4PLCS 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

5PLCS Inc. (c) 2002

Lessons learned

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

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

8PLCS Inc. (c) 2002

Conclusions

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

10PLCS Inc. (c) 2002

Conclusions – Slide 1/7Specific 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


Conclusions – Slide 2/7DEX 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


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


Conclusions – Slide 3/7An 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

RDL

Local

Legacy 1Legacy 1 Legacy 2Legacy 2Translator 1

DEX n spec

Translator 2

DEX n spec

RDL

Core (standard)

Legacy concepts

Standard concepts

Maps legacy and standard concepts

EXPRESS: Business tailored

sub-set of PLCS schema.

EXPRESS: Business tailored

sub-set of PLCS schema.

DEX spesification (DEX schema) enables:• Unambiguous interpretation of business concepts and data

• Automatic data exchange between legacysystems in an open business environment

P21/P28

Data exchange in an openbusiness environment

Translator may claim compliance tothe business concepts and standards represented in the DEX schemas.Quality rules.

”apple”

”banana”, id=1234

”pear”

”apple”, id=2345 = id 1234”pear”, id=3456 = id 1234

External class id=1234”apple”= id 2345 ”pear”= id 3456

DEX


Conclusions – Slide 4/7PLCS 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


Conclusions – Slide 5/7DEXLib 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


Conclusions – Slide 6/7Issues 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


Conclusions – Slide 7/7Upload 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


Recommendations


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


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


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


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


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


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


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.


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.


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


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


Plan Forward


Recommendations Recommended plan forward

Step 1Upload the example DEX from the Synchronization project to DEXLib (NDLO activity, to be completed 25 February)

Step 2Establish 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 3Establish 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


RecommendationsPlan 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. Developing, Publishing and maintain DEXs, Capabilities, Reference data, Guidelines

Performed by a dedicated team,

funded by OASIS members



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



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)

Information 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)


RecommendationsPlan forward – Implementers Forum

Implementers forum activities Establish guidelines for the implementers 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


RecommendationsPlan 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 fundings for participation in Implementers forum


RecommendationsPlan forward – Draft plan / schedule

Upload DEX template

Establish detailed project plan

Develop tool supporting DEX cap and ref data development

Establish and maintain guidelines

Fe

b

Ma

r

Ap

r

Ma

y

Ju

ne

Ja

n

Ju

ly

Au

g

Se

p

Oc

t

No

v

De

c

Administration of DEXs,caps, ref data, tool, publishing

Ballot activities

To be continued

To be continued

To be continued

Meetings and conference calls

Provided by NDLO, not OASIS TC

To be continued

Management To be continued


RecommendationsPlan forward – Detailed plan

The detailed plan shall include recommended activities and identified actions that is relevant for the OASIS TC scope


RecommendationsPlan 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



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



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



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



Ballot activities Maintain guidelines Meetings and conference calls


The End

Synchronize work on DEXs and reference data between PLCS pilots and OASIS/PLCS

Documents

Transcript of Synchronize work on DEXs and reference data between PLCS pilots and OASIS/PLCS