The title of this article is a pun intended to question if, from a Data Management perspective, the vocabulary should only refer to Data Elements (DE), or if there is in fact an overlooked information category of Business Elements (BE). During Data Lineage projects there comes a time when the question is asked what are you tracking? In fact, this question equally applies to the broader data management space, although more often than not it is initially asked as part of a reactionary data lineage driven effort.
This article covers the various types of information used during the Data Management process, and how the information can be used to meet Data Management needs. Regulators commonly ask Financial Institutions (FI) for Data Lineage based on Critical Data Elements (CDEs). Because of the way the question is asked the organization assumes they must track at that level. Instead they should accept the regulator request as the “What” is being asked of them and define “How” in a way that best meets their needs for sound data management.
To achieve this the article steps back and defines the Information Landscape building blocks necessary to support data in an organization, after which the “Data Framework” and “Data Management Practice” can be executed leveraging these foundational information constructs.
Starting with the Data Element (DE)
Most people are familiar with a generic meaning of “Data Element”, for those that are not here is a stock definition from an ISO Metadata repository standard (ISO11179):
A Data Element is a unit of data that is considered in context to be indivisible. (ISO 11179-1:2015)
It is fair to say that there are many definitions for Data Elements available and this one is specific to a Metadata context, and there isn’t a single “right” answer, overall we hope not too many disagree with this definition. This definition indicates that a Data Element (DE) is a specification of data that can be inspected, and as such if it is in a different location and has different sets of permissible values it would be a different Data Element. To make this more tangible below are some examples of related, but different, data elements:
While these are two distinct data elements they clearly represent the same concept with different identification, representation, and permissible values. It naturally leads one to the question – is there language to represent this concept? The good news is that ISO11179 does have a term to represent the concept.
A Data Element Concept is a concept that can be represented in the form of a data element, described independently of any particular representation. ISO11179-1
While the term “Data Element Concept” sounds geeky it does appear to cover the missing concept.
Now this is where real world practicalities with Data Management start to come into play as we need to build up a communication and deployment plan to integrate Data Management into the organization. We need a term that resonates with the business (aka the people that do not normally think of data first) and allows us to separate out the responsibility and accountability without our message being dismissed as “techno gobbledygook” and not applicable to them.
Reference point: Unfortunately in todays world terms are often used imprecisely by technology firms, and their intended use vs the the way it is commonly referred to is often blurred. Unfortunately this is also seems to be the case when talking about CDE (Critical Data Element’s) in the Finance world. So it seems fitting to refer to some external documentation to ensure everything is understood. The BIS team produces an initial document covering “Key Data Elements” (September 2015) , the third release “Critical Data Element’s” was in June 2017 The Bank for International Settlements OICV-IOSCO
Besides the fact that you can see the change from “Key” (Sept 2015) to “Critical” (June 2017), looking at the contained content you can see the CDE’s (June 2017) are defined with both a “Format” and “Allowable values” (i.e. “Y”/”N” etc). So these exactly match the ISO definition of “Data Elements” as they have both the “Representation” and “Permissible Values”. So it seems the both BIS, IOSCO and ISO 11179-1 all align to the same expectation of a “Data Element”, leaving us to wonder where our equivalent of “Data Element Concept” (or similar) fits into Data Management.
Migrating to Data Management Terms
This is where the Data Management vocabulary separates a little from our starting point of the ISO Metadata standard (ISO11179). The terms are changed predominantly to help reinforce ownership and improve adoptability within the business community. It is understandable why some purists may be howling in pain now – but bear with us as we go down the journey.
To gain more general traction the Term “Business Element” or BE is used instead of “Data Element Concept”. The BE is largely equivalent to the “Data Element Concept”, but has been named to support adoptability and help reinforce the business accountability for its maintenance.
For full transparency, a Business Element is slightly different than a Data Element Concept and for that reason alone they should be called different things, however rather than performing a deep dive clarifying the exact differences between these two let’s step further back and consider the whole stack and see what else is in our vocabulary?
So we have now established an understanding of what a Business Element (BE) and Data Element (DE) is – what other concepts exist in this Data Management information landscape?
Below is a classical view of the various element levels in a top down view of the landscape, and an approximate magnitude associated with each. The triangle is used to visually clarify that there are orders of magnitude between the counts of the layers. Strictly it wouldn’t be such a simple linear view and but presenting it this way is a helpful, especially as we then apply a responsibility to each layer.
A more definition based view of the landscape is:
This illustration helps us understand the various levels of abstraction and understand which organization group is responsible for each layer. We still haven’t proposed a definition for a DE or BE, but before that let’s have a deeper look at what are the characteristics of each of these terms.
Below is a view of the high-level information artifacts in a simple classification to separate out concepts, metadata and data – and then show how Terms, Business Elements and Data Elements relate to those.
For clarity, the above illustration is a simplified view specifically tailored for this article to depict how information types tie together. A more complete and accurate representation of the relationships between these artifacts is covered in a later article (link will be added when published).
Deeper Dive into Meaning
So we have covered the outline of the landscape, in the following table there is a deeper set of meanings and implications associated with each term:
Can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive. [https://www.w3.org/TR/skos-reference/#concepts]
To compare an idea or notion it has to be persisted or referenceable in a way so it can be differentiated from other concepts. In the Data Management world this information ends up being represented in an Knowledge Organization System (KOS), more often than not an Ontology is used to capture the concepts.
Whilst the Business is accountable for the concept, Technology is responsible to representing it in a KOS.
The appetite and capacity to articulate concepts in a KOS may be less than the ability to collect Terms, as such to be successful in managing the Information landscape the ability to remove any requirements on a Term for a Concept to be formally documented before a Term is added is key.
- a word or phrase used to label a concept.
- Note a term may include things beyond data, processes etc.
- A term is often confused with a BE or DE, but while they can appear on the surface to be the same it is a mistake to merge these constructs.
- A Term has meaning, but doesn’t have a context outside of a specific vocabulary it resides in.
- For example “End Date” could be a Term, while “Transaction End Date” would be a Business Element.
- Terms are added as needed, but the rate of the addition is controlled by the team responsible for maintaining the accuracy and consistency of the vocabulary.
Business Term (BT)
Curated and accepted by the business community
To be successful in harvesting the terms from the business, the process has to be sufficiently lightweight and empower the business community to add and maintain the content themselves. However there still has to be appropriate oversight to prevent duplicates and the repository becoming uncontrolled.
Technical Term (TT)
Curated and accepted by the technical community
Note these are not often utilized by Data Management functions (unless the business is a technical one), however this is called out to clarify there are differences between a Term, Business Term and other terms.
Business Element (BE)
Is Business Metadata that represents a unit of information that has a specific business meaning in the context of a business process or collection of processes within a business domain.
Business is accountable for content, and should align with one or more Business Terms. If no terms exist in the glossary that meets the meaning then a candidate term is proposed.
A BE can exist without a Term, but this should only be temporary. Any BE’s without associated terms should be remediated, otherwise the foundational aspects of the business vocabulary is incomplete.
Note: A BE cannot be directly measured, they can be indirectly measured through a DE. However they can and should have business rules associated with them
Data Element (DE)
Is Technical Metadata that represents specific unit of data that has precise meaning or precise semantics.
Most should have traceability back to one or more Business Element(s)
Technology is accountable for content, and technology implements any business rules with data controls.
Data Element is the physical execution of the requirements of the “Business Element” with additional supporting technical controls to ensure data quality is achieved and maintained as an element is captured and moves through the data ecosystem.
Examples include regulatory report fields definitions, database column definitions, file definitions that represent data.
How do Terms, Business Elements and Data Elements Differ?
Looking in the middle of the landscape, or more precisely the Metadata elements, is where most of the confusion arises the following table should help clarify how these constructs differ from each other.
Business Element (BE)
Data Element (DE)
Central curation team
Defined by term
Maps to one or more Business Terms, and if the BE meaning is simple it can be inferred – else requires to be directly stated.
Meaning maps to Business element(s), but may be affected by physical platform constraints.
Articulates label for concept meaning only
Articulates the concept as used by the business with documented business constraints.
Articulates the business element location in technology language, but it is optimized for technology implementation.
Word or phrase within Barron’s Dictionary
Logical business concept, unencumbered by technology constraints.
Technical implementation of the Business Element. Examples may include Database columns, Report fields, screen fields, regulatory report lines.
Up to now we have described what a DE and a BE is, how they fit into the landscape and why they exist – but we haven’t actually assigned robust definitions.
A Unit of thought. [ISO25964-1]
Data that defines and describes other Data.[ISO/IEC 11179-3:2013, 3.2.74]
Metadata that provides context about the data from the perspective of the business process.
a word or phrase used to label a Concept [in a clearly defined context] . [ISO25964-1]
a Term that is associated with the business and managed by the Business.
Business Metadata describing a unit of information that has a specific business meaning in the context of a business process or collection of processes within a domain.
Technical Metadata describing a unit of data for which the definition, identification, representation, and permissible values are specified by means of a set of attributes.
Derived from ISO11179-1
Note this may realise a Business Element in a physical form.
Technical Metadata describing a unit of data that is considered in context to be indivisible (ISO 11179-1:2015)
Note this commonly has data traceability back to a Business Element.
re-interpretable representation of information in a formalized manner suitable for communication, interpretation, or processing.
The description for a term is constructed by referencing its parent as part of the description, this allows us to see that both the Business Element and the Data Element are both types of Metadata. For transparency, this wasn’t done for Term because in this specific case it was felt there is little confusion as to what type of information it is, and staying aligned with the various ISO standards was more appropriate.
This article articulates the rationale and introductory usage of a Business Element. Hopefully it is clear why an external party may articulate requirements in terms of a Data Element, but from a Data Management perspective these are just physical instantiations of the Business Element. In order to be successful we need to manage meaning and content at the BE level.
Another benefit from these definitions is that we can clearly articulate that a Data Element isn’t an actual data value. As we start to discuss the process of measuring data quality (DQ) and Data Set’s the understanding of a “Data Element” can easily get blurred between Data and Metadata. It’s a slippery slope, but with these definitions the meaning is always clear.
So to answer the tagline of “To DE or to BE that is the question” – to successfully manage data within an organization you can’t operate only be in the weeds at the DE level, but have to recognize all the layers and how they interact. Business Elements are a core requirement that is a key part of Data Management.
We are always interested in feedback so if you have questions, disagree with what we say and would like to engage in debate, or want more information on Ortecha please contact us at email@example.com