{"id":2936,"date":"2019-11-07T17:31:04","date_gmt":"2019-11-07T22:31:04","guid":{"rendered":"http:\/\/www.dcamportal.org\/?p=2936"},"modified":"2020-03-25T18:46:52","modified_gmt":"2020-03-25T22:46:52","slug":"business-element-data-element-construct","status":"publish","type":"post","link":"https:\/\/staging.dcamportal.org\/fr_ca\/business-element-data-element-construct\/","title":{"rendered":"Structure de l'\u00e9l\u00e9ment d'entreprise \/ de l'\u00e9l\u00e9ment de donn\u00e9es"},"content":{"rendered":"

Best Practice Scribes<\/strong><\/p>\n\n\n\n

Gareth Isaac<\/a>, Director and Principal Consultant, Ortecha, a DCAM<\/span> Authorized Partner
Mark <\/a>McQueen<\/a>, EDM Council Senior Advisor-DCAM<\/p>\n\n\n\n\n\n\n\n

\n

Business Element \/ Data Element Construct<\/h1>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n
\n
<\/path><\/path><\/svg><\/span>

Legend<\/h4><\/div>
\n
\n
\n

Constructs Components <\/strong><\/p>\n\n\n\n

\"\"\/ Business Term<\/span><\/p>\n\n\n\n

\"\"\/ Business Element<\/span> <\/p>\n\n\n\n

\"\"\/ Data Element<\/span><\/p>\n\n\n\n

\"\"\/Business Metadata<\/span><\/p>\n\n\n\n

\"\"\/Technical Metadata<\/span><\/p>\n\n\n\n

\"\"\/Physical Metadata<\/span><\/p>\n<\/div>\n\n\n\n

\n

Business Element<\/span> Types<\/strong><\/p>\n\n\n\n

\"\"\/ Atomic<\/p>\n\n\n\n

\"\"\/ Derived <\/p>\n\n\n\n

\"\"\/ Determined<\/p>\n\n\n\n

Critical Designation<\/strong> <\/p>\n\n\n\n

\"\"\/ Critical Business Element<\/span> (CBE<\/span>)<\/p>\n\n\n\n

\"\"\/ Critical Data Element<\/span> (CDE<\/span>)<\/p>\n<\/div>\n<\/div>\n<\/div><\/div>\n<\/div>\n\n\n\n

Diagram 1: Business Element<\/span> \/ Data Element<\/span> Construct<\/span><\/em><\/strong> <\/p>\n<\/div><\/div>\n\n\n\n

The construct<\/span> contains a business view and a\ntechnical view in relationship to each other. As depicted in the diagram, the\nplayers in the neighborhood include business and technical oriented resources.\nSeparating the two views creates clearly defined accountability for the\nbusiness to manage the Business Element<\/span> and technology to manage the Data\nElement.<\/p>\n\n\n\n

The business view<\/em><\/strong> defines the business process<\/span> requirements for the data produced by the process<\/span>. The business that owns the process<\/span> 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<\/span>. The Best Practice workgroup determined there was sufficient difference between a Business Term<\/span> and Business Element<\/span> which warranted clear separation, and both were different than a Data Element<\/span>.<\/p>\n\n\n\n

Similarly, the technical view<\/em><\/strong> is an\ninterpretation of the business process<\/span> requirements for data transformed into\ntechnical data requirements. The data requirements are defined as a Data\nElement with all the appropriate technical metadata<\/span> including the physical\nmetadata<\/span>. The use of the Data Element<\/span> term<\/span> is aligned to ISO Data Element<\/span>\nstandard<\/span> to ensure architecture consistency<\/span> with other standards. <\/p>\n\n\n\n

The Business Element<\/span> is conceptual, and the\nData Element<\/span> is the technological execution of the Business Element<\/span>. The ISO\nstandards body have defined a “Data Element<\/span>”, and the EDMC Data Neighborhood\nreflects the ISO definition and clearly distinguishes that from a “Business\nElement”. <\/p>\n\n\n\n

Determining whether data is critical is from\nthe perspective of the business process<\/span> that is consuming the data. Criticality\nis a business designation based on an assessment of the material impact the\ndata has on the outcome of a business process<\/span>. It is this principle<\/span> that places\naccountability on the business to identify critical data as part of the requirements\nfor data, so the identification is part of the requirements for the Business\nElement. Therefore, a Business Element<\/span> that is critical is a Critical Business\nElement (CBE<\/span>) and will also have a corresponding Critical Data Element<\/span> (CDE<\/span>).<\/p>\n\n\n\n

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

Validation<\/h2>\n\n\n\n

Two approaches were used to validate the\nBusiness Element<\/span> \/ Data Element<\/span> Construct<\/span> worked in real life examples and were\nconsistent with other architectural viewpoints.<\/p>\n\n\n\n

  1. Use Case<\/strong> – apply the construct<\/span> to actual data that have different type and levels of complexity<\/li>
  2. Data Architecture<\/span> & Modeling <\/strong>– align the construct<\/span> with traditional data architecture<\/span> and modeling standards<\/li><\/ol>\n\n\n\n

    Use Case Scenarios<\/h3>\n\n\n\n

    To validate the Best Practice, four scenarios\nwere solicited from the group<\/span>. These scenarios are not considered an exhaustive\nset of CDE<\/span> scenarios – instead, they are used as a mechanism for a practical\ndemonstration of the concepts defined in the proposed Business Element<\/span> \/ Data\nElement Construct<\/span>.<\/p>\n\n\n\n

    As presented the scenarios generally move from\nthe most simple to the more complex. The language and concepts defined in the\nBusiness Element<\/span> \/ Data Element<\/span> Construct<\/span> were deemed to be viable in all\nprovided scenarios.<\/em><\/strong><\/p>\n\n\n\n

    Credit\nMaturity Date<\/strong> – Represents a scenario where different\nbusiness requirements for a similar Business Element<\/span> exists in the enterprise<\/span>,\nand how to disambiguate the various concepts used.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Click to enlarge image.<\/em><\/p>\n\n\n\n

    \n
    \n
    <\/path><\/path><\/svg><\/span>

    Legend<\/h4><\/div>
    \n
    \n
    \n

    Constructs Components <\/strong><\/p>\n\n\n\n

    \"\"\/ Business Term<\/span><\/p>\n\n\n\n

    \"\"\/ Business Element<\/span> <\/p>\n\n\n\n

    \"\"\/ Data Element<\/span><\/p>\n\n\n\n

    \"\"\/Business Metadata<\/span><\/p>\n\n\n\n

    \"\"\/Technical Metadata<\/span><\/p>\n\n\n\n

    \"\"\/Physical Metadata<\/span><\/p>\n<\/div>\n\n\n\n

    \n

    Business Element<\/span> Types<\/strong><\/p>\n\n\n\n

    \"\"\/ Atomic<\/p>\n\n\n\n

    \"\"\/ Derived <\/p>\n\n\n\n

    \"\"\/ Determined<\/p>\n\n\n\n

    Critical Designation<\/strong> <\/p>\n\n\n\n

    \"\"\/ Critical Business Element<\/span> (CBE<\/span>)<\/p>\n\n\n\n

    \"\"\/ Critical Data Element<\/span> (CDE<\/span>)<\/p>\n<\/div>\n<\/div>\n<\/div><\/div>\n<\/div>\n<\/div><\/div>\n\n\n\n

    Total\nCumulative Return<\/strong> – Represents a complex derived\nBusiness Element<\/span> and the need to deconstruct the derivation into its atomic\nparts.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Click to enlarge image.<\/em><\/p>\n\n\n\n

    Registered\nAddress<\/strong> – Introduces the concept of compound or\ncomposite data that has meaning with other contextual information. Addresses\nare common but are complicated to handle as critical data as they are often\npersisted in different ways, and managed differently depending on the role they\nare playing and the technology platforms used. This scenario identifies one way\nan Organization may identify and manage CDE<\/span>’s representing a Registered Address<\/em>. Note the actual\nimplementation and approach may be different depending on underlying data and\nplatforms, and there is significantly more complexity when using this in a\nlarge federated environment. The implementation pattern choices could make up\nan entire chapter on its own. However, this use case serves as one way of\nidentifying the data management concepts in this scenario.<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Click to enlarge image.<\/em><\/p>\n\n\n\n

    Risk FX\nVega<\/strong> – Introduces a tabular concept used to contain\nseveral related values to holistically represent a Business Element<\/span> (in this\ncase FX Vega). Vega is the measurement of an option’s price sensitivity to\nchanges in the volatility of the underlying asset. Vega represents the amount\nthat an option contract price changes in reaction to a one percent change in\nthe implied volatility of the underlying asset. This is a Risk metric used to\nmeasure portfolios containing options and is made up of several data points\n(table). This is the first scenario where a Data Element<\/span> is comprised of many\ncalculated elements based off more than one dimension (Currency Pair &\nTenor).<\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Click to enlarge image.<\/em><\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Click to enlarge image.<\/em><\/p>\n\n\n\n

    \"\"<\/a><\/figure>\n\n\n\n

    Click to enlarge image.<\/em><\/p>\n\n\n\n

    Data Architecture & Modeling\nValidation<\/h3>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n

    As the group<\/span> evolved the language surrounding\nCDEs that resonated with the business community, it was necessary that the\narchitecture viewpoint be considered to ensure the language did not contradict\nany architecture standards or principles. <\/p>\n\n\n\n

    To achieve alignment, the data architecture<\/span>\nsubgroup ensured the language and definitions were compatible with other\narchitectural standards. The rationale is that the EDMC language and meaning\nshould not contradict any industry standards to avoid confusion by users of\nthose standards. The investigated standards were:<\/p>\n\n\n\n