Introduction

The path to integrated architecture across the organization begins with business architecture and how it defines requirements for data architecture.

A data architecture function establishes consistency in definition and use of data throughout an organization. Adhering to a prescribed data architecture forces business and technology resources to take the necessary steps to define and document data meaning, define the appropriate use of the data, and to ensure that proper governance is in place to manage data as meaning on a sustainable basis.

Definition

The Business and Data Architecture (DA) component is a set of capabilities to ensure integration between the business process requirements and the execution of the DA function. The business process is defined by the business architecture function. DA defines data models such as taxonomies and ontologies as well as data domains, metadata, and business critical data to execute processes across the data control environment. The DA function ensures the control of data content, that the meaning of data is precise and unambiguous and that the use of data is consistent and transparent.

Scope

• Establish a DA function within the Office of Data Management (ODM).
• Work with DM Project Management Office (PMO) to design and implement sustainable business-as-usual processes and tools for DA including the required integration with business architecture.
• Identify and establish data domains, authoritative sources, and provisioning points.
• Identify and inventory the data to support the business requirements, including all necessary metadata including glossary, dictionary, classification, lineage, etc.
• Define and assign business definitions, linked to the data inventory.
• Ensure that the DA governance is integrated into Data Governance (DG) and aligned to both business and technology governance activities.

Value Proposition

Organizations that identify, record and make available information about the internal constituencies that define, produce, and use specific data demonstrate efficient and effective coordination, cooperation, and communications around this data.

Organizations that document information about highly valued data elements demonstrate improved understanding and business use of these data.

Organizations that effectively implement DA to understand their data and data ecosystem get a return on investment from several areas:

• Operational excellence in business processes creates efficiencies and lowers operating cost
• Creation of straight-through, fit-for-purpose data, reduced data debt and remediation costs and increased value derived from advanced analytics
• Greater understanding of your data leads to data simplification and reduces the cost of DM and maintenance
• Understanding your data also reduces operational, financial and reputational risks associated with using the wrong data for analytics, decision-making, and regulatory reporting

Overview

The DA component establishes the unambiguous definition and use of data throughout an organization. Adhering to a prescribed data architecture forces business and technology to take the necessary steps to define and document data meaning, define the appropriate use of the data, and to ensure that proper governance is in place to manage data as meaning on a sustainable basis.

Data exists throughout an organization across all facets of business operations. The design of an organization's data architecture is based on a comprehensive understanding of business requirements and their impact on what data is needed. Unraveling the business process informs how data should be identified, defined, modeled and related. Technology architecture then dictates how the data architecture design is organized and placed into physical repositories in order to provide optimized access, security, efficient storage management and speed of processing.

To establish a successful DA function, the following sequence of activities is required.

First, the following two activities will allow an organization to understand what data is needed to satisfy the business requirements.

• Identification of Logical Data Domains

  Logical data domains are the logical groupings of data, not the databases themselves, that are needed to satisfy the business requirements.

•  

• Identification of Physical Repositories

  Underlying the logical data domains are multitudes of physical, often overlapping repositories of data that will map into the logical data domains. Identification of these underlying physical repositories is a critical step towards minimizing the complexity of legacy environments, reducing replication, better understanding data lineage, assigning data ownership, and assessing data quality (DQ).

Once the data domains and their underlying physical sources of data have been identified, precise business definitions using common semantic language for the identified data must be assigned and agreed upon by stakeholders. DA is about managing the meaning of data. The importance of assigning precise definitions in the context of business reality, the creation of a shared data dictionary and getting the agreement from both data producers and data consumers cannot be minimized. Without this common understanding of data attributes, aligned to business meaning, data architecture will struggle to succeed. The risk of inappropriate use of data will increase and the ability to share data across an organization with confidence will be hindered.

