Welcome New Members!

We'd like to welcome our 20 new Professional Members who have joined the chapter in Q2 & Q2 2023. We're thrilled you're here and hope you are enjoying all the perks of membership!

• Allen A
• Alyssa S
• Brandon A
• Devan D
• Emilie A
• Gisella B
• Gurvirender T
• Indira K
• Jason V
• Jon S
• Joseph B
• Lara S
• Lee G
• Linda G
• Martin P
• May C
• Michael B
• Michael P
• Pete G
• Zack R

We also warmly welcome our 60 new Guest Members! We're excited you're here and hope you explore and find a way to connect with our community at an upcoming event.

Primary Data Architecture outcomes include:

• Data storage and processing requirements

• Designs of structures and plans that meet the current and long-term data requirements of the enterprise

Architects seek to design in a way that brings value to the organization. this values comes through an optimal technical footprint, operational and project efficiencies, and the increased ability of the organization to use its data. to get there requires good design, planning, and the ability to ensure that the designs and plans are executed effectively.

To reach these goals, Data Architects define and maintain specifications that:

• Define the current state of data in the organization

• Provide a standard business vocabulary for data and components

• Align Data Architecture with enterprise strategy and business architecture

• Express strategic data requirements

• Outline high-level integrated designs to meet these requirements

• Integrate with overall enterprise architecture roadmap

An overall Data Architecture practice includes:

• Using Data Architecture artifacts (master blueprints) to define data requirements, guide data integration, control data assets, and align data investments with business strategy

• Collaborating with, learning from and influencing various stakeholders that are engaged with improving the business or IT systems development

• Using Data Architecture to establish the semantics of an enterprise, via a common business vocabulary

DAMA-RMC is looking for guest bloggers to be featured on our website, and in our newsletters and social media posts.  This is a great opportunity to grow your network and reach thousands of new contacts sharing your data knowledge and expertise.  Interested bloggers can reach out to Cher Fox, VP of Marketing at MarketingVP@damarmc.org.

Details for submission and publishing are as follows:

1. Guest bloggers will be featured in the members only section of our website.
2. The guest blog and the blogger's contact information can be featured in our emailed monthly newsletter, which reaches about 550 members (pending delivery and approval by the time newsletters release later in the 2nd week of each month)
3. The guest blog and the blogger's contact information will be featured in social media posts on Linked In and Twitter (reaches multiple 1000s of people)
4. The guest blog and the blogger's contact information can be featured in DAMA-RMC Linked In newsletter (pending delivery and approval by the time newsletters release earlier in the 3rd week of each month)
5. There is no compensation for guest blogging.  There is a trade in promotion of you and your contact information to our network.  An additional benefit could be an invitation to speak to our chapter in your area of expertise.
6. When considering topics to submit, please refer to the Knowledge Areas in the DAMA Wheel below.  
7. There is no character limit and longer blogs can certainly be published in multiple parts across weeks or months.
8. Blogs should not be vendor specific. Case studies can mention vendors and should not be a sales pitch of vendor specific features.
9. Submissions should be emailed to Cher Fox, VP of Marketing at MarketingVP@damarmc.org, by the end of the 1st week of each month to be considered and then reviewed/approved by the DAMA board before release.   
10. Submissions should be new content from the blogger and not made available to the general public anywhere else for at least one month after DAMA publishing.

For a range of submission topics, please refer to the DAMA Wheel:

Thank you for your interest in being a guest blogger for DAMA-RMC.

Issue Management is the process for identifying, quantifying, prioritizing, and resolving data governance-related issues, including:

• Authority: Questions regarding decision rights and procedures

• Change management escalations: Issues arising from the change management process

• Compliance: Issues with meeting compliance requirements

• Conflicts: Conflicting policies, procedures, business rules, names, definitions, standards, architecture, data ownerships and conflicting stakeholder interests in data and information

• Conformance: Issue related to conformance to policies, standards, architecture, and procedures

• Contracts: Negotiation and review of data sharing agreements, buying and selling data, and cloud storage

• Data security and identity: Privacy and confidentiality issues, including breach investigations

• Data quality: Detection and resolution of data quality issues, including disasters or security breaches

Many issues can arise locally in Data Stewardship teams. Issues requiring communication and / or escalation must be logged, and may be escalated to the Data Stewardship teams, or higher to the DGC, as shown in this figure. A Data Governance scorecard can be used to identify trends related to issues, such as where within the organization they occur, what their root causes are, etc. Issues that cannot be resolved by the DGC should be escalated to corporate governance and / or management.

Data governance requires control mechanisms and procedures for:

• Identifying, capturing, logging, tracking and updating issues

• Assignment and tracking of action items

• Documenting stakeholder viewpoints and resolution alternatives

• Determining, documenting, and communicating issue resolutions

• Facilitating objective, neutral discussions where all viewpoints are heard

• Escalating issues to higher levels of authority

Data issue management is very important. It builds credibility for the DG team, has direct, positive effects on data consumers, and relieves the burden on production support teams. Solving issue management requires control mechanisms that demonstrate the work effort and impact of resolution.

While developing a basic definition of Data Governance (DG) is easy, creating an operating model that an organization will adopt can be difficult. Consider these areas when constructing an organization's operating model:

• Value of data to the organization: If an organization sells data, obviously DG has a huge business impact. Organizations that use data as a crucial commodity (e.g. Facebook, Amazon) will need an operating model that reflects the role of the data. For organizations where data is an operational lubricant, the form of DG will be less intense.

• Business model: Decentralized business vs. centralized, local vs. international, etc. are factors that influence how business occurs, and therefore, how the DG operating model is defined. Links with specific IT strategy, Data Architecture, and application integration functions should be reflected in the target operating framework design (per previous post on DMBoK Figure 16).

• Cultural factors: Such as acceptance of discipline and adaptability to change. Some organizations will resist the imposition of governance by policy and principle. Governance strategy will need to advocate for an operating model that fits the organizational culture, while still progressing change.

• Impact of regulation: Highly regulated organizations will have a different mindset and operating model of DG than those less regulated. There may be links to the Risk Management group or Legal as well.

Layers of data governance are often part of the solution. This means determining where accountability should reside for stewardship activities, who owns the data, etc. The operating model also defines the interaction between the governance organization and the people responsible for data management projects or initiatives, the engagement of change management activities to introduce this new program, and the model for issue management resolution pathways through governance. This figure shows an example of an operating framework. The example is illustrative. This kind of artifact must be customized to meet the needs of a specific organization.

Part of alignment includes developing organizational touchpoints for Data Governance work. The CDO Organizational Touch Points figure illustrates examples of touch points that support alignment and cohesiveness of an enterprise data governance and data management approach in areas outside the direct authority of the Chief Data Officer.

• Procurements and Contracts: The CDO works with a Vendor/Partner Management or Procurement to develop and enforce standard contract language vis-a-vis data management contracts. These could include Data-as-a-Service (DaaS) and cloud-related procurements, other outsourcing arrangements, third-party development efforts, or content acquisition / licensing deals, and possibly data-centric IT tools acquisitions and upgrades.
• Budget and Funding: If the CDO is not directly in control of all data acquisition-related budgets, then the office can be a focal point for preventing duplicate efforts and ensuring optimizations of acquired data assets.
• Regulatory Compliance: The CDO understands and works within required local, national, and international regulatory environments, and how these impact the organization and their data management activities. Ongoing monitoring is performed to identify and track new and potential impacts and requirements.

• SDLC / development framework: The data governance program identifies control points where enterprise policies, processes, and standards can be developed in the system or application development lifecycles.

The touch points that the CDO influences support the organization's cohesiveness in managing its data, therefore, increasing its nimbleness to use its data. In essence, this is a vision of how DG will be perceived by the organization.

September 2023 Newsletter.pdf

In a centralized model, one Data Governance organization oversees all activities in all subject areas. In a replicated model, the same DG operating model and standards are adopted by each business unit. In a federated model, one Data Governance organization coordinates with multiple Business Units to maintain consistent definitions and standards.

The most formal and mature data management operating model is a centralized one. Here everything is owned by the Data Management Organization. Those involved in governing and managing data report directly to a data management leader who is responsible for Governance, Stewardship, Metadata Management, Data Quality Management, Master and Reference Data Management, Data Architecture, Business Analysis, etc.

The core word in governance is govern. Data governance can be understood in terms of political governance. It includes legislative-like functions (defining policies, standards and the Enterprise Data Architecture), judicial-like functions (issue management and escalation), and executive functions (protecting and serving, administrative responsibilities). To better manage risk, most organizations adopt a representative form of data governance, so that all stakeholders can be heard.

Each organization should adopt a governance model that supports its business strategy and it likely to succeed within its own cultural context. Organizations should also be prepared to evolve that model to meet new challenges. Models differ with respect to their organizational structure, level of formality, and approach to decision-making. Some models are centrally organized, while others are distributed.

Data governance organizations may also have multiple layers to address concerns at different levels within an enterprise - local, divisional, and enterprise-wide. The work of governance is often divided among multiple committees, each with a purpose and level of oversight different from others.

This Figure represents a generic data governance model, with activities at different levels within the organization (vertical axis), as well as separation of governance responsibilities within organizational functions and between technical (IT) and business areas.

Just as an auditor controls financial processes but does not actually executive financial management, data governance ensures data is properly managed without directly executing data management. Data governance represents an inherent separation of duty between oversight and execution.

A data-centric organization values data as an asset and manages data through all phases of its lifecycle, including project development and ongoing operations. To become data-centric, and organization must change the way it translates strategy into action. Data is no longer treated as a by-product of process and applications. Ensuring data is of high quality is a goal of business processes. As organizations strive to make decisions based on insights gained from analytics, effective data management becomes a very high priority.

People tend to conflate data and information technology. To become data-centric, organizations need to think differently and recognize that managing data is different from managing IT. This shift is not easy. Existing culture, with its internal politics, ambiguity about ownership, budgetary competition, and legacy systems, can be a huge obstacle to establishing an enterprise vision of data governance and data management.

While each organization needs to evolve its own principles, those that seek to get more value from their data are likely to share the following:

• Data should be managed as a corporate asset

• Data management best practices should be incented across the organization

• Enterprise data strategy must be directly aligned with overall business strategy

• Data management processes should be continuously improved