{"id":5060,"date":"2025-11-03T11:13:49","date_gmt":"2025-11-03T16:13:49","guid":{"rendered":"https:\/\/staging.dcamportal.org\/?p=5060"},"modified":"2026-02-24T15:09:29","modified_gmt":"2026-02-24T20:09:29","slug":"dcam-v3-framework-beta-3-0-architecture-business-data-technology","status":"publish","type":"post","link":"https:\/\/staging.dcamportal.org\/fr\/dcam-v3-framework-3-architecture-business-data-technology\/","title":{"rendered":"Cadre DCAM v3 \u2013 3.0 Architecture \u2013 M\u00e9tier, Donn\u00e9es et Technologie"},"content":{"rendered":"
\r\n
\r\n
\r\n
\r\n
\r\n<\/div>\r\n<\/div>\r\n\r\n

\"DCAM<\/p>\r\n\r\n

\r\n
\r\n\r\n

Upper Matter<\/h3>\r\n<\/div>\r\n
\r\n
\r\n

Introduction<\/h3>\r\nThe Architecture – Business, Data & Technology<\/b> component focuses on establishing an integrated architecture as a foundation for best-practice data management. Ensuring collaboration among business, data, and technology architectures is essential for achieving business objectives. The architecture disciplines provide the structure and blueprints that are leveraged in other DM capabilities. Business Architecture<\/span> is the strategy, design, and execution of business capabilities needed to support the organization’s business processes and activities with a focus on deliverables used as inputs for data architecture<\/span>. Data Architecture<\/span> is the strategy and execution of design processes for data structures, definitions of data meaning, and metadata<\/span> to support the organizational objectives. Technology Architecture<\/span> is the strategy and execution of the design of the physical infrastructure based on business and data architecture<\/span> to support the data needs of the organization.\n\nBusiness architecture<\/span> is the blueprint for organizations to define and organize their business operations. Simply put, business architecture<\/span> involves analyzing, designing, and communicating an organization’s core business capabilities, processes and model<\/span>. The diagram below provides a simple representation of this concept.\n

\"diagram<\/p>\r\n

Diagram 3.1: Business Architecture<\/span> and Data Requirements<\/p>\nThe DCAM<\/span> framework uses ‘business architecture<\/span>’ as a broad term<\/span> for the function<\/span>, group<\/span>(s) or individual(s) that generate the business strategy, objectives, requirements, and needs for data. Data and data management requirements typically can be defined by business capabilities or business processes. Some organizations may not have a formal business architecture<\/span> team, so it is important for Data Management to identify and collaborate with the appropriate business team to drive the identification of data requirements.\n

Definition<\/h3>\r\nBusiness architecture<\/span><\/b> defines the business activities that may be recorded as the business capabilities or as the business process<\/span> requirements that are needed to meet the business objectives. Of specific interest to DCAM<\/span> is the definition of the data requirements that will drive how data will be managed to support the defined business activities. These requirements are used as input to data architecture<\/span>.\n\nData architecture<\/span><\/b> is a bridge between the business process<\/span> requirements for data and the physical execution of that data in the technology infrastructure. It converts the data needs of the business into detailed plans for how data is defined, structured, managed, and controlled. It also outlines the technical requirements for how data is created, used, and shared across business processes. Data architecture<\/span> assigns data to data domains, models data entities, establishes glossaries, taxonomies and ontologies, develops a metadata<\/span> model<\/span>, and articulates needs for data management technology tools.\n\nTechnology architecture<\/span><\/b> takes data and Data Management requirements from Data Architecture<\/span> and applies them to the strategy, design and implementation of the technology infrastructure. Technology Architecture<\/span> defines the platforms and tools needed for optimal support of the business processes, data, and Data Management requirements, including how data is physically acquired, moved, revised and distributed in an efficient manner. Designing for physical data proximity, bandwidth, processing time, privacy protection, backup, recovery and archiving are some important elements of mature technology architecture<\/span>. Technology Architecture<\/span> and Data Architecture<\/span> may develop and share architecture patterns to help achieve this.\n

Scope<\/h3>\r\n
    \r\n \t
  • Establish architecture policy<\/span> and standards to guide business, data, and technology architecture<\/span> as a foundation for data management across the organization<\/li>\r\n \t
  • Establish the roadmap for structured and integrated architecture processes (business, data and technology) to support data management execution across the organization<\/li>\r\n \t
  • Secure the alignment of Data Management with business, data and technology architecture<\/span>, and strategy.<\/li>\r\n \t
  • Design and implement sustainable data architecture<\/span> processes<\/i> with due collaboration to address the data and data management requirements as defined as outputs from the business architecture<\/span> process<\/span><\/i>.<\/li>\r\n \t
  • Define the data architecture<\/span> approach to define and design data architecture<\/span> to achieve the business objectives and needs for data.<\/li>\r\n \t
  • Identify and inventory the organization’s data needed to support the business requirements.<\/li>\r\n \t
  • Develop and validate data domains<\/i>, data models, authoritative sources, and provisioning points<\/i>.<\/li>\r\n \t
  • Ensure that Business Architecture<\/span>, Data Architecture<\/span> and Technology Architecture<\/span> governance is integrated in the Data Governance structures and aligned with business and technology governance activities.<\/li>\r\n<\/ul>\r\n

    Value Proposition<\/h3>\nOrganizations that implement an integrated architecture capability as a foundation for Data Management are more effectively positioned to support strategic and tactical business objectives more powerfully for business gain. Business architecture<\/span> articulates the nature, purpose, criticality, and business benefits of curated data assets for the identified business processes to facilitate revenue generation, risk mitigation and cost containment from leveraging those assets. The formalized data and data management requirements clarify the business rules around data provision and use for each process<\/span>, including regulatory obligations and modern analytics needs. The integration of business architecture<\/span> with functional and adaptable data architecture<\/span> and technology architecture<\/span> completes the picture, setting foundational blueprints to optimize manual and machine-driven data management. This underpins a high-performing data ecosystem.\n

    Overview<\/h3>\r\nBusiness architecture<\/span><\/b> plays a crucial role in defining and documenting the organization’s business capability and processing requirements for data. These outputs serve as critical inputs for data architecture<\/span>, ensuring its alignment with technology architecture<\/span> and the organization’s strategic data needs and business objectives. The effective integration of business, data, and technology architecture—through clearly defined inputs and outputs, role responsibilities, collaboration, and governance controls—is essential for architecture to effectively support data management.\n\nData architecture<\/span><\/b> oversees consistency<\/span> in defining, managing, and utilizing data across an organization by aligning business and technology teams in data governance and sustainable data management. It bridges business data requirements with technology infrastructure, enabling structured data production, provisioning, and consumption. By providing blueprints for secure, scalable, and efficient data management, it supports adaptable platforms, applications, and infrastructure while ensuring accessibility of data catalogs and metadata<\/span>. Strong governance frameworks and flexible toolsets maintain data integrity and responsible data use, while proper alignment with technology architecture<\/span> enhances performance, cost efficiency, and long-term scalability.\n\nTechnology architecture<\/span><\/b> translates data architecture<\/span> into physical data repositories, platforms, and tools that optimize security, storage, distribution, and processing speed. It must remain flexible to accommodate evolving business needs, including regulatory requirements and organizational stress conditions. As businesses increasingly adopt AI-driven data management solutions, architecture plays a critical role in structuring metadata<\/span> and enabling efficient data discovery. Well-designed architecture supports emerging technologies, ensuring that data remains an asset for innovation and decision-making. Data Architecture<\/span> offers a design framework for providing well-curated descriptive information and metadata<\/span> to facilitate efficient discovery and access to data. Additionally, AI technologies can directly manage data, and architecture should be structured to support this capability.\n

    Core Questions<\/h3>\r\n
      \r\n \t
    • Are business stakeholders driving data requirements for their business process<\/span>(es)?<\/li>\r\n \t
    • Are governance procedures in place to ensure adherence to established architecture standards?<\/li>\r\n \t
    • Is adherence to architecture standards enforceable?<\/li>\r\n \t
    • Is technology architecture<\/span> driven by business process<\/span> and data architecture<\/span> requirements?<\/li>\r\n \t
    • Are policies or standards in place that require integration of the business, data and technology architecture<\/span>?<\/li>\r\n<\/ul>\r\n

      Core Artifacts<\/h3>\nThe following are the core artifacts required to execute effective Business, Data & Technology Architecture<\/span> capabilities. Items with an ‘*’ link to published best practice guidelines.\n
        \r\n \t
      • Business Architecture<\/span> Policy<\/span> (data related)<\/li>\r\n \t
      • Data Architecture<\/span> Policy<\/span><\/li>\r\n \t
      • Technology Architecture<\/span> Policy<\/span> (data related)<\/li>\r\n \t
      • Business Architecture<\/span>, Data Architecture<\/span>, Technology Architecture<\/span> Policy<\/span> Alignment Matrix<\/li>\r\n \t
      • Business Data Requirements<\/li>\r\n \t
      • Business Element<\/span> – Data Element<\/span> Model<\/span>*<\/li>\r\n \t
      • Data Architecture<\/span> Approach<\/li>\r\n \t
      • Data Domain<\/span> Inventory Registry<\/li>\r\n \t
      • Data Asset<\/span> Inventory<\/li>\r\n \t
      • Data Model<\/span> Inventory<\/li>\r\n \t
      • Data Storage Criteria, Strategy, & Roadmap<\/li>\r\n \t
      • Data Management Tool Strategy & Roadmap<\/li>\r\n<\/ul>\r\n\r\n\r\n<\/div>\r\n<\/div>\r\n\r\n
        \r\n\r\n

        3.1 Business Architecture<\/h3>\r\n<\/div>\r\n
        \r\n
        \n\nThe Data Management initiative must be engaged with the Business Architecture<\/span> Team for two primary activities:\n
          \r\n \t
        1. Each business capability or process<\/span> must define data requirements (i.e. inputs and outputs) and<\/li>\r\n \t
        2. Business Architecture<\/span> must collaborate with Data Management and Data Architecture<\/span> to support mutual governance and policy<\/span>.<\/li>\r\n<\/ol>\nThe Business Architecture<\/span> Team supports the design and implementation of the capabilities and processes needed for business functions. While not all organizations have a team called "Business Architecture<\/span>", most have groups responsible for these activities, even if they are called something else. It is critical that the Data Management Organization identify and collaborate with the appropriate team(s) to define data requirements based on business needs and objectives.\n\nGathering comprehensive data requirements is essential as data management collaborates with the business. The following areas should be considered when defining complete data requirements:\n\n

          \"diagram<\/p>\r\n

          Diagram 3.2: Architecture Table<\/p>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n<\/div>\r\n\r\n

          \r\n\r\n

          3.1.1 Business Architecture Definition of Data Requirements<\/h3>\r\n<\/div>\r\n
          \r\n
          \r\n
          Description<\/h5>\nThe Data Management initiative must be engaged with the business architecture<\/span> of the organization to support the identification of data requirements based on business needs.\n
          Objectives<\/h5>\r\n
            \r\n \t
          • Define data requirements as (e.g., inputs and outputs) of each business capability or process<\/span>.<\/li>\r\n \t
          • Collaborate with Data Architecture<\/span> and Business Architecture<\/span> functions to collect business capability or process<\/span> data requirements.<\/li>\r\n<\/ul>\r\n
            Advice<\/h5>\nThe Data Management initiative along with Data Architecture<\/span> must collaborate with Business Architecture<\/span> and business subject matter experts to define requirements for data. A foundational activity is to identify the types of data required to execute the identified business capability or processes. Data Architecture<\/span> will then translate the business’s functional data requirements into a complete set of operational data requirements. This process<\/span> must support:\n
              \r\n \t
            • Alignment of the data to approved data models<\/li>\r\n \t
            • Assignment of the data to business or operational domains with related requirements, rules and constraints<\/li>\r\n \t
            • Development and cataloguing of related metadata<\/span> to communicate meaning, context, and any applicable business rule<\/span> constraints<\/li>\r\n \t
            • Identification of any use of data restrictions which may be due to data-licensing constraints, privacy regulations, data sovereignty, regulatory considerations, or adherence to the organization’s ethical policies<\/li>\r\n<\/ul>\r\n
              Questions<\/h5>\r\n
                \r\n \t
              • Are data requirements documented and managed?<\/li>\r\n \t
              • Are the Data Management initiative, Data Architecture<\/span> and Business Architecture<\/span> collaborating to define data requirements?<\/li>\r\n<\/ul>\r\n
                Artifacts<\/h5>\r\n
                  \r\n \t
                • Business Data Requirements, including rules and restrictions for data use<\/li>\r\n \t
                • Requirements to Models Matrix<\/li>\r\n<\/ul>\r\n
                  Scoring<\/h5>\r\n
                  \r\n
                  \r\n
                  \r\n
                  \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                  \n\nNo formal capture of Business Architecture<\/span> Data Requirements exists.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                  \r\n
                  \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                  \n\nNo formal capture of Business Architecture<\/span> Data Requirements exists, but the need is recognized, and the development is being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                  \r\n
                  \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                  \n\nA formal approach for capturing Business Architecture<\/span> Data Requirements is being developed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                  \r\n
                  \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                  \n\nA formal approach for capturing Business Architecture<\/span> Data Requirements is defined and validated by directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                  \r\n
                  \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                  \n\nA formal approach for capturing Business Architecture<\/span> Data Requirements is established, recognized, and followed by stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                  \r\n
                  \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                  \n\nA formal approach for capturing Business Architecture<\/span> Data Requirements is established as part of business-as-usual practice with regular assessments of the efficacy of the process<\/span>.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n<\/div>\r\n\r\n
                  \r\n\r\n

                  3.1.2 Identification and Prioritization of Key Data Elements<\/h3>\r\n<\/div>\r\n\r\n
                  \r\n
                  \r\n
                  Description<\/h5>\nData Management must be engaged with the business and data architecture<\/span> teams to support the identification and prioritization of data elements based on the requirements, needs, and objectives of the business.\n
                  Objectives<\/h5>\r\n
                    \r\n \t
                  • Identify and prioritize data elements in support of business needs.<\/li>\r\n \t
                  • Establish standard<\/span> for characteristics and criteria used to determine prioritization of data elements.<\/li>\r\n<\/ul>\r\n
                    Advice<\/h5>\nOrganizations rely on vast amounts of data, but not all data is of equal importance. The goal for an organization is to establish the standard<\/span> characteristics and criteria that are used to prioritize data elements that are impactful to business operations. The data elements should be identified, communicated and managed to organization standards. Often, the most important data elements are referred to as critical data elements, where criticality of data to a business process<\/span> is used to drive the degree of rigor (and resources) applied in managing the data. Requiring data quality<\/span> checks, data lineage<\/span> support, data governance, or more security on use and access can be resource-intensive. Prioritization of the data is an important determinant of what constitutes the most efficient deployment of those resources.\n\nMost organizations develop a classification approach for data elements based on a binary “is-critical\/is not critical” determination. However, complex ecosystems may require multiple tiers of criticality. T-shirt sizing (high, medium, low) or numbered tiers of criticality may be more appropriate in such environments. Regardless of the number of criticality tiers, most approaches consider criteria such as impact on business functions, legal, compliance, security and privacy requirements to drive classification. A well-defined data element<\/span> classification approach ensures that an organization’s data is maintained with standards for ownership, quality, consistency<\/span>, security, and governance to enhance data reliability and operational efficiency.\n
                    Questions<\/h5>\r\n
                      \r\n \t
                    • Does the organization recognize that not all data is of equal importance?<\/li>\r\n \t
                    • Is data classified against a standard<\/span> set of characteristics and criteria to determine levels of “business criticality” or “data standards applied”?<\/li>\r\n \t
                    • Are the levels of “business criticality” supported by standard<\/span> of treatment expectations?<\/li>\r\n \t
                    • Is there an inventory of data elements and their associated “business criticality”?<\/li>\r\n \t
                    • Are the business, data and technology teams collaborating in applying the data element<\/span> prioritization approach to daily practices (quality, data governance, data management operations)?<\/li>\r\n<\/ul>\r\n
                      Artifacts<\/h5>\r\n
                        \r\n \t
                      • Inventory of “business critical” data elements<\/li>\r\n \t
                      • Standard<\/span> classification for key data elements<\/li>\r\n<\/ul>\r\n
                        Scoring<\/h5>\r\n
                        \r\n
                        \r\n
                        \r\n
                        \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                        \r\n\r\nNo formal prioritization of data elements exists.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                        \r\n
                        \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                        \r\n\r\nNo formal prioritization of data elements exists, but the need is recognized, and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                        \r\n
                        \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                        \r\n\r\nA formal approach for the prioritization of data elements is being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                        \r\n
                        \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                        \r\n\r\nA formal approach for the prioritization of data elements is defined and validated by directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                        \r\n
                        \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                        \r\n\r\nA formal approach for the prioritization of data elements is established, recognized and followed by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                        \r\n
                        \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                        \n\nA formal approach for the prioritization of data elements is established as part of business-as-usual practice with regular assessments of the efficacy of the process<\/span>.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n<\/div>\r\n\r\n
                        \r\n\r\n

                        3.1.3 Data Architecture Governance Aligned with Business Architecture Governance<\/h3>\r\n<\/div>\r\n\r\n
                        \r\n
                        \r\n
                        Description<\/h5>\nThe alignment of Data Architecture<\/span> and Business Architecture<\/span> governance involves a common understanding of holistic data requirements to design a flexible and scalable data architecture<\/span>, as well as appropriately managing changes in business needs within the data architecture<\/span> and monitoring it in support of business requirements and objectives.\n
                        Objectives<\/h5>\r\n
                          \r\n \t
                        • Align Data Architecture<\/span> governance with Business Architecture<\/span> governance to ensure proper design, management, and monitoring of the data architecture<\/span> against business needs.<\/li>\r\n<\/ul>\r\n
                          Advice<\/h5>\nThe goal of this governance alignment is to ensure that the architecture teams work collaboratively in defining, capturing, and supporting the data needs of the business. Both data architects and business analysts should drive the design of data architecture<\/span>. Business analysts will provide insights into essential data for business operations and strategic initiatives while data architects will provide knowledge of how the data is best structured to support the business requirements. Working collaboratively, they can drive data architecture<\/span> that will meet current needs while simultaneously anticipating future demands.\n\nWhile effective design can minimize the need to modify the data architecture<\/span> when the business environment changes, some business factors cannot be anticipated. Again, a close collaboration between business and data architects will help to minimize disruption and to enhance the effectiveness of the updated data architecture<\/span>.\n\nOnce the data architecture<\/span> has been aligned with the business goals, it is important to continually monitor the efficacy of the architecture. Business analysts can assist in establishing measures to track whether the data architecture<\/span> continues to meet business objectives. Such ongoing evaluation helps ensure the data architecture<\/span> remains optimally effective over time.\n
                          Questions<\/h5>\r\n
                            \r\n \t
                          • Are Business Architecture<\/span> and Data Architecture<\/span> governance collaborating in support of meeting business data needs?<\/li>\r\n \t
                          • Are Business Architecture<\/span> and Data Architecture<\/span> governance participating in Data Management governance activities and aligned with policies and standards?<\/li>\r\n \t
                          • Have Business Architecture<\/span> and Data Architecture<\/span> governance established a regular cadence and communication plan?<\/li>\r\n \t
                          • Are Business Architecture<\/span> and Data Architecture<\/span> governance aligned with Data Management initiative standards for data requirements identification?<\/li>\r\n<\/ul>\r\n
                            Artifacts<\/h5>\r\n
                              \r\n \t
                            • Data Requirements aligned to business capability or process<\/span><\/li>\r\n \t
                            • Business Architecture<\/span> and Data Architecture<\/span> governance meeting schedules, minutes and communications<\/li>\r\n \t
                            • Business Architecture<\/span> and Data Architecture<\/span> governance structure<\/li>\r\n<\/ul>\r\n
                              Scoring<\/h5>\r\n
                              \r\n
                              \r\n
                              \r\n
                              \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                              \n\nData Architecture<\/span> governance is not formally aligned with Business Architecture<\/span> governance.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                              \r\n
                              \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                              \n\nData Architecture<\/span> governance is not formally aligned with Business Architecture<\/span> governance, but the need for alignment is recognized and the development is being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                              \r\n
                              \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                              \n\nThe alignment of Data Architecture<\/span> & Business Architecture<\/span> governance is being developed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                              \r\n
                              \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                              \n\nData Architecture<\/span> governance and Business Architecture<\/span> governance are formally aligned in a manner that has been validated by directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                              \r\n
                              \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                              \n\nData Architecture<\/span> governance and Business Architecture<\/span> governance are actively collaborating.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                              \r\n
                              \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                              \n\nData Architecture<\/span> governance and Business Architecture<\/span> governance are aligned as part of business-as-usual practice with regular reviews of the efficacy of the collaboration routines.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n<\/div>\r\n\r\n
                              \r\n\r\n

                              3.2 Data Architecture Approach<\/h3>\r\n<\/div>\r\n
                              \r\n
                              \n\nThe Data Architecture<\/span> Approach and Plan must be created to support the unique characteristics and structures of the organization. Roles and responsibilities across the stakeholders must be established with consideration for the operational processes in place.\n\n\n\n<\/div>\r\n<\/div>\r\n\r\n
                              \r\n\r\n

                              3.2.1 Data Architecture Approach and Plan<\/h3>\r\n<\/div>\r\n\r\n
                              \r\n
                              \r\n
                              Description<\/h5>\nThe Data Architecture<\/span> Approach and Plan must align with the objectives of the Data Management Strategy in support of the business needs and objectives. Once established, Data Architecture<\/span> must be formally empowered by senior management and its role communicated to all stakeholders.\n
                              Objectives<\/h5>\r\n
                                \r\n \t
                              • Establish the formal Data Architecture<\/span> Approach and Plan in support of the Data Management Strategy.<\/li>\r\n \t
                              • Ensure alignment of stakeholder<\/span> plans and roadmaps with the Data Architecture<\/span> Approach and Plan.<\/li>\r\n \t
                              • Ensure collaboration with Business Architecture<\/span>, Data Management, and Technology Architecture<\/span>.<\/li>\r\n<\/ul>\r\n
                                Advice<\/h5>\nData Architecture<\/span> serves as a crucial link between business and technology stakeholders within the Data Management initiative. Regardless of whether the Data Architecture function<\/span> is organizationally aligned with the business or the technology sector, its essential role as an intermediary between these two stakeholder<\/span> groups must be acknowledged. There is sometimes a misconception that data architecture<\/span> is merely a subset of technology architecture<\/span>. However, successful data architecture<\/span> necessitates the integration of both business architecture<\/span> and technology architecture<\/span> expertise.\n
                                Questions<\/h5>\r\n
                                  \r\n \t
                                • Is there a Data Architecture<\/span> Approach and plan in place?<\/li>\r\n \t
                                • Is the Data Architecture<\/span> Approach aligned to the Data Management Strategy?<\/li>\r\n \t
                                • Has the Data Architecture<\/span> Approach been formally communicated to Data Management stakeholders?<\/li>\r\n \t
                                • Has executive management demonstrated its support for Data Architecture<\/span>?<\/li>\r\n \t
                                • Has this authority been communicated to stakeholders?<\/li>\r\n<\/ul>\r\n
                                  Artifacts<\/h5>\r\n
                                    \r\n \t
                                  • Data Architecture<\/span> Approach and Plan<\/li>\r\n \t
                                  • Communications of Data Architecture<\/span> responsibilities and support<\/li>\r\n<\/ul>\r\n
                                    Scoring<\/h5>\r\n
                                    \r\n
                                    \r\n
                                    \r\n
                                    \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                    \n\nNo formal Data Architecture<\/span> Approach & Plan exists.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                    \r\n
                                    \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                    \n\nNo formal Data Architecture<\/span> Approach & Plan exists, but the need is recognized, and the development is being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                    \r\n
                                    \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                    \n\nThe formal Data Architecture<\/span> Approach & Plan is being developed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                    \r\n
                                    \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                    \n\nThe formal Data Architecture<\/span> Approach & Plan is defined and has been validated by the directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                    \r\n
                                    \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                    \n\nThe formal Data Architecture<\/span> Approach & Plan is established and understood across the organization and is being followed by the stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                    \r\n
                                    \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                    \n\nThe formal Data Architecture<\/span> Approach & Plan is established as part of business-as-usual practice with a regular assessment of efficacy and relevance.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                    \r\n\r\n

                                    3.2.2 Data Architecture Roles and Responsibilities<\/h3>\r\n<\/div>\r\n\r\n
                                    \r\n
                                    \r\n
                                    Description<\/h5>\nEffective Data Architecture<\/span> requires clear roles for Data Architecture<\/span>, Business Architecture<\/span>, and Technology Architecture<\/span>. Activities involving these disciplines should be integrated into the roles and responsibilities agreed upon by stakeholders.\n
                                    Objectives<\/h5>\r\n
                                      \r\n \t
                                    • Define the roles and responsibilities required for effective Data Architecture<\/span> and collaboration with Business Architecture<\/span> & Technology Architecture<\/span>.<\/li>\r\n \t
                                    • Identify the organizational alignment of Data Architecture<\/span> roles with the other architecture roles that impact Data Management.<\/li>\r\n<\/ul>\r\n
                                      Advice<\/h5>\nWell-defined Data Architecture<\/span> and associated architecture roles are essential to the Data Management initiative. They establish the connection between the data requirements identified by the business architecture<\/span> function<\/span> and the capabilities offered by technology and tooling, as determined by the Technology Architecture function<\/span>. Effective Data Architecture<\/span> requires collaboration and coordination with individuals and teams throughout the organization, and possibly with external parties, as well. The relationships between Data Architecture<\/span> and the Business Architecture<\/span> and Technology Architecture<\/span> functions must be clearly defined and formalized, focusing on activities, roles, and accountability. Documenting accountability using a RACI matrix<\/span> or a similar method is advisable for capturing roles and responsibilities. Staffing for all the roles should align with expectations regarding the scope and volume of work.\n
                                      Questions<\/h5>\r\n
                                        \r\n \t
                                      • Have the roles and responsibilities for Data Architecture<\/span> activities been established?<\/li>\r\n \t
                                      • Is Data Architecture<\/span> appropriately staffed and funded?<\/li>\r\n<\/ul>\r\n
                                        Artifacts<\/h5>\r\n
                                          \r\n \t
                                        • Data Architecture<\/span> roles and responsibilities<\/li>\r\n \t
                                        • Data Architecture<\/span> stakeholder<\/span> identification<\/li>\r\n \t
                                        • RACI matrix<\/span> or other evidence of accountability assignment across the scope of the Business Architecture<\/span>, Data Architecture<\/span> and Technology Architecture<\/span> activities<\/li>\r\n<\/ul>\r\n
                                          Scoring<\/h5>\r\n
                                          \r\n
                                          \r\n
                                          \r\n
                                          \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                          \n\nData Architecture<\/span> Roles & Responsibilities have not been formally defined.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                          \r\n
                                          \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                          \n\nData Architecture<\/span> Roles & Responsibilities have not been formally defined, but the need is recognized, and the development is being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                          \r\n
                                          \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                          \n\nData Architecture<\/span> Roles & Responsibilities are being developed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                          \r\n
                                          \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                          \n\nThe Data Architecture<\/span> Roles & Responsibilities are defined and have been validated by the directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                          \r\n
                                          \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                          \n\nThe Data Architecture<\/span> Roles & Responsibilities are defined and staffed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                          \r\n
                                          \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                          \n\nThe Data Architecture<\/span> roles & responsibilities are defined, staffed, and role definitions are regularly reviewed for efficacy.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                          \r\n\r\n

                                          3.2.3 Data Architecture Processes<\/h3>\r\n<\/div>\r\n\r\n
                                          \r\n
                                          \r\n
                                          Description<\/h5>\nFormal processes have been established for Data Architecture<\/span> activities. These processes must align with Data Management policy<\/span> and standards of the organization. Data Architecture<\/span> should be supported with standard<\/span> tools and associated procedures to perform Data Architecture<\/span> activities.\n
                                          Objectives<\/h5>\r\n
                                            \r\n \t
                                          • Establish formal Data Architecture<\/span> processes in alignment with the Data Management policy<\/span> and standards.<\/li>\r\n \t
                                          • Integrate the Data Architecture<\/span> processes into the overall end-to-end processes of the Data Management initiative.<\/li>\r\n \t
                                          • Identify, schedule and maintain Data Architecture<\/span> meetings and working sessions required for operational support.<\/li>\r\n<\/ul>\r\n
                                            Advice<\/h5>\nThe Data Architecture<\/span> subject matter experts should work with the Data Management Program to design and optimize Data Architecture<\/span> processes. Together they will create and monitor the implementation of the Data Architecture<\/span> processes in alignment to the end-to-end process<\/span> across the full Data Management initiative.\n
                                            Questions<\/h5>\r\n
                                              \r\n \t
                                            • Have formal Data Architecture<\/span> processes been defined and implemented?<\/li>\r\n \t
                                            • Are those processes supported by standards to ensure a common approach?<\/li>\r\n \t
                                            • Do the processes account for the necessary collaboration with Data Management & Business Architecture<\/span>?<\/li>\r\n \t
                                            • Are Data Architecture<\/span> activities part of the normal operational routine of stakeholders?<\/li>\r\n \t
                                            • Are there standing meetings, planning sessions and regular communications about Data Architecture<\/span> initiatives?<\/li>\r\n<\/ul>\r\n
                                              Artifacts<\/h5>\r\n
                                                \r\n \t
                                              • Process<\/span> design artifacts, procedure<\/span> guides or playbooks, and published routines<\/li>\r\n \t
                                              • Process<\/span> performance metrics reports<\/li>\r\n \t
                                              • Meeting minutes, status reports and Data Architecture<\/span> announcements<\/li>\r\n<\/ul>\r\n
                                                Scoring<\/h5>\r\n
                                                \r\n
                                                \r\n
                                                \r\n
                                                \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                \n\nNo formal Data Architecture<\/span> processes exist.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                \r\n
                                                \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                \n\nNo formal Data Architecture<\/span> processes exist, but the need is recognized, and the development is being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                \r\n
                                                \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                \n\nFormal Data Architecture<\/span> processes are being developed and documented.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                \r\n
                                                \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                \n\nData Architecture<\/span> processes are documented and have been validated by the directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                \r\n
                                                \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                \n\nData Architecture<\/span> processes are established, recognized, and followed by stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                \r\n
                                                \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                \n\nData Architecture<\/span> processes are established as part of business-as-usual practice and are regularly reviewed for efficacy.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                \r\n\r\n

                                                3.2.4 Data Management Governance Aligned with Technology Architecture Governance<\/h3>\r\n<\/div>\r\n\r\n
                                                \r\n
                                                \r\n
                                                Description<\/h5>\nThe Data Management Governance must ensure that Data Architecture<\/span> and Technology Architecture<\/span> teams collaborate in governance to align with the organization's overall technology vision and strategy. This includes specific strategies for enterprise-wide platforms, data storage, and data integration infrastructures. Technology Architecture<\/span> governance processes may involve design reviews, as well as permit-to-build, permit-to-use, and permit-to-send approvals.\n
                                                Objectives<\/h5>\r\n
                                                  \r\n \t
                                                • Align Data Management governance structure and policies with the Technology Architecture<\/span> and Data Management strategies.<\/li>\r\n \t
                                                • Ensure all technology development meets the Technology Architecture<\/span> policy<\/span> requirement to follow Data Management policy<\/span> and standards.<\/li>\r\n \t
                                                • Ensure collaboration is driven by organizational requirements, with enhancements and new developments subject to architectural platform design, review, and approval.<\/li>\r\n<\/ul>\r\n
                                                  Advice<\/h5>\nTypically, technology governance is the responsibility of the technology group<\/span>. However, because of the close relationship between the Data Management initiative, Data Architecture<\/span> and technology implementation, it is imperative that Data Management facilitates collaboration with Data Architecture<\/span> and the technology group<\/span>. Together they create, support and enforce technology policy<\/span> and standards that impact the Data Management initiative.\n\nThis collaboration with technology is designed to ensure that implemented solutions align with business needs, that they comply with data restrictions and that they are harmonized with both technical and architectural standards. This collaboration should include design reviews to ensure that technology implementation follows Data Management policy<\/span> and standards and that tollgates are in place to review the technical implementation. This governance should include collaboration on the data related technology platforms and tools that could impact data management activities.\n
                                                  Questions<\/h5>\r\n
                                                    \r\n \t
                                                  • Is Technology Architecture<\/span> governance aligned with Data Architecture<\/span> and Data Management governance?<\/li>\r\n \t
                                                  • Are Data Management initiative and Data Architecture<\/span> involved in the technical design review process<\/span>?<\/li>\r\n \t
                                                  • Are authorizations to build, use and send data in place?<\/li>\r\n \t
                                                  • Are legal and compliance involved in this effort?<\/li>\r\n \t
                                                  • Is Technology Architecture<\/span> policy<\/span> aligned with the Data Management strategy and Data Management policy<\/span>?<\/li>\r\n<\/ul>\r\n
                                                    Artifacts<\/h5>\r\n
                                                      \r\n \t
                                                    • Evidence of governance collaboration such as stakeholder<\/span> meeting agendas, results, and escalation procedures<\/li>\r\n \t
                                                    • Evidence of tollgate review process<\/span>, for example, minutes and meeting outcomes<\/li>\r\n \t
                                                    • Technology Architecture<\/span> policy<\/span><\/li>\r\n \t
                                                    • Data Management policy<\/span><\/li>\r\n \t
                                                    • List of stakeholders and evidence of bi-directional communication on technical review and authorizations<\/li>\r\n<\/ul>\r\n
                                                      Scoring<\/h5>\r\n
                                                      \r\n
                                                      \r\n
                                                      \r\n
                                                      \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                      \n\nData Management governance is not formally aligned with Data Architecture<\/span> or Technology Architecture<\/span> governance.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                      \r\n
                                                      \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                      \n\nData Management governance is not formally aligned with Data Architecture<\/span> or Technology Architecture<\/span> governance, but the need for alignment is recognized and being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                      \r\n
                                                      \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                      \n\nRoutines for aligning Data Management, Data Architecture<\/span> and Technology Architecture<\/span> governance are being developed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                      \r\n
                                                      \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                      \n\nRoutines for aligning Data Management, Data Architecture<\/span> and Technology Architecture<\/span> governance are defined and validated by directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                      \r\n
                                                      \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                      \n\nData Management, Data Architecture<\/span> and Technology Architecture<\/span> governance are formally aligned by means of approved collaboration routines.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                      \r\n
                                                      \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                      \n\nData Management, Data Architecture<\/span> and Technology Architecture<\/span> governance are formally aligned, and the efficacy of this alignment is assessed regularly.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                      \r\n\r\n

                                                      3.3 Data Identification & Classification<\/h3>\r\n<\/div>\r\n
                                                      \r\n
                                                      \r\n\r\nThe activities in this capability must be aligned with the prioritization of data requirements performed in capability 3.1.2. This capability includes two primary activities, identifying and defining the data.\r\n\r\nIdentifying the data includes:<\/b>\r\n
                                                        \r\n \t
                                                      1. Defining the logical data domains and the associated data that is critical to each domain<\/span><\/li>\r\n \t
                                                      2. Mapping of physical data repositories to the logical data domains<\/li>\r\n \t
                                                      3. Cataloguing the data in the repositories<\/li>\r\n<\/ol>\r\nDefining the data includes:<\/b>\r\n
                                                          \r\n \t
                                                        1. Modeling data to reflect core concepts, attributes, and their relationships<\/li>\r\n \t
                                                        2. Describing the data within the context of the business capabilities or processes where the data is used<\/li>\r\n \t
                                                        3. Creating taxonomies and ontologies to document relationships between the data<\/li>\r\n<\/ol>\nThese activities guide identification, definition, organization, and cataloging of data requirements and data designs. Critical data identified during the business architecture<\/span> activities must be described in a way that supports the design and implementation of data repositories and data architecture<\/span>. Additionally, the data architecture<\/span> must ensure that the data is designed in a manner that can be leveraged by the technical architecture to support the business requirements.\n\n\n\n<\/div>\r\n<\/div>\r\n\r\n
                                                          \r\n\r\n

                                                          3.3.1 Data Domains<\/h3>\r\n<\/div>\r\n\r\n
                                                          \r\n
                                                          \r\n
                                                          Description<\/h5>\nA data domain<\/span> is a logical representation of a specific category of data that has been formally designated and named. Data domains are logical constructs that represent the data itself rather than the physical repositories in which that data resides. Identifying domains helps pinpoint the data essential for executing business functions within those domains. Managing data within a domain<\/span> structure helps ensure consistent ownership of shared data and thus minimizes conflicting understanding of what the data represents.\n
                                                          Objectives<\/h5>\r\n
                                                            \r\n \t
                                                          • Involve business process<\/span> subject matter experts in the identification of logical data domains.<\/li>\r\n \t
                                                          • Identify and prioritize data domains.<\/li>\r\n \t
                                                          • Structure logical data domains to contain related data regardless of where the data may be produced in the organization.<\/li>\r\n<\/ul>\r\n
                                                            Advice<\/h5>\nIdentification of data domains must be driven by the business from the perspective of what data is needed to perform the required business functions. This activity will be closely aligned to sub-capabilities that are related to vocabulary \/ glossary management, 4.2.1, and data classification<\/span>, 3.3.4.\n\nData domains are defined to facilitate better understanding of the structure and organization of data that is associated with business or operational functions that curate the data. Defining data domains has benefits including:\n
                                                              \r\n \t
                                                            • Forming a basis for communication and activities in a business context<\/li>\r\n \t
                                                            • Supporting coordination between Business Architecture<\/span>, Data Management\/Data Architecture<\/span> and Technology Architecture<\/span> around common subjects or themes<\/li>\r\n \t
                                                            • Facilitating consistent shared meaning and alignment around common business \/ operational concepts<\/li>\r\n<\/ul>\nThe overall goal is to ensure the proper use of data and to get stakeholders to think about Data Management in terms of data content concepts rather than physical database repositories. All this needs to be based on an understanding of how the business functions operate. Once the logical data domains are defined, they must be described using ontologies, taxonomies, data models, or other relevant constructs, and mapped to their physical locations.\n\nData 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<\/span> critical business processes. Metadata<\/span> should be treated as a distinct data domain<\/span> managed and maintained by the Data Management organization using quality standards comparable to those used for business domains.\n
                                                              Questions<\/h5>\r\n
                                                                \r\n \t
                                                              • Has the business domain<\/span> owner and the Data Architecture function<\/span> been involved in identifying the authoritative data domains?<\/li>\r\n \t
                                                              • Are appropriate business functions represented in the discussion?<\/li>\r\n \t
                                                              • Is the distinction between data domains and data repositories clear?<\/li>\r\n<\/ul>\r\n
                                                                Artifacts<\/h5>\r\n
                                                                  \r\n \t
                                                                • Policy<\/span> indicating what data domains are and how they are to be used<\/li>\r\n \t
                                                                • Criteria for determination of data domains<\/li>\r\n \t
                                                                • Inventory of data domains<\/li>\r\n \t
                                                                • List of stakeholders and evidence of bi-directional communication<\/li>\r\n<\/ul>\r\n
                                                                  Scoring<\/h5>\r\n
                                                                  \r\n
                                                                  \r\n
                                                                  \r\n
                                                                  \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n\r\nLogical data domains have not been identified in a consistent manner.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n
                                                                  \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n\r\nLogical data domains have not been identified in a consistent manner, but the need is recognized and defining the approach is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n
                                                                  \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n\r\nA comprehensive list of logical data domains is being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n
                                                                  \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n\r\nLogical data domains have been defined and validated by directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n
                                                                  \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n\r\nLogical data domains are established, recognized and used by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n
                                                                  \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                  \n\nLogical data domains are established as part of business-as-usual practice and are regularly reviewed for completeness<\/span> and consistency<\/span>.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                  \r\n\r\n

                                                                  3.3.2 Physical Data Inventory and Alignment<\/h3>\r\n<\/div>\r\n\r\n
                                                                  \r\n
                                                                  \r\n
                                                                  Description<\/h5>\r\nEssential to the data domains are physical repositories of data that must be mapped to the data domains. The physical repositories may include application databases, spreadsheets, data warehouses \/ marts, data lakes, streaming data or data stored in cloud services, and particularly, systems of record and archives.\r\n
                                                                  Objectives<\/h5>\r\n
                                                                    \r\n \t
                                                                  • Create and maintain an inventory of physical data repositories.<\/li>\r\n \t
                                                                  • Map physical repositories to data domains.<\/li>\r\n<\/ul>\r\n
                                                                    Advice<\/h5>\nThe data elements in any data domain<\/span> need to be mapped to where the data physically resides. The first step is the creation of the inventory of data repositories. For this activity, it doesn’t matter where the content resides; data may be external, streaming, master\/slave and cloud based. What is important is that the repositories are inventoried and the data within them is mapped to the identified and approved data domains.\n\nNote that the mapping of repositories to domains will not necessarily be one-to-one. A single repository may contain data from two or more domains and a single domain<\/span> may be instantiated in multiple repositories. This latter case is especially likely when a data domain<\/span> represents data that is shared widely across the organization or where the organization is sufficiently complex requiring the existence of multiple versions of domains.\n
                                                                    Questions<\/h5>\r\n
                                                                      \r\n \t
                                                                    • Has the inventory of data repositories been compiled and verified?<\/li>\r\n \t
                                                                    • Have the identified and approved data domains been mapped to their physical location?<\/li>\r\n<\/ul>\r\n
                                                                      Artifacts<\/h5>\r\n
                                                                        \r\n \t
                                                                      • Inventory of data repositories<\/li>\r\n \t
                                                                      • Mapping of identified and approved data domains to the physical location<\/li>\r\n<\/ul>\r\n
                                                                        Scoring<\/h5>\r\n
                                                                        \r\n
                                                                        \r\n
                                                                        \r\n
                                                                        \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n\r\nThere is no comprehensive inventory of physical repositories of data.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n
                                                                        \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n\r\nThere is no comprehensive inventory of physical repositories of data, but the need is recognized, and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n
                                                                        \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                        \n\nA comprehensive inventory of physical repositories of data is being developed.\n\nThe mapping of repositories to domains is in process<\/span>.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n
                                                                        \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n\r\nA comprehensive inventory of physical repositories of data is defined, and the mapping of repositories to domains is validated by directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n
                                                                        \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n\r\nThe inventory of physical repositories of data and related mapping is established, recognized and used by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n
                                                                        \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                        \n\nThe inventory of physical repositories of data and related mapping is established as part of business-as-usual practice. The accuracy<\/span> and relevance of this repository is assessed regularly and updated as needed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                        \r\n\r\n

                                                                        3.3.3 Enterprise Data Entities<\/h3>\r\n<\/div>\r\n\r\n
                                                                        \r\n
                                                                        \r\n
                                                                        Description<\/h5>\nEnterprise<\/span> data domains and their key data elements must be clearly defined, modeled, and documented to capture core data relationships and ensure alignment to business requirements and process<\/span>. Standard<\/span> enterprise<\/span> entity models should be mandated by data management policies.\n
                                                                        Objectives<\/h5>\r\n
                                                                          \r\n \t
                                                                        • Create comprehensive models of key enterprise<\/span> data.<\/li>\r\n \t
                                                                        • Capture and document data object relationships.<\/li>\r\n \t
                                                                        • Develop enterprise<\/span> entity definitions and models in support of business capabilities, processes and requirements.<\/li>\r\n<\/ul>\r\n
                                                                          Advice<\/h5>\r\nData modeling practices vary depending on an organization’s unique business challenges and the technical architecture or data platform decisions it has made. While traditionally associated with structuring data for relational database management systems (RDBMS), modern architectures—such as data lakes, NoSQL, and graph databases—have shifted the role and methods of data modeling. These newer technologies often do not require the same rigid modeling approach.\r\n\r\nNonetheless, the organization of data to support business requirements remains essential. From a management—not implementation—perspective, organizations typically mandate the creation of conceptual and logical data models to capture business-relevant data relationships.\r\n
                                                                            \r\n \t
                                                                          • Conceptual Data Models:<\/b> A high-level simplified data model<\/span> used to express data concepts important to the business process<\/span>. Designed by data modelers to communicate with business process<\/span> owners to ensure high-level agreement on core data concepts.<\/li>\r\n \t
                                                                          • Logical Data Models:<\/b> These are more detailed data models that identify the data attributes and relationships required to support the business process<\/span>, independent of any technology or solution. These models may be influenced by, if not necessarily descriptive of, the organization's existing technology stack and technical architecture, and intended to be comprehensible to business users.<\/li>\r\n<\/ul>\nIn practice, logical models are often adapted to align with the physical, data, and technical architectures, as these functions collaborate to define models that reflect implementation needs—such as the distinctions between relational and semantic designs (e.g., graph or OWL<\/span>).\n\nOnce data models are established, they must be formally managed and governed by policy<\/span>. This includes requirements for implementation, ongoing maintenance, and usage. Data modeling activities must be integrated into the organization’s change management processes, including change approvals, impact assessments, and controlled implementations.\n
                                                                            Questions<\/h5>\r\n
                                                                              \r\n \t
                                                                            • Have data models defining the entities in the organization-wide data domains been verified by business subject experts?<\/li>\r\n \t
                                                                            • Are data models documented, made accessible and used in existing and new systems?<\/li>\r\n \t
                                                                            • Is the terminology used when creating data models aligned to the organization standard<\/span> glossary(ies), vocabulary, and other metadata<\/span> requirements?<\/li>\r\n \t
                                                                            • Have policies and standards for managing data models been defined, verified, sanctioned, and made accessible?<\/li>\r\n \t
                                                                            • Has governance over data models been aligned with existing change management policies and practice?<\/li>\r\n \t
                                                                            • Has the modeling of terms, definitions, and relationships been verified by business stakeholders and stored as metadata<\/span>?<\/li>\r\n<\/ul>\r\n
                                                                              Artifacts<\/h5>\r\n
                                                                                \r\n \t
                                                                              • Policy<\/span> and standards on use and maintenance of data models<\/li>\r\n \t
                                                                              • Data models<\/li>\r\n \t
                                                                              • List of stakeholders and evidence of bi-directional communication<\/li>\r\n<\/ul>\r\n
                                                                                Scoring<\/h5>\r\n
                                                                                \r\n
                                                                                \r\n
                                                                                \r\n
                                                                                \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                                \n\nEnterprise<\/span> data entities are not defined, modeled or standardized.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                \r\n
                                                                                \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                                \n\nEnterprise<\/span> data entities are not defined, modeled, or standardized, but the need is recognized, and the development is being discussed.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                \r\n
                                                                                \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                                \n\nEnterprise<\/span> data entities are being defined, modeled, and standardized.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                \r\n
                                                                                \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                                \n\nEnterprise<\/span> data entities are defined, modeled, and standardized, and are validated by directly involved stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                \r\n
                                                                                \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                                \n\nEnterprise<\/span> data entities are established, recognized, and used by stakeholders.\n\nEnterprise-level data models are recognized and used by stakeholders.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                \r\n
                                                                                \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                                \n\nEnterprise<\/span> data entities and data modelling are established as part of business-as-usual practice and are regularly reviewed for completeness<\/span>, accuracy<\/span>, and relevance of presentation.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                \r\n\r\n

                                                                                3.3.4 Data Identification and Classification<\/h3>\r\n<\/div>\r\n\r\n
                                                                                \r\n
                                                                                \r\n
                                                                                Description<\/h5>\nData should be identified by consistent, organization-wide identifiers and classified via approved taxonomic schemes to ensure accurate organization of that data. Establishing these schemes and methodologies is essential for defining relationships, standardizing data treatment across the organization, and aggregating data for analytical purposes. Unique and precise identifications and classifications are foundational concepts to ensure data is discoverable, understandable and consumable that aligns with the business and domain<\/span> requirements.\n
                                                                                Objectives<\/h5>\r\n
                                                                                  \r\n \t
                                                                                • Establish and standardize classification schemas considering both structured and unstructured data.<\/li>\r\n \t
                                                                                • Standardize how business elements are identified and cataloged.<\/li>\r\n \t
                                                                                • Formalize and standardize the implementation of reference data<\/span>, classification vocabulary, taxonomies and ontologies considering industry standard<\/span> identifiers.<\/li>\r\n<\/ul>\r\n
                                                                                  Advice<\/h5>\nCommunicating context and semantic meaning is made possible through data classification<\/span> schemas, reference vocabularies, and linked vocabularies organized into taxonomies or ontologies.\n\nEstablishing classification schemas is critical to establishing standard<\/span> approaches supporting data discovery and suitability or “fit for purpose” analysis. Unique and precise identification of data is a foundational capability. It is critical for master (operational) data management, regulatory reporting, risk analysis, as well as laying the foundation for artificial intelligence techniques as adopted.\n\nData identification schemas are required to ensure that data associated with unique entities are readily identifiable when shared across the organization. Such data includes, but is not limited to, customer<\/span> information, legal entity name, and product details. Additionally, correctly identifying and describing data is required for privacy management, information security management, data masking, data encryption, and risk analysis. Unique identification is a foundational tenet of data management that is governed by policy<\/span> and enforced by standards. When reference data<\/span> is used to classify other data, it is important that reference data<\/span> be defined according to formal taxonomic methodologies and that each reference value be identified in a unique manner.\n\nPolicies, procedures, and standards are needed to ensure critical tasks are performed as required; specifically related to identification of key data, the use of classification vocabularies, and application and mapping to taxonomy<\/span> \/ ontology<\/span> schemas.\n\nThe 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 broader data management processes within an organization.\n
                                                                                  Questions<\/h5>\r\n
                                                                                    \r\n \t
                                                                                  • Have unique and precise vocabulary and schemas to describe data been established for all key data?<\/li>\r\n \t
                                                                                  • Has policy<\/span> been developed and approved to ensure these vocabularies and schemas are used in business applications?<\/li>\r\n \t
                                                                                  • Have these standard<\/span> vocabularies been published?<\/li>\r\n \t
                                                                                  • Have appropriate classification schemas and taxonomies been defined?<\/li>\r\n \t
                                                                                  • Has the organization approved and published standards for the vocabularies, schemas, taxonomies and ontologies selected?<\/li>\r\n \t
                                                                                  • Does the organizational metadata<\/span> model<\/span> align and leverage the classification approaches adopted?<\/li>\r\n \t
                                                                                  • Does the data catalog reference the classification approaches in a way that supports data discoverability and understanding the meaning and context of data?<\/li>\r\n<\/ul>\r\n
                                                                                    Artifacts<\/h5>\r\n
                                                                                      \r\n \t
                                                                                    • Policy<\/span> about standard<\/span> vocabulary, classification schemas, taxonomies and ontologies<\/li>\r\n \t
                                                                                    • Inventory of identification, classifications, taxonomies and ontologies standards in use<\/li>\r\n \t
                                                                                    • Cross-referencing and transformation documentation<\/li>\r\n<\/ul>\r\n
                                                                                      Scoring<\/h5>\r\n
                                                                                      \r\n
                                                                                      \r\n
                                                                                      \r\n
                                                                                      \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n\r\nThere are no standardized approaches for the identification or classification of data.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n
                                                                                      \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n\r\nThere are no standardized approaches for the identification or classification of data, but the need is recognized, and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n
                                                                                      \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n\r\nStandardized identification and classification schemes are being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n
                                                                                      \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n\r\nStandardized identification and classification schemes are defined and validated by directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n
                                                                                      \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n\r\nStandardized identification and classification schemes are established, recognized, and used by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n
                                                                                      \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                                      \n\nStandardized identification and classification schemes are established as part of business-as-usual practice with a continuous improvement routine.\n\nThe schemes are regularly reviewed and assessed for completeness<\/span>, accuracy<\/span>, and relevance.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                      \r\n\r\n

                                                                                      3.3.5 Data Cataloging<\/h3>\r\n<\/div>\r\n\r\n
                                                                                      \r\n
                                                                                      \r\n
                                                                                      Description<\/h5>\r\nAfter the physical repositories of data aligned to the data domains are established, the next step is to catalog the data in the repositories.\r\n
                                                                                      Objectives<\/h5>\r\n
                                                                                        \r\n \t
                                                                                      • Establish a catalog of data elements aligned to the data domain<\/span>.<\/li>\r\n \t
                                                                                      • Capture required standard<\/span> metadata<\/span> on the data elements.<\/li>\r\n \t
                                                                                      • Make the data catalog accessible to stakeholders.<\/li>\r\n<\/ul>\r\n
                                                                                        Advice<\/h5>\nThe catalog functions as a tool for communicating the available data within a specific domain<\/span> while also providing essential details that enable consumers to both discover the data and to assess its relevance to their needs.\n\nAny cataloging effort requires an organization to determine which labels should be included. These labels must align with the information necessary to effectively manage key data in accordance with domain<\/span> requirements. This is structured within a metadata<\/span> model<\/span>, which defines the essential attributes needed to comprehensively describe the data and outlines how those attributes are organized. The metadata<\/span> cataloged must align to the established standards defined by the organization.\n
                                                                                        Questions<\/h5>\r\n
                                                                                          \r\n \t
                                                                                        • Have the data elements aligned to a data domain<\/span> been cataloged?<\/li>\r\n \t
                                                                                        • Has the required metadata<\/span> for those data elements been captured and cataloged?<\/li>\r\n \t
                                                                                        • Does the metadata<\/span> captured and cataloged fully describe the data elements at the level required by the relevant domain<\/span>(s)?<\/li>\r\n \t
                                                                                        • Is the metadata<\/span> accessible to stakeholders in a data catalog?<\/li>\r\n<\/ul>\r\n
                                                                                          Artifacts<\/h5>\r\n
                                                                                            \r\n \t
                                                                                          • Data policy<\/span> for metadata<\/span> capture<\/li>\r\n \t
                                                                                          • Data Catalog standards and guidelines<\/li>\r\n \t
                                                                                          • Data Dictionary<\/li>\r\n \t
                                                                                          • Metadata<\/span> Dictionary<\/li>\r\n<\/ul>\r\n
                                                                                            Scoring<\/h5>\r\n
                                                                                            \r\n
                                                                                            \r\n
                                                                                            \r\n
                                                                                            \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\nThere is no formal catalog of physical data.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n
                                                                                            \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\nThere is no formal catalog of physical data, but the need is recognized, and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n
                                                                                            \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\nA formal catalog of physical data is being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n
                                                                                            \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\nA formal catalog of physical data is created and validated by directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n
                                                                                            \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\nThe catalog of physical data is implemented and used by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n
                                                                                            \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                                            \n\nThe catalog of physical data is established as part of business-as-usual practice and is assessed regularly for accuracy<\/span>, relevance, and usability.\n\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\n

                                                                                            3.4 Data Management Supports Technology Architecture<\/h3>\r\n<\/div>\r\n
                                                                                            \r\n
                                                                                            \n\nThe Data Management initiative must work in collaboration with the Technology function<\/span>. Together they define the organization-wide data platform, storage and distribution infrastructures. This collaboration must be supported by mutual governance and policy<\/span>.\n\n\n\n<\/div>\r\n<\/div>\r\n\r\n
                                                                                            \r\n\r\n

                                                                                            3.4.1 Data Management Supports Technology Strategy<\/h3>\r\n<\/div>\r\n\r\n
                                                                                            \r\n
                                                                                            \r\n
                                                                                            Description<\/h5>\nThe role of the Technology function<\/span> is to define and design the technical architecture needed to accommodate data requirements in collaboration with business process<\/span> requirements. The Data Management initiative must work in collaboration with the Technology function<\/span>. Together they define the database strategies, analytics platform approaches, middleware solutions, storage and retention technologies, information security considerations, and all other aspects of the holistic technology infrastructure needed to support the Data Management goals and objectives of the organization.\n
                                                                                            Objectives<\/h5>\r\n
                                                                                              \r\n \t
                                                                                            • Ensure that Data Management is participating collaboratively in the Technology Strategy processes representing Data Management requirements, goals and objectives.<\/li>\r\n \t
                                                                                            • Ensure that consideration is made for the incorporation of the latest technological advancements that relate to data management.<\/li>\r\n<\/ul>\r\n
                                                                                              Advice<\/h5>\nTechnology strategy must ensure that the Data Management initiative can be supported by the Technology function<\/span>. The Technology function<\/span> is responsible for the operation of the technology infrastructure. It does not define data functionality or requirements. Evaluate the Technology Architecture<\/span> strategy with Data Management objectives at the forefront.\n\nAn obligation of the data architecture<\/span> and Technology Architecture<\/span> functions is to evaluate the business objectives and inform the senior business executives of opportunities to deploy innovative technology tools and methods like AI. The review should include opportunities to support Data Management initiative objectives and processes using these tools and methods.\n
                                                                                              Questions<\/h5>\r\n
                                                                                                \r\n \t
                                                                                              • What are the mechanisms to ensure a formal, ongoing partnership between the Data Management Organization and the Technology function<\/span>?<\/li>\r\n \t
                                                                                              • Have the Data Architecture<\/span> and Technology Architecture<\/span> functions evaluated and communicated opportunities to deploy innovative technical tools and methods in support of the defined business objectives?<\/li>\r\n<\/ul>\r\n
                                                                                                Artifacts<\/h5>\r\n
                                                                                                  \r\n \t
                                                                                                • Alignment of Technology Architecture<\/span> and Data Management strategies, inclusive of the Data Architecture<\/span> strategy<\/li>\r\n \t
                                                                                                • List of stakeholders and evidence of bi-directional communication<\/li>\r\n<\/ul>\r\n
                                                                                                  Scoring<\/h5>\r\n
                                                                                                  \r\n
                                                                                                  \r\n
                                                                                                  \r\n
                                                                                                  \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\nData Management is not engaged in the Technology Strategy.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n
                                                                                                  \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\nData Management is not engaged in the Technology Strategy, but the need for engagement is recognized and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n
                                                                                                  \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\nThe approach to engaging Data Management in the Technology Strategy is being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n
                                                                                                  \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\nThe approach to engaging Data Management in the Technology Strategy is defined and has been validated by the directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n
                                                                                                  \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\nData Management is engaged in the Technology Strategy, and this is recognized by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n
                                                                                                  \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\nData Management engagement in the Technology Strategy is established and the approach to this engagement is regularly assessed and reviewed for efficacy and relevance.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                  \r\n\r\n

                                                                                                  3.4.2 Data Management Supports Platform Infrastructure Strategy<\/h3>\r\n<\/div>\r\n\r\n
                                                                                                  \r\n
                                                                                                  \r\n
                                                                                                  Description<\/h5>\nThe Data Management initiative must be engaged with Technology Architecture<\/span> on the platform infrastructure to define and execute a strategy, an execution roadmap, and a governance structure. For a technology strategy to be sustainable it must have a budget commitment over the life of the designed roadmap.\n
                                                                                                  Objectives<\/h5>\r\n
                                                                                                    \r\n \t
                                                                                                  • Ensure Data Management is collaborating with Technology Architecture<\/span> to inform the platform infrastructure strategy of Data Management requirements, goals and objectives.<\/li>\r\n \t
                                                                                                  • Ensure that all enhancements and new developments are subject to review and approval consistent with the defined platform infrastructure strategy and roadmap.<\/li>\r\n<\/ul>\r\n
                                                                                                    Advice<\/h5>\nTechnology Architecture<\/span> is accountable for the platform infrastructure strategy and the associated execution roadmap. The strategy must be coordinated with business requirements for the Database Management Systems organization-wide. The Data Management organization should be a facilitator, providing coordination among the stakeholders to represent these business considerations. Prioritization of requirements is critical.\n\nSome opportunities for innovation in the organization-wide platform infrastructure involve new technology tools and methods. The infrastructure may benefit from the addition of AI, ML, Natural Language Processing (NLP), and knowledge graphs.\n
                                                                                                    Questions<\/h5>\r\n
                                                                                                      \r\n \t
                                                                                                    • What are the mechanisms to ensure coordination among business, data, and technology at the proper levels of the organization?<\/li>\r\n \t
                                                                                                    • What are the mechanisms for coordination and prioritization?<\/li>\r\n<\/ul>\r\n
                                                                                                      Artifacts<\/h5>\r\n
                                                                                                        \r\n \t
                                                                                                      • Platform infrastructure requirements, strategy, and roadmap<\/li>\r\n \t
                                                                                                      • Evidence of alignment with the Data Management Strategy<\/li>\r\n \t
                                                                                                      • Platform Infrastructure policy<\/span> and standards<\/li>\r\n<\/ul>\r\n
                                                                                                        Scoring<\/h5>\r\n
                                                                                                        \r\n
                                                                                                        \r\n
                                                                                                        \r\n
                                                                                                        \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\nData Management is not engaged in organization-wide platform infrastructure matters.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n
                                                                                                        \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\nData Management is not engaged in organization-wide platform infrastructure matters, but the need for engagement is recognized and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n
                                                                                                        \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\nThe approach to engaging Data Management in organization-wide platform infrastructure matters is being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n
                                                                                                        \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\nThe approach to engaging Data Management in organization-wide platform infrastructure matters is defined and has been validated by the directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n
                                                                                                        \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\nData Management is engaged in organization-wide platform infrastructure matters, including definition, roadmap development and approval, and this is recognized by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n
                                                                                                        \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\nData Management engagement in organization-wide platform infrastructure matters and is established, and the approach to this engagement is regularly assessed and reviewed for efficacy and relevance.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                        \r\n\r\n

                                                                                                        3.4.3 Data Management Supports Data Storage Infrastructure Strategy<\/h3>\r\n<\/div>\r\n\r\n
                                                                                                        \r\n
                                                                                                        \r\n
                                                                                                        Description<\/h5>\nThe Data Management initiative must be engaged with Technology Architecture<\/span> in the data storage infrastructure to define and execute a strategy, an execution roadmap and a governance structure. For a technology strategy to be sustainable, it must have a budget commitment over the life of the designed roadmap.\n
                                                                                                        Objectives<\/h5>\r\n
                                                                                                          \r\n \t
                                                                                                        • Ensure Data Management is collaborating with Technology Architecture<\/span> to inform the data storage infrastructure strategy of Data Management requirements, goals, objectives, and policies.<\/li>\r\n \t
                                                                                                        • Ensure that all enhancements and new developments are subject to review and approval consistent with the defined storage management strategy and roadmap.<\/li>\r\n<\/ul>\r\n
                                                                                                          Advice<\/h5>\nTechnology Architecture<\/span> is accountable for the data storage infrastructure strategy and the associated execution roadmap. The strategy must be coordinated with business requirements for activities like archiving capability, legal compliance considerations, retention and defensible destruction of data. The Data Management organization should be a facilitator, providing coordination among the stakeholders to represent these business considerations. Additionally, data storage, archive, and retrieval plans must be coordinated across the various stakeholders (business, data, technology, legal, and compliance). Prioritization of requirements is critical.\n\nSome opportunities for innovation in the organization-wide data storage infrastructure involve new technology tools and methods. Organizations should consider traditional (relational data bases, file systems, block storage), cloud-based (cloud objects, distributed file systems, hybrid and multi-cloud), NoSQL and Big Data (key-value stores, columnar, document, graph and time-series databases), edge and decentralized (edge computing storage, blockchain and decentralized), and in-memory and high-performance storage (RAM based storage, NVMe and SSD storage). There are also new opportunities for data to be encrypted, tokenized, anonymized, or pseudonymized at rest, in transit, and in storage.\n
                                                                                                          Questions<\/h5>\r\n
                                                                                                            \r\n \t
                                                                                                          • What mechanisms are in place to ensure coordination among business, data, and technology at the proper levels of the organization?<\/li>\r\n \t
                                                                                                          • Are additional legal requirements considered in the strategy, including but not limited to, masking, anonymization, and the full complement of personal privacy rights?<\/li>\r\n \t
                                                                                                          • What is the organization’s appetite for cloud data storage services?<\/li>\r\n \t
                                                                                                          • How will the organization manage data reconstruction from an archive?<\/li>\r\n \t
                                                                                                          • What are the mechanisms for coordination and prioritization?<\/li>\r\n<\/ul>\r\n
                                                                                                            Artifacts<\/h5>\r\n
                                                                                                              \r\n \t
                                                                                                            • Storage requirements, strategy, and roadmap<\/li>\r\n \t
                                                                                                            • Evidence of alignment with the Data Management Strategy<\/li>\r\n \t
                                                                                                            • Evidence of collaboration, alignment, socialization, and approval between Data Management and Technology<\/li>\r\n \t
                                                                                                            • Data Storage policy<\/span> and standards<\/li>\r\n \t
                                                                                                            • Evidence of storage consideration in SDLC tollgates at the onset of technology platform enhancements or new development<\/li>\r\n<\/ul>\r\n
                                                                                                              Scoring<\/h5>\r\n
                                                                                                              \r\n
                                                                                                              \r\n
                                                                                                              \r\n
                                                                                                              \r\n\r\nNot Initiated\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\nData Management is not engaged in organization-wide data storage infrastructure matters.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n
                                                                                                              \r\n\r\nConceptual\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\nData Management is not engaged in organization-wide data storage infrastructure matters, but the need for engagement is recognized and the development is being discussed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n
                                                                                                              \r\n\r\nDevelopmental\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\nThe approach to engaging Data Management in organization-wide data storage infrastructure matters is being developed.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n
                                                                                                              \r\n\r\nDefined\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\nThe approach to engaging Data Management in organization-wide data storage infrastructure matters is defined and has been validated by the directly involved stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n
                                                                                                              \r\n\r\nAchieved\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\nData Management is engaged in organization-wide data storage infrastructure matters, including definition, roadmap development and approval, and this is recognized by stakeholders.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n
                                                                                                              \r\n\r\nEnhanced\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\nData Management engagement in organization-wide data storage infrastructure matters and is established, and the approach to this engagement is regularly assessed and reviewed for efficacy and relevance.\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n
                                                                                                              \r\n\r\n

                                                                                                              3.4.4 Data Management Supports Data Integration Infrastructure Strategy<\/h3>\r\n<\/div>\r\n\r\n
                                                                                                              \r\n
                                                                                                              \r\n
                                                                                                              Description<\/h5>\nThe Data Management initiative must be engaged with Technology Architecture<\/span> in the data integration infrastructure to define and execute a strategy, an execution roadmap and a governance structure. For a technology strategy to be sustainable, it must have a budget commitment over the life of the designed roadmap.\n
                                                                                                              Objectives<\/h5>\r\n
                                                                                                                \r\n \t
                                                                                                              • Establish an integrated data integration strategy. Obtain agreement from business, data, and technology senior executive stakeholders.<\/li>\r\n \t
                                                                                                              • Ensure Data Management is collaborating with Technology Architecture<\/span> to inform the data integration infrastructure strategy of Data Management requirements, goals and objectives.<\/li>\r\n \t
                                                                                                              • Ensure that all enhancements and new developments are subject to review and approval consistent with the defined data integration strategy and roadmap.<\/li>\r\n<\/ul>\r\n
                                                                                                                Advice<\/h5>\nTechnology Architecture<\/span> is accountable for the data integration infrastructure strategy and the associated execution roadmap. The strategy must be coordinated with business requirements, and it must consider data access controls, information security restrictions, authoritative data provisioning points, and data as a service. The Data Management Organization should be a facilitator – providing coordination among the stakeholders to represent these business considerations. Prioritization of requirements is critical.\n
                                                                                                                Questions<\/h5>\r\n
                                                                                                                  \r\n \t
                                                                                                                • What are the mechanisms to ensure coordination among business, data, and technology at the proper levels of the organization?<\/li>\r\n \t
                                                                                                                • What are the mechanisms for coordination and prioritization?<\/li>\r\n<\/ul>\r\n
                                                                                                                  Artifacts<\/h5>\r\n