The next step in addressing data architecture is to define data taxonomies and business ontologies. Data taxonomies define how data entities are structurally aligned and related. For each officially designated data domain that is identified, inventoried and deemed critical, a taxonomy must be defined and maintained. The taxonomy is then mandated for all systems using this data as input into their business processes. With critical business function taxonomies defined and in place, the organization needs to model the relationships between taxonomies into a business ontology. Ontologies are the relationships and knowledge of multiple related taxonomies across data domains.

A comprehensive data architecture process may include the following; however, this level of complexity is not always required.

• The business function defines the data in a business model based on the requirements for data as an input and output of the business process.
• These business function data models are then consolidated into an organization-wide business data model.
• For each data domain, a taxonomy is defined, maintained, and mandated for all systems using this data as input to the business process. Data taxonomies define how data entities are structurally aligned and related.
• With business function taxonomies defined and in place, the organization models the relationships between taxonomies into a business ontology. These ontologies represent the relationships and knowledge of multiple related taxonomies across data domains.

Taxonomies and ontologies define and relate the content of data to enable the organization to realize the maximum value of its data in a consistent and controlled manner. Once the content is defined, it needs to be precisely described using metadata. Some of the types of metadata may include, but not limited to, business, operational, technical, descriptive, structural and administrative.

Core Questions

• Are business stakeholders driving requirements for data?
• Are policies in place to govern the creation and maintenance of data attributes and relationships?
• Are governance procedures in place to ensure adherence to established data architecture standards?
• Are design reviews in place and required to ensure enhancements and new development are utilizing standard data architecture definitions?
• Is adherence to data architecture standards auditable?

Core Artifacts

The following are the core artifacts required to execute an effective Business & Data Architecture capability. Items with an ‘*’ link to published best practice guidelines.

• Business & Data Architecture Policy Alignment Matrix
• Business Element – Data Element Model*
• DCAM Business Glossary – Data Dictionary Model
• Data Asset Inventory
• Data Domain Inventory Registry
• Data Lineage – Data Flow Model
• Data Model Inventory
• Data Domain Identification Criteria
• Data Classification Catalog

First Capability

The DA function strategy and approach must be defined and approved by stakeholders. Roles and responsibilities across the stakeholders must be established with operational processes in place.

First Sub-Capability

Description

The strategy and approach for the DA function must be defined and reflect the related vision and objectives of the Data Management Strategy (DMS). Once established, it must be formally empowered by senior management and its role communicated to all stakeholders.

Objectives

• Formally establish the DA strategy and approach within the organization.
• Get approval of the DA strategy and approach from stakeholders.
• Ensure alignment of stakeholder plans and roadmaps with the DA strategy and approach.
• Obtain executive management support for the DA strategy.
• Communicate the role of the DA function across the organization through formal organizational channels.
• Operate the DA function collaboratively with DM initiative stakeholders.
• Secure authority to enforce DA compliance through policy and documented procedure.

Advice

The DA function is a critical bridge between the business and technology stakeholders in the DM initiative. Irrespective of whether the DA function aligns organizationally to the business or to the technology function, the pivotal role as the bridge between these two stakeholder groups must be recognized. Sometimes data architecture is mistakenly viewed as a subset of technology architecture. Successful data architecture requires the integration of subject matter expertise from both business architecture and technology Architecture.

Alignment of the DA strategy and roadmap to the DMS vision and objectives is achieved by agreement between the Operating Level Data Officer and the individual responsible for delivering the data governance function. The Operating Level Data Officer is accountable for establishing priorities across each of the Framework Component requirements.

Questions

• Has the DA function been formally established?
• Is there a DA strategy and approach in place?
• Is the DA strategy and roadmap aligned to the DMS?
• Has the DA function been formally communicated to business, technology, operations, finance and risk stakeholders?
• How has executive management demonstrated its support?
• Has authority been granted to the DA function to implement and enforce best practice via policy and standards?
• Has authority been communicated to stakeholders?
• Is there a functional partnership in place with Internal Audit?

Artifacts

