Best Practice Scribes

Gareth Isaac, Director and Principal Consultant, Ortecha, a DCAM Authorized Partner
Mark McQueen, EDM Council Senior Advisor-DCAM

Le construire contains a business view and a technical view in relationship to each other. As depicted in the diagram, the players in the neighborhood include business and technical oriented resources. Separating the two views creates clearly defined accountability for the business to manage the Élément d'entreprise and technology to manage the Data Element.

Le business view defines the business processus requirements for the data produced by the processus. The business that owns the processus is accountable for defining the requirements for the data including the data criticality. The requirements are defined as Business Terms and Business Elements with all the appropriate business metadata. The Best Practice workgroup determined there was sufficient difference between a Période d'activité et Élément d'entreprise which warranted clear separation, and both were different than a Élément de données.

Similarly, the technical view is an interpretation of the business processus requirements for data transformed into technical data requirements. The data requirements are defined as a Data Element with all the appropriate technical metadata including the physical métadonnées. The use of the Élément de données terme is aligned to ISO Élément de données standard to ensure architecture cohérence with other standards.

Le Élément d'entreprise is conceptual, and the Élément de données is the technological execution of the Élément d'entreprise. The ISO standards body have defined a “Élément de données”, and the EDMC Data Neighborhood reflects the ISO definition and clearly distinguishes that from a “Business Element”.

Determining whether data is critical is from the perspective of the business processus that is consuming the data. Criticality is a business designation based on an assessment of the material impact the data has on the outcome of a business processus. It is this principe that places accountability on the business to identify critical data as part of the requirements for data, so the identification is part of the requirements for the Business Element. Therefore, a Élément d'entreprise that is critical is a Critical Business Element (CBE) and will also have a corresponding Élément de données critique (CDE).

This topic is presented more fully in the Best Practice: Donner la priorité aux données en fonction de leur criticité : Les éléments de données critiques (EDC) en contexte, the section titled Data Producer / Data Consumer Relationship.

Validation

Two approaches were used to validate the Élément d'entreprise / Élément de données Construire worked in real life examples and were consistent with other architectural viewpoints.

1. Use Case – apply the construire to actual data that have different type and levels of complexity
2. Architecture des données & Modeling – align the construire with traditional architecture des données and modeling standards

Use Case Scenarios

To validate the Best Practice, four scenarios were solicited from the groupe. These scenarios are not considered an exhaustive set of CDE scenarios – instead, they are used as a mechanism for a practical demonstration of the concepts defined in the proposed Élément d'entreprise / Data Element Construire.

As presented the scenarios generally move from the most simple to the more complex. The language and concepts defined in the Élément d'entreprise / Élément de données Construire were deemed to be viable in all provided scenarios.

Credit Maturity Date – Represents a scenario where different business requirements for a similar Élément d'entreprise exists in the entreprise, and how to disambiguate the various concepts used.

Click to enlarge image.

Total Cumulative Return – Represents a complex derived Élément d'entreprise and the need to deconstruct the derivation into its atomic parts.

Click to enlarge image.

Registered Address – Introduces the concept of compound or composite data that has meaning with other contextual information. Addresses are common but are complicated to handle as critical data as they are often persisted in different ways, and managed differently depending on the role they are playing and the technology platforms used. This scenario identifies one way an Organization may identify and manage CDE’s representing a Registered Address. Note the actual implementation and approach may be different depending on underlying data and platforms, and there is significantly more complexity when using this in a large federated environment. The implementation pattern choices could make up an entire chapter on its own. However, this use case serves as one way of identifying the data management concepts in this scenario.

Click to enlarge image.

Risk FX Vega – Introduces a tabular concept used to contain several related values to holistically represent a Élément d'entreprise (in this case FX Vega). Vega is the measurement of an option’s price sensitivity to changes in the volatility of the underlying asset. Vega represents the amount that an option contract price changes in reaction to a one percent change in the implied volatility of the underlying asset. This is a Risk metric used to measure portfolios containing options and is made up of several data points (table). This is the first scenario where a Élément de données is comprised of many calculated elements based off more than one dimension (Currency Pair & Tenor).

Click to enlarge image.

Click to enlarge image.

Click to enlarge image.

Data Architecture & Modeling Validation

As the groupe evolved the language surrounding CDEs that resonated with the business community, it was necessary that the architecture viewpoint be considered to ensure the language did not contradict any architecture standards or principles.

To achieve alignment, the architecture des données subgroup ensured the language and definitions were compatible with other architectural standards. The rationale is that the EDMC language and meaning should not contradict any industry standards to avoid confusion by users of those standards. The investigated standards were:

• OMG
• W3C
• ISO
• Other standards
  (ArchiMate, XBRL, O-DEF, E/R, etc.)

It is worth noting that the studied industry standards had been created over time by different groups with different perspectives. While it wasn’t possible to keep 100% alignment with all the standards, compatibility was maintained with the major standards.

It is also worth restating, the ultimate data language needs to be simple enough to be adoptable by business users that will not have a rigorous architecture background, while also being relevant to the language of the technical users in the organization.

A separate smaller Architecture des données groupe worked through the various standards to ensure the language used in the Élément d'entreprise / Élément de données Construire was consistent in language, meaning, and usage with the other standards. Additionally, a logical modèle was created to ensure the concepts could be modeled in a way to ensure every concept is clearly distinct from other concepts. Whilst the logical modèle is not formally part of this whitepaper it serves as a useful tool that architects can use to clearly see how the different terms relate to each other. The modèle is presented in the Appendix: Alignment to Data Architecture & Modeling Analysis.

Click to enlarge image.

---

Revision History

Date	Author	Description
November 2019	Garreth Issac; Mark McQueen	Initial Publication
March 2020	Mark McQueen	Knowledge Portal Release