We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Blog: Kelle O'Neal Subscribe to this blog's RSS feed!

Kelle O'Neal

Thanks for joining our data conversation! This blog is an opportunity to share the real life challenges, opportunities and approaches to improving the quality and value of data in your organization. We will write about everything data related from translating "data" speak into "business" speak, to governance models, to the real differences among the myriad software tools available. But there's one catch: we all have to agree to toss out the fluff. That's right, no 30,000 foot, theoretical strategies that leave you wondering how to execute and actually improve performance. Visit regularly to learn from peers and partners on how they are managing and improving data, and we hope you'll also share your views and experiences.

About the author >

As Founder and Managing Partner of First San Francisco Partners, Kelle O’Neal manages specialist data governance and data management consulting services to complex organizations that deliver faster time to results. Kelle can be reached at kelle@firstsanfranciscopartners.com or through the First San Francisco Partners website.

Follow First San Francisco Partners on Twitter at @1stSanFrancsico.

Editor's Note: Find more articles and resources in Kelle's BeyeNETWORK Expert Channel. Be sure to visit today!

A client recently asked me this, and I thought it was a great question!

Data Architecture and Data Governance support each other in a variety of ways, with the mutual goal of creating standards and guidelines to support the enterprise in increasing operational efficiency, decreasing costs and mitigating risk.

Data Governance Supports Data Architecture

There are policies/principles that are designed and enforced by the overall architecture group to ensure best practices are followed for new technology implementations. The Data Governance Team (DGT) can "translate" those policies into business requirements and guidelines and help to enforce them from a business perspective. Education sessions will help the business folks to understand the importance of data architecture and the impact when its guidelines aren't followed. This should help the business in its project planning process as well as set its expectations for what is possible. Without the DGT as a forum, this sort of knowledge transfer only happens on a project-by-project basis and usually only when a request is made that is denied because it doesn't adhere to the data architecture policies/principles.
Data Modeling--an important component of Data Architecture--is also critical to Data Governance. It is rare that the business cares to be involved in data modeling, and the DGT has an important role to play in educating the business on data modeling and translating why data modeling needs to be a reflection of the operational use of data (as well as a reflection of customer engagement, product positioning and other key business operations). The hierarchies and data relationships that the DGT creates to reflect the view of the customer, for example, need to be instantiated in the appropriate data model(s). Without a high-level understanding of data modeling, business people will lack the ability to understand how to translate the operational use of data into the systems that house the data. Essentially, the data model needs to reflect the business model, and the DGT can act as both a translator and a facilitator to ensure that this happens.

Data Architecture Supports Data Governance

Data Architecture provides an understanding of what data exists where and how it travels throughout the organizations and systems. It highlights changes and transformations made as data moves from one system to the next. These data inventory and data flow diagrams provide the information and the tools that the DGT needs in order to properly make decisions regarding data policies and standards. These artifacts also help the DGT perform root cause analysis when data issues are raised by business people, and they help to solve those issues.
The data inventory and data flow diagrams also help to determine what can be measured, when and how. They can help to identify the possible business impacts associated with improving data quality in the systems by understanding who uses the systems and for what purpose--this also helps in creating metrics and measurements. As well, they can help to determine how to measure adherence to standards based on who creates and updates the data in which systems.
Overlaying the data inventory and data flow diagrams with data accountability and ownership is a helpful artifact for everyone in the organization and also helps to determine where gaps in accountability and ownership may lie.
Participants in the DGT may also find these artifacts very useful to take back to their groups and educate their teams about the source and usage of data that they may consider "theirs." In fact, in many instances, key business stakeholders say it would be helpful to understand the data landscape and how data moves across the organization. The DGT has a role in educating the rest of the company on this information and in overlaying that information with the policies and standards that are implemented along the way--all of which is important in ensuring that data is accurate and maintains its integrity throughout its lifecycle.

Do your Data Governance and Data Architecture groups work together? How do you see them supporting one another? I'd love to hear how this works in your organization!

Posted March 26, 2014 5:00 PM
Permalink | 1 Comment |

1 Comment

Your blog on "relationship btw DA and DG" Very nicely illustrated.


Leave a comment