• The DA Plan
• Description of the roles and responsibilities of the DA function
• Communication of specific support from executive management with distribution lists
• Policies and procedures associated with executing and enforcing DA
• Bi-directional engagement with stakeholders on the DA function authority

Scoring

Next Sub-Capability

Description

The DA function will require the coordination between the roles of the DA, business architecture and technology architecture. The integration activities between these disciplines must be defined by specific role descriptions within the different stakeholder teams. It is critical that each team be staffed at an optimal level for the scope and volume of work.

Objectives

• Define and communicate the roles and responsibilities of the DA function.
• Fund and staff the DA function.
• Ensure and enforce alignment of activities and projects to policy and standards through the authority of the DA function.
• Hold individuals accountable for the data control environment performance via annual reviews and compensation considerations.

Advice

Effective DA is critical to the DM initiative. The data architect needs an understanding of the business process and the technical environment to excel as the bridge between these two disciplines. The data architect will partner with the business data steward and technical data steward. The business data steward is accountable for the business element, which defines all the requirements for data. The technical data steward is accountable for the data element, which is the physical execution of the concept defined by the business element.

Questions

• Has the DA function been established?
• Is the DA function appropriately staffed and funded?
• Does the DA function have the authority needed to be effective?
• Have the roles and responsibilities of the DA function been defined, documented and socialized?
• Have the skills for data ethics review and execution of Machine Learning (ML) and Artificial Intelligence (AI) tools been added or developed within the stakeholders?
• Have milestones and metrics associated with DA execution been established?

Artifacts

• Evidence of stakeholder identification
• RACI matrix or other evidence of accountability assignment
• Description of the roles and responsibilities of the DA function
• Staff qualifications and assignments
• Evidence of accountability linked to reviews and compensation
• Gap analysis of skills needed and those in place
• List of stakeholders and evidence of bi-directional communication

Scoring

Next Sub-Capability

Description

Formal processes have been established for the activities of the DA function. These processes align with the DM policy and standards of the organization and include procedures, tools and routines. The routines are required for steady-state operations.

Objectives

• Establish formal DA processes in alignment with the DM policy and standards.
• Integrate the DA processes into the overall end-to-end processes of the DM initiative.
• Identify, schedule and maintain DA routines, meetings and working sessions required for operational support.

Advice

The DA subject matter experts should work with the business process design and optimization service within the Data Management Program (DMP) function. Together they will create and monitor the implementation of the DA processes in alignment to the end-to-end process across the full DM initiative.

Questions

• Have formal processes been defined and implemented?
• Are the procedures, tools and routines in place for implementing the processes?
• Have innovative technologies such as AI and ML been considered as part of the DCE process and infrastructure?
• Has the review of data ethics been included in the Data Quality Management (DQM) strategy and approach?
• Are DA activities part of the normal operational routine of stakeholders?
• Are there standing meetings, planning sessions and regular communications about DA initiatives?

Artifacts

• Process design artifacts, procedure guides and published routines
• Process performance metrics reports
• Meeting minutes, status reports and DA announcements

Scoring

Next Capability

The DM initiative must be engaged with the business architecture function for three activities: 1) the business process must define data as an input and output; 2) manage restrictions on data access and use by the business process; and 3) root-cause-fix for data issues that involve people or process deficiency. This engagement must be supported by mutual governance and policy.

First Sub-Capability

Description

The DM initiative must be engaged with the business architecture function of the organization to support the identification of requirements for data as input and output of the business process design and optimization activity.

Objectives

• Define a process optimization framework for the business architecture function. Include the identification of requirements for data as input and output of the process.
• Engage the DA function in business process design and optimization. Integrate requirements for data into the standard data models of the organization.

Advice

The BA function should engage with business subject matter experts to define requirements for data. The DA function then will engage with the business data stewards to interpret the requirements for data into a complete set of business element requirements. They should then record these requirements as metadata. The DA function can then engage with the technology function to translate business element requirements into the requirements for the physical data elements. In this way these physical data elements are brought into the real world.

Questions

