Best Practice Scribes

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

The model 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 Business Element and technology to manage the Data Element.

The business view defines the business process requirements for the data produced by the process. The business that owns the process 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 Business Term and Business Element which warranted clear separation, and both were different than a Data Element.

Similarly, the technical view is an interpretation of the business process 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 metadata. The use of the Data Element term is aligned to ISO Data Element standard to ensure architecture consistency with other standards.

The Business Element is conceptual, and the Data Element is the technological execution of the Business Element. The ISO standards body have defined a “Data Element”, 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 process 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 process. It is this principle 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 Business Element that is critical is a Critical Business Element (CBE) and will also have a corresponding Critical Data Element (CDE).

This topic is presented more fully in the Best Practice: Prioritizing Data Based on Criticality: Critical Data Elements (CDEs) in Context, the section titled Data Producer / Data Consumer Relationship.

Validation

Two approaches were used to validate the Business Element / Data Element Model worked in real life examples and were consistent with other architectural viewpoints.

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

Use Case Scenarios

To validate the Best Practice, four scenarios were solicited from the group. 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 Business Element / Data Element Model.

As presented the scenarios generally move from the most simple to the more complex. The language and concepts defined in the Business Element / Data Element Model were deemed to be viable in all provided scenarios.

Credit Maturity Date – Represents a scenario where different business requirements for a similar Business Element exists in the enterprise, and how to disambiguate the various concepts used.

Click to enlarge image.

Total Cumulative Return – Represents a complex derived Business Element 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 Business Element (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 Data Element 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 group 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 data architecture 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 Data Architecture group worked through the various standards to ensure the language used in the Business Element / Data Element Model was consistent in language, meaning, and usage with the other standards. Additionally, a logical model 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 model 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 model 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