About PLCS Business Concepts

--- THIS PAGE NEEDS UPDATING TERMINOLOGY REGARDING BUSINESS DEXs ---

The PLCS DEXs are defined using standard terminology and support activities defined in the ISO 10303-239 activity model. Whilst this provides a definition of a data exchange that satisfies a particular business need, it is still too generic for defining a contractual data exchange agreement. In particular:

• the DEX is defined to satisfy a high level business activity, not necessarily the precise business process that is required by the data exchange;
• the DEX may not be expressed in terms that are used by the business, instead standard PLCS terms are used;
• the DEX will not include the reference data required for the business;
• the DEX specifies how to represent something, not what is to be included in the exchange.

Consider for example, a maintenance feedback form for reporting on aircraft repair and maintenance. This form will define exactly what information is required to be exchanged. A PLCS DEX will however specify "how" to represent the information on the form. However, this will be in general terms and is likely to be able to represent a lot of information that is not required on the form. Furthermore, the PLCS DEX does not make explicit what is to be recorded, namely all of the entries in the Form.

The approach is therefore to define the business term and explain how this is represented (mapped) into PLCS. This is done via a "business concept" which provides a definition of the business term and a description of the PLCS model that is used to represent it. This representation is defined by referring to capabilities and templates.

In addition to defining the business concept, it is important to identify the context in which the business concept has been defined as a business term may be used in many different contexts to mean different things. Examples of the context are a project, a company, or a business process.

In order to define a data exchange, the business concepts are collected together to form a "Business DEX". In addition, the PLCS reference data is extended to incorporate the business reference data.

The set of business concepts then provide a library of mappings from business terms to PLCS that can be reused.

A business concept consists of:

• Free text description/definition of the business concept:
  • What is the business concept
  • In which context is it used
  • What are the distinguishing characteristics
  • What makes it different from similar business concepts used in positive terms
• Textual mapping to the capability/capabilities that represent the concept. Informal textual mappings between business concepts and PLCS concepts shall include the entities and capabilities that describe their general usage.
• Description of the applicable reference data
• Constraints, if needed
• Instance diagram
• Relation to other business concepts:
  • Synonyms (different word for the same concept)
  • Homonyms (same word used for different concepts)
  • Similar to (similar concepts, e.g. Initial_provision_spare_part_list, allowance_part_list)
• Identification of the source for the definition/description of the business concept
• Informal textual mapping to the capability/capabilities that represent the concept
  • Identify entities and ref data used
  • Optional: formal mapping
• Listing of the applicable reference data
  • The default reference data should automatically be extracted from the capability
  • The business concept may identify the reference data to be used to classify entities. If that reference data is to be used it shall be subclasses of standard reference data identified in the capability. For example a Part may be classified as a Parts list. This will be identified in the relevant capability. In the business concept an Allowance parts list which is a sub-class of Parts list
• Rules
  • Format
    Textually description (structured English) of all rules to be written in structured English (e.g. Gellish). Source of structured English: www.simplifiedenglish-aecma.org
  • Optional: Formal documentation of rules.
  • Rule types
    • Characterizations for the business concept
    • Constraining values
• Instance diagram
  • Style:
    Complete instantiation of all entities except entities included in the core capabilities. Within each core capability we shall define a macro/template that specifies a pattern of instantiated entities and identify the attributes for which values need to be provided (the parameters of the template). The template will be represented as a box plus parameters which will then be reused throughout in other capabilities and business concepts.
• Hyperlinks to other business concepts, capabilities, synonyms, homonyms etc.