• Are the BA function and the DA function integrated into the business process design and optimization activities?
• Does the business process design and optimization activity generate requirements for data as input and output of the process steps?

Artifacts

• Business & Data Architecture Policy Mapping
• Business & Data Architecture Target-state
• Business & Data Architecture Execution Roadmaps
• Process Optimization Framework
• Business Element – Data Element Construct

Scoring

Next Sub-Capability

Description

The business process design and optimization effort must define requirements for data as an input and output of the business process activities. To process these requirements a review of any restrictions on the data usage is required. These restrictions may be due to data-subject owner consent, privacy, ethics of accessing the data and ethics of the data usage output of the business process.

Objectives

• Define a process to evaluate the data usage restrictions of the data.
• Define data restrictions that include the ethics of accessing the data and the ethics of the data usage output of the business process.

Advice

As the BA function delivers requirements for data to the DA function, a review of the data usage restrictions must be completed. This review should involve the business and technical data stewards as required. The data usage restriction review must be exhaustive across all regulatory, internal policy and ethical considerations.

Questions

• Have all the usage restrictions for the data been defined and reviewed?
• Is ethical data access and data usage output defined in the data usage restrictions?

Artifacts

• Process documentation for data usage restrictions
• Data usage restriction metadata

Scoring

Next Sub-Capability

Description

When data fit-for-use issues are encountered, the BA function must be engaged if it is determined that the root cause fix required involves a people or process deficiency.

Objectives

• Define a process to engage the BA function to conduct root cause analysis and execute root cause fix solutions when the deficiency is related to people or business process.

Advice

When data fit-for-use issues are discovered the first step is to triage the potential cause. The triage review may determine it is a data issue, a technology issue, a business process issue or a people issue. The type of issue will define the subject matter expertise required to determine the root cause fix. In the case of either business process or people issues, the business architecture function should be engaged in the root cause analysis. Direct business subject matter experts should be engaged as needed.

Questions

• Is there a triage process in place to identify suspected root cause of data defects?
• Does the data defect issues log include categorizing issues that align to people or process?
• Is the business architecture function involved in the analysis and root cause fix of data defects aligned to people and process?

Artifacts

• Process for engagement of business architecture in root cause fix activities
• Issues log that includes defects aligned to people and process

Scoring

Next Sub-Capability

Description

Alignment of DA and BA governance includes: a definition of the business process; data requirements as an input and output of the business process; and integration of data consumer requirements including third party data contract specifications. DA governance is a part of the overall DM governance structure and routines.

Objectives

• Align DA governance with BA governance to ensure semantic definitions, taxonomies and critical data elements (CDEs) are properly assigned and maintained.
• Utilize DA governance to monitor the capture of appropriate business metadata as defined by DM policies.

Advice

The goal is to ensure that the management of data meaning is aligned with defined business processes. Business elements including their definitions and relationships to one another need to be properly assigned and maintained to capture and align with business reality. Data meaning needs to be aligned with operational processes and third-party data requirements. Collaboration is required to manage data vendor, data producer and data consumer relationships and entitlement control needed to maintain the flow of data.

Questions

• Have business processes been defined and verified?
• Are governance procedures in place to ensure unambiguous shared meaning across the organization?
• Have the business processes defined the priority data (CDEs) that is critical to the process?
• Are there mechanisms to ensure collaboration between data producers and data consumers?
• Are third party data requirements and restrictions defined and accessible?

Artifacts

• Business process flow diagrams with data as an input and output
• Bi-directional communication on data definitions and relationships
• CDEs defined by business processes
• Security and privacy classifications

Scoring

Next Capability

Identifying the data includes: 1) defining the logical data domains; 2) mapping of physical data repositories to the logical data domains; and 3) cataloging the physical data in the repositories.

First Sub-Capability

Description

Identification of logical data domains must be driven by the business from the perspective of what data is needed to perform the required business functions. A logical data domain is the representation of a category of data that has been designated and named. Logical data domains represent the data, not the databases, which are needed to satisfy the business process requirements.

Objectives

• Involve business process subject matter experts in the identification of the logical data domains.
• Identify and prioritize logical data domains.
• Structure logical data domains to contain the data of the domains irrespective of the various organizational structures where the data may be produced organization-wide.

Advice

The overall goal is to ensure the proper use of data and to get stakeholders to think about DM in terms of data content concepts and not the physical database repositories. All this needs to be based on an understanding of how the business functions operate in reality. Once the logical data domains are defined, they must be mapped to their physical locations and associated with authorized provisioning points. The first step, however, is to define the domains.

Data domains include both internally generated data as well as externally acquired data. It is imperative that these strategic data assets are identified and inventoried to ensure their proper use in all data consumer critical business processes.

Questions

• Have data domain owners who are responsible for the quality and availability of the data been identified?
• Has the business domain owner, as well as the DA function, been involved in the designation of the authoritative data domains?
• Have data domain taxonomies and conceptual/logical models been verified by business subject experts?
• Are all critical business functions represented in the discussion?
• Is the distinction between data domains and databases clear?

Artifacts

• Policy indicating what authoritative data domains are and how they are to be used
• Criteria for determination of authoritative data domains
• Inventory of authoritative data domains
• List of stakeholders and evidence of bi-directional communication

Scoring

Next Sub-Capability

Description

Underlying the logical data domains are physical repositories of data that will map to those logical data domains. The physical repositories may include application data, databases, spreadsheets, data warehouses, data lakes, streaming data or data stored in cloud services.

Objectives

• Link underlying physical repositories to the logical data domains and record those links.
• Identify repositories that have been inventoried and document that the inventory is actively maintained.

Advice

The data elements in any logical data domain need to be mapped to where the data physically resides. The first step is the creation of the inventory of data repositories. It doesn’t really matter where the content resides. This may be external, streaming, master/slave and cloud-based. What is important is that it is linked to the authoritative data domains and enforced. This is not about centralizing the data in a warehouse. It is adequate if the data has a unique repository identified as the known source of the data.

Questions

• Have the inventories of data repositories been compiled and verified?
• Have the authoritative data domains been mapped to their physical location?
• Are controls implemented to ensure namespace integrity and accessibility?
• Has policy been drafted, verified and sanctioned on the use of authorized provisioning points?

Artifacts

• Inventory of data repositories and authorized distribution points
• Mapping of authoritative data domains to the physical location
• Policy statements on the use of authorized provisioning points

Scoring

Next Sub-Capability

Description

After the physical repositories of data aligned to the data domains are established, the next step is to catalog the physical data in the repositories.

Objectives

• Establish a catalog of data elements aligned to the data domain.
• Capture basic metadata on the data elements.
• Make the data catalog accessible to stakeholders.

Advice

The data elements aligned to a data domain must have basic metadata captured including but not limited to source, term name, term definition, field name and field location. The basic metadata is required to make the data accessible. Any data consumer and particularly the data analytics consumers will need this metadata as part of their discovery process in advance of defining data for production usage. As data is prioritized based on business needs and business process criticality the data policy will require a more comprehensive set of business and technical metadata to be captured.

Questions

• Have the data elements aligned to a data domain been cataloged?
• Has basic metadata been captured on the data elements?
• Is the metadata accessible to stakeholders in a data catalog?

Artifacts

• Data policy for basic metadata capture on data elements aligned to a data domain
• Data Catalog

Scoring

Next Capability

Defining the data includes: 1) defining and documenting the conceptual and logical models; 2) establishing the business process definition of the data; and 3) use of taxonomies to establish relationships between the data.

First Sub-Capability

Description

Conceptual and logical models for all enterprise data domains must be defined and documented. Alignment to the models must be required by policy and integrated into the enterprise change management policies.

Objectives

• Define and document conceptual and logical data models.
• Verify conceptual and logical data models with key stakeholders.
• Capture data object relationships and document them into domain ontologies.
• Verify authoritative data domains with business subject matter experts.
• Publish authoritative data domain taxonomies and demonstrate use by upstream/downstream systems.
• Align and cross-reference internal taxonomies to global standards.

Advice

Conceptual models define how business processes work in the real world. Logical models organize the data in into manageable domains. Taxonomies define hierarchical relationships. Taxonomies are critical to establishing a common definition and language of data organization-wide and are required to ensure the data's proper use. Establishing these models should be done independent of the future physical instantiation of the data, however, issues related to relational data design vs. semantic (i.e.: graph or OWL design) should be considered strategically in designing the enterprise entity data.

Once the models are designated, they need to be managed and required by policy to ensure that they are implemented, maintained and used. Alignment to data domain taxonomies and conceptual models should be formally mandated by the organization’s change management policies including change approvals, impact analysis and controlled implementation.

Data repositories contain data that represents real concepts required in the business processes. The data have terms, define characteristics, express conditions, define triggers, specify requirements and translate activities in the business process. The goal is the creation of a single conceptual view of data that defines how business concepts and processes work in the real world. The conceptual model is used to express the requirements for data in business terms, based on the business process activities at the most granular level needed in the business process. The logical data model is used to define a logical set of data to align to a data domain. The scope of the logical data set can be validated by whether there is a natural subject matter expertise to support the data set. If the scope of the logical data set is too broad it will require desperate subject matter expertise and be inefficient to manage.

Granular data is often used to manufacture derived concepts to manage the objectives of the business processes. Derived concepts can sometimes be very complex and be manufactured from many data elements that may have variation if the data comes from multiple sources. Ensuring that the data is aligned with common meaning is an essential requirement for achieving automation, performing advanced analytics and generating trusted reports. This is one of the essential goals of the DM initiative and the building block of most business processes. Without shared meaning and transparency about how derived concepts are created, the organization will have challenges unraveling interconnections, managing complexity and most importantly using data to drive innovation.

Questions

• Have conceptual and logical data models defining the organization-wide data domains been verified by business subject experts?
• Are data taxonomies and models documented, made accessible and used in existing and new systems?
• Have policies and standards for managing data models and taxonomies been defined, verified, sanctioned and made accessible?
• Has governance over taxonomies been aligned with existing change management policies?
• Has the model of terms, definitions, and relationships been verified by business stakeholders and stored as metadata?
• Are there mechanisms for access such as glossaries that can be used as reference points for implementation?

Artifacts

• Policy and standards on use and maintenance of data models and taxonomies
• Mapping and transformation to ensure implementation by upstream and downstream systems
• Business conceptual terms, definitions and relationships
• Agreement on business meaning verified by stakeholders
• Data models and taxonomies recorded in metadata repository
• Metadata repository content accessible to stakeholders
• List of stakeholders and evidence of bi-directional communication

Scoring

Next Sub-Capability

Description

Business definitions must be developed as non-technical descriptions of data attributes that are based on contractual, legal and/or business facts.

Objectives

• Document business definitions and verify them with stakeholders.
• Assign approved business definitions to defined taxonomies, which are fully attributed conceptual models.

Advice

The precise meaning of data gets convoluted as data is moved around, copied and renamed. This is a problem because most organizations are run by business applications. Applications are driven by software– each with their own unique data model. And all these models use glossaries as core factors of input. Meaning is often aligned with the specific software to make sure it works. It is not aligned across all applications and not harmonized across the organization. This creates circumstances where organizations use the same terms to mean different things and refer to identical things using different terms. These problems can be exacerbated when aligning front office to back-office processes because terms used in the front office don’t always communicate critical nuances that are needed to meet legal obligations in the back-office. These definitional differences create problems with integration and make it difficult to unravel complex business calculations or reuse data across new applications. The goal is the agreement on the meaning of data terms in the context of how they are used.

Questions

• Has the business meaning of atomic and derived terms been defined and verified?
• Have legal and compliance representatives been involved in the legal language used to define business concepts?

Artifacts

• Business glossaries
• Complete front-to-back stakeholder engagement
• List of stakeholders and evidence of bi-directional communication

Scoring

Next Sub-Capability

Description

Data identification, classification and taxonomy schemes and methodologies must be used to ensure precise organization of data. Establishing these schemes and methodologies are critical to defining how things relate, establishing standard treatment of data organization-wide and for aggregating data for analytical purposes. Unique and precise identifications, classifications and taxonomies are a foundational concept and is a required aspect for regulatory reporting, risk analysis and other internal analytics.

Objectives

• Define identifiers for critical business elements.
• Assign and publish internal entity IDs and use them across business processes.
• Align and cross-reference internal IDs to industry standard identifiers.

Advice

Data identification schemes are required for data factors of input such as Customer ID, Legal Entity ID and Product ID.

Data classification schemes are required for data factors such as privacy treatment, info-security treatment, masking, encryption and risk analysis.

Data taxonomy schemes define how things relate. Taxonomies define the relationship of Business Elements within a data domain. Taxonomies are critical to establishing a common definition and language of data organization-wide and are required to ensure the data's proper use.

Standard identification, classification and taxonomy schemes need to be mapped to any proprietary identifiers used in consuming applications. Unique identification is a core foundational tenet of DM that is governed by policy and enforced by standards.

Policies, procedures, and standards are needed to ensure the appropriate assignment, use, and maintenance of identification, classification and taxonomy schemes. The creation of these schemes requires participation from business, data, technology and legal and compliance stakeholders. In many cases, compliance policies may already exist, but they may not be integrated into the appropriate use or Software Development Lifecycle (SDLC) and/or change management processes within an organization.

Establishing these schemes and methodologies are critical to defining how things relate, establishing standard treatment of data organization-wide and for aggregating data for analytical purposes. Unique identifications, classifications and taxonomies are a foundational concept and is a required aspect for regulatory reporting, risk analysis and other internal analytics.

Identification schema for instruments, entities, customers, and products need to be unique and precise. Standard identifiers need to be mapped to any proprietary identifiers used in applications consuming data. Unique identification is a core foundational tenet of DM that must be governed by policy and enforced by standards. The scope and value of advanced analytics is very dependent on the standard identification schema.

Questions

• Have unique and precise identification schema been established for all instruments, entities, customers, and products?
• Has policy been developed and approved to ensure these identifiers are used in business applications?
• Have standard identifiers been published and cross-referenced to any proprietary identifiers?

Artifacts

• Policy about standard identifiers
• Inventory of identification standards being used
• Cross-referencing and transformation documentation

Scoring

Next Sub-Capability

Description

An organization-wide standard metadata model is required. The metadata is the data domain that is owned and managed by the DM initiative. The same DM initiative requirements for managing any data domain are applied to the DM data domain.

Objectives

• Define and implement the metadata model for the data domain owned and managed by the DM initiative.
• Include all data required as input and output of the DM business process in the metadata model.
• Manage the DM data domain according to the data policy and standards.

Advice

The DM data domain includes all metadata defined as requirements for data as input and output of the DM initiative business processes. To execute standard DM processes the metadata in the processes must align to a standard metadata model. An additional benefit of standard metadata is the interoperability across all the data domains as they interact. And finally, the standard metadata creates the ability to support, as appropriate, the implementation of DM processes centrally in the organization.

Another significant application of metadata is the data classification schema that allows identification of data flagged for issues such as privacy, sensitive data, consent requirements, data-subject rights and the ethical use, access and outcome of data.

The types of metadata are many and may include business, operational, technical, descriptive, structural, administrative.

Questions

• Is the DM data domain defined with a metadata model?
• Does the metadata model include all data required by the DM business processes?
• Does the metadata model include a comprehensive data classification schema?

Artifacts

• DM data domain included in the organization data domain structure
• Metadata model defined for the DM data domain
• Data classification schema?

Scoring