SlideShare a Scribd company logo
1 of 40
Download to read offline
Data Governance Team
Data Governance Team
Related terms:
Related terms:
Business Intelligence, Internet of Things, Data Governance, Master Data Manage-
ment, Data Governance Program, Programme Management, Term Definition
Business Intelligence, Internet of Things, Data Governance, Master Data Manage-
ment, Data Governance Program, Programme Management, Term Definition
View all Topics
View all Topics
13.
13.
Term definition example
Term definition example
14. 14.
Term use description (how to and how not to use)
Term use description (how to and how not to use)
15. 15.
Last update date Last update date
16. 16.
Term category, subcategory name (related to taxonomy or subject area) (1 or
many)
Term category, subcategory name (related to taxonomy or subject area) (1 or
many)
17. 17.
Term acronym Term acronym
18. 18.
Term abbreviation Term abbreviation
19. 19.
Related term name (1 or many)
Related term name (1 or many)
20. 20.
Replacement term name
Replacement term name
21. 21.
Managed by business unit
Managed by business unit
22. 22.
Managed by application
Managed by application
23. 23.
Managed by business function
Managed by business function
24. 24.
Data steward name Data steward name
25. 25.
Data steward contact phone, email, location
Data steward contact phone, email, location
26. 26.
Data steward alternate contact phone, email, location
Data steward alternate contact phone, email, location
27. 27.
Term logical business rules
Term logical business rules
28. 28.
Term use restrictions Term use restrictions
29. 29.
Security and compliance rules and restrictions
Security and compliance rules and restrictions
30. 30.
Mapped IT assetsa.Physical column name and table name (1 or many)b.-
Database name/scheme name (1 or many)c.Report name (1 or many)d.Data
integration process name (1 or many)
Mapped IT assetsa.Physical column name and table name (1 or many)b.-
Database name/scheme name (1 or many)c.Report name (1 or many)d.Data
integration process name (1 or many)
31. 31.
Data-quality expectations/profilinga.Column name (1 or many)b.Business
term namec.Date profiledd.Completeness percentagee.Validity percentagef.-
Nonvalid percentage
Data-quality expectations/profilinga.Column name (1 or many)b.Business
term namec.Date profiledd.Completeness percentagee.Validity percentagef.
Nonvalid percentage
3.
3.
Term definition example (can be imbedded in the definition attribute but
we recommend against it)
Term definition example (can be imbedded in the definition attribute but
we recommend against it)
4. 4.
Term acronym Term acronym
5. 5.
Term abbreviation Term abbreviation
6. 6.
Term security and compliance restrictions
Term security and compliance restrictions
7. 7.
Defined by person name (name of the person creating the term definition)
Defined by person name (name of the person creating the term definition)
8. 8.
Data steward name (assuming there is not just one steward)
Data steward name (assuming there is not just one steward)
9. 9.
Data steward contact information (phone, email, location)
Data steward contact information (phone, email, location)
10. 10.
Term logical business rules (business, referential integrity, and quality)
Term logical business rules (business, referential integrity, and quality)
sufficient “air coverage” (i.e., be introduced or initially sponsored by a respected
executive). If an MDM project is initiating DG, then the project sponsor needs to
kick this off.
sufficient “air coverage” (i.e., be introduced or initially sponsored by a respected
executive). If an MDM project is initiating DG, then the project sponsor needs to
kick this off.
The Agile EDW Subrelease Cycle
departments will maintain their own data marts because they cannot understand
or trust the information in the enterprise data warehouse. Third, changing the data
warehouse for a new requirement takes months just to research and plan because
the impact on master data elements cannot be readily assessed [Eckerson 2001].
as an asset [Ladley 2010]. EIM is comprised to two complementary practices: data
governance and information management.
as an asset [Ladley 2010]. EIM is comprised to two complementary practices: data
governance and information management.
As shown in Figure 19.1, an informal way to describe the division of labor between
these two practices is that “data governance is defining and planning the right
things to do, information management is actually doing those things right” [Ladley
2013]. Data governance is the business-led portion of the EIM effort. Information
management comprises the systems design and implementation work that IT must
provide to achieve the data governance the business has defined.
As shown in Figure 19.1, an informal way to describe the division of labor between
these two practices is that “data governance is defining and planning the right
things to do, information management is actually doing those things right” [Ladley
2013]. Data governance is the business-led portion of the EIM effort. Information
management comprises the systems design and implementation work that IT must
provide to achieve the data governance the business has defined.
Figure 19.1. Enterprise information management includes a business-led data gov-
ernannce program and an IT-led information managment program.
Figure 19.1. Enterprise information management includes a business-led data gov-
ernannce program and an IT-led information managment program.
In his 2010 book, John Ladley provides an iterative approach for the business side
of a company to pursue when it decides to invest in EIM [Ladley 2010]. I believe this
cycle provides a reliable, step-by-step process that companies should follow in order
to achieve effective data governance. During the previous chapters on requirements
management, this book described an enterprise-capable requirements manage-
ment (ERM) process for defining the application an agile EDW team intends to build.
This project definition process started with sponsor concept briefings, included a
vision document, and resulted in a current estimate. Not only does this ERM value
chain of artifacts enable a team to move smoothly into the development iterations of
a subrelease cycle but also it links quite well with the EIM process Ladley proposes,
as shown in Figure 19.2. Because this linkage is so extensive, the agile EDM project
startup process provides a strong sequencing for the information management
activities needed to support a company’s data governance program, should one exist.
I summarize the complementary nature of these two processes level by level, as each
progresses through its own particular form of planning, approaching the moment
when a team can execute upon those plans. The dividing line between steps 5 and 6
in Figure 19.2 indicates where both of these linked cycles transition from planning
activities to putting their plans into action.
In his 2010 book, John Ladley provides an iterative approach for the business side
of a company to pursue when it decides to invest in EIM [Ladley 2010]. I believe this
cycle provides a reliable, step-by-step process that companies should follow in order
to achieve effective data governance. During the previous chapters on requirements
management, this book described an enterprise-capable requirements manage-
ment (ERM) process for defining the application an agile EDW team intends to build.
This project definition process started with sponsor concept briefings, included a
vision document, and resulted in a current estimate. Not only does this ERM value
chain of artifacts enable a team to move smoothly into the development iterations of
a subrelease cycle but also it links quite well with the EIM process Ladley proposes,
as shown in Figure 19.2. Because this linkage is so extensive, the agile EDM project
startup process provides a strong sequencing for the information management
activities needed to support a company’s data governance program, should one exist.
I summarize the complementary nature of these two processes level by level, as each
progresses through its own particular form of planning, approaching the moment
when a team can execute upon those plans. The dividing line between steps 5 and 6
in Figure 19.2 indicates where both of these linked cycles transition from planning
activities to putting their plans into action.
Figure 19.2. Agile EDW project start-up aligns well with the data governance cycle.-
Adapted from [Ladley 2013].
Figure 19.2. Agile EDW project start-up aligns well with the data governance cycle.-
Adapted from [Ladley 2013].
The EIM cycle begins with alignment, which Ladley describes as an effort to un-
derstand the goals and objectives needed to articulate a direction for enterprise
information management within a company [Ladley 2010]. Alignment includes a
discovery process to uncover the primary drivers that determine the performance
of the business. Examples of these drivers are the executives’ desire to improve
market share, increase customer interactions, or achieve faster product innovation.
This discovery process will identify the same high-level goals and objectives that the
agile EDW team leaders uncover when they draft their sponsor’s concept briefing and
stakeholder requests, artifacts created as part of Iteration –1 of the ERM project-de-
finition process.
The EIM cycle begins with alignment, which Ladley describes as an effort to un-
derstand the goals and objectives needed to articulate a direction for enterprise
information management within a company [Ladley 2010]. Alignment includes a
discovery process to uncover the primary drivers that determine the performance
of the business. Examples of these drivers are the executives’ desire to improve
market share, increase customer interactions, or achieve faster product innovation.
This discovery process will identify the same high-level goals and objectives that the
agile EDW team leaders uncover when they draft their sponsor’s concept briefing and
stakeholder requests, artifacts created as part of Iteration –1 of the ERM project-de-
finition process.
The next level in the EIM cycle is vision, during which the data governance team
proposes information management goals in terms that the business staff can under-
stand so that they can achieve buy-in for particular area of the enterprise where the
The next level in the EIM cycle is vision, during which the data governance team
proposes information management goals in terms that the business staff can under-
stand so that they can achieve buy-in for particular area of the enterprise where the
EIM program has decided to improve the company’s management of information
assets. The EIM vision artifacts include business cases for the proposed policy
changes, a preliminary set of information requirements, and an initial business
model. These elements closely match the solution statements, feature and benefits
listing, and target business model called for by the agile EDW project definition
process’s vision document.
EIM program has decided to improve the company’s management of information
assets. The EIM vision artifacts include business cases for the proposed policy
changes, a preliminary set of information requirements, and an initial business
model. These elements closely match the solution statements, feature and benefits
listing, and target business model called for by the agile EDW project definition
process’s vision document.
Level 3 of the EIM process is an increasingly detailed business model. This model
consists of a more complete expression of the company’s conceptual data model,
information requirements, usage scenarios, and information taxonomy. These ele-
ments align very well with the work product that the EDW team leaders will deliver
as part of their Iteration 0 startup work, which includes a 80/20 logical data model
for the warehouse, a supporting data dictionary, ETL design patterns, and the first
set of source-to-target mappings.
Level 3 of the EIM process is an increasingly detailed business model. This model
consists of a more complete expression of the company’s conceptual data model,
information requirements, usage scenarios, and information taxonomy. These ele-
ments align very well with the work product that the EDW team leaders will deliver
as part of their Iteration 0 startup work, which includes a 80/20 logical data model
for the warehouse, a supporting data dictionary, ETL design patterns, and the first
set of source-to-target mappings.
Next, the data governance team invests in an architecture, during which the team
drafts the following artifacts in a business-intelligible format [Ladley 2013]:
Next, the data governance team invests in an architecture, during which the team
drafts the following artifacts in a business-intelligible format [Ladley 2013]:
• •
Enterprise metric architecture
Enterprise metric architecture
• •
Information application framework
Information application framework
• •
Business data management architecture
Business data management architecture
• •
Data governance architecture
Data governance architecture
• •
Data quality architecture
Data quality architecture
• •
Information value chain architecture
Information value chain architecture
• •
Community social network architecture
Community social network architecture
• •
Detailed taxonomy Detailed taxonomy
Many of these components will provide crucial requirements for the data warehous-
ing applications that the EDW team has been asked to develop. The previous list is
daunting if one views it as a set of artifacts that must be complete and perfect before
the data governance team moves on to the next level of the EIM process. Providing
100% complete versions of these artifacts is counter to EIM best practices, however.
Ladley urges EIM teams to never implement more data governance than they can
sustain [Ladley 2013]. He defined the EIM cycle so that companies can approach
information management iteratively, implementing with each effort only the policies
that the business staff will be able to support with the changes in their thinking and
daily work actions.
Many of these components will provide crucial requirements for the data warehous-
ing applications that the EDW team has been asked to develop. The previous list is
daunting if one views it as a set of artifacts that must be complete and perfect before
the data governance team moves on to the next level of the EIM process. Providing
100% complete versions of these artifacts is counter to EIM best practices, however.
Ladley urges EIM teams to never implement more data governance than they can
sustain [Ladley 2013]. He defined the EIM cycle so that companies can approach
information management iteratively, implementing with each effort only the policies
that the business staff will be able to support with the changes in their thinking and
daily work actions.
The fact that the data governance team will be pursuing the EIM architecture incre-
mentally essentially mandates that the enterprise data warehouse be constructed
The fact that the data governance team will be pursuing the EIM architecture incre-
mentally essentially mandates that the enterprise data warehouse be constructed
iteratively as well. Fortunately, agile EDW practices will accelerate IT’s ability to
support iterative EIM, to the point that slow development of DW/BI applications
will no longer limit how much EIM the company can achieve. The philosophies
and techniques offered in this book are thus perfectly aligned with the realities
of the business-led data governance process in which EDW’s customers will be
immersed. When starting a project, the agile EDW team pursues an elaboration
phase during the first couple of iterations. Those iterations are dedicated to proving
out the architecture of the new areas being added to the enterprise data warehouse.
As the data governance team works through each increment of the EIM architecture,
the agile EDW team leaders can utilize the resulting EIM artifacts as business
and technical requirements for the modules their teams will build during their
elaboration development work.
iteratively as well. Fortunately, agile EDW practices will accelerate IT’s ability to
support iterative EIM, to the point that slow development of DW/BI applications
will no longer limit how much EIM the company can achieve. The philosophies
and techniques offered in this book are thus perfectly aligned with the realities
of the business-led data governance process in which EDW’s customers will be
immersed. When starting a project, the agile EDW team pursues an elaboration
phase during the first couple of iterations. Those iterations are dedicated to proving
out the architecture of the new areas being added to the enterprise data warehouse.
As the data governance team works through each increment of the EIM architecture,
the agile EDW team leaders can utilize the resulting EIM artifacts as business
and technical requirements for the modules their teams will build during their
elaboration development work.
The last prep step in the EIM cycle before the company executes its data governance
plan is to provide a roadmap. This roadmap prescribes milestones for rolling out the
newly defined data governance process as well as the order in which the company’s
major business applications should align with the data governance plan. Here,
the agile EDW method can enable the data governance team to be more precise.
Working in isolation, the EIM roadmap can depict the desired alignment of business
applications only in terms of EIM maturity phases [Ladley 2013]. Because they are
not close enough to the IT work required to align these systems, the EIM team
cannot provide a roadmap with the likely dates when these systems will be adapted
to support the data governance plan. The agile EDW team, however, will prepare a
current estimate once it has completed the elaboration-phase iterations. Using the
development team velocity established during these iterations, the team can story
point the entire backlog of work and then calculate the number of iterations that
will be required to achieve the target changes in the enterprise data warehouse. Of
course, this calculation is a rough estimate, and the team’s velocity can later change,
but at least this estimate of the number of iterations needed will be evidence-based
and can thus provide meaningful dates for when the features called for by the EIM
roadmap will be available.
The last prep step in the EIM cycle before the company executes its data governance
plan is to provide a roadmap. This roadmap prescribes milestones for rolling out the
newly defined data governance process as well as the order in which the company’s
major business applications should align with the data governance plan. Here,
the agile EDW method can enable the data governance team to be more precise.
Working in isolation, the EIM roadmap can depict the desired alignment of business
applications only in terms of EIM maturity phases [Ladley 2013]. Because they are
not close enough to the IT work required to align these systems, the EIM team
cannot provide a roadmap with the likely dates when these systems will be adapted
to support the data governance plan. The agile EDW team, however, will prepare a
current estimate once it has completed the elaboration-phase iterations. Using the
development team velocity established during these iterations, the team can story
point the entire backlog of work and then calculate the number of iterations that
will be required to achieve the target changes in the enterprise data warehouse. Of
course, this calculation is a rough estimate, and the team’s velocity can later change,
but at least this estimate of the number of iterations needed will be evidence-based
and can thus provide meaningful dates for when the features called for by the EIM
roadmap will be available.
Finally, the EIM team needs to put the data governance plan into action and then
sustain the corporate data quality. The sustain activities include training business
staff in the new work patterns required, the development or modification of the
information systems that the staff will use, plus metrics-gathering activities and
corrective actions when data quality does not meet the goals laid out in the roadmap.
For the agile EDW team, the sustain level of the EIM process translates directly to
iterative DW/BI application development. The subrelease cycle will provide the small
doses of requirements, design, development, and quality assurance work necessary
to evolve the corporate data warehouse to support the master data, standardized
Finally, the EIM team needs to put the data governance plan into action and then
sustain the corporate data quality. The sustain activities include training business
staff in the new work patterns required, the development or modification of the
information systems that the staff will use, plus metrics-gathering activities and
corrective actions when data quality does not meet the goals laid out in the roadmap.
For the agile EDW team, the sustain level of the EIM process translates directly to
iterative DW/BI application development. The subrelease cycle will provide the small
doses of requirements, design, development, and quality assurance work necessary
to evolve the corporate data warehouse to support the master data, standardized
measures, and data quality metrics the EIM plan needs in order to track busi-
ness-unit compliance with the data governance policies adopted.
measures, and data quality metrics the EIM plan needs in order to track busi-
ness-unit compliance with the data governance policies adopted.
Data Governance Actions for the EDW Team
Data Governance Actions for the EDW Team
The agility of the EDW team to deliver evolving business analytics systems will
translate directly into fast feedback loops for the data governance team, making the
EIM process all the more effective at detecting and correcting data quality issues. To
this end, the agile EDW team leaders can support the EIM program as they work with
the company’s various business units to develop the enterprise-level data integration
and reporting applications:
The agility of the EDW team to deliver evolving business analytics systems will
translate directly into fast feedback loops for the data governance team, making the
EIM process all the more effective at detecting and correcting data quality issues. To
this end, the agile EDW team leaders can support the EIM program as they work with
the company’s various business units to develop the enterprise-level data integration
and reporting applications:
• •
They can familiarize themselves with the standards defined by the current
version of data governance regulations, notify data governance when they
encounter source systems that do not comply, and ensure that new EDW
designs do align with those standards.
They can familiarize themselves with the standards defined by the current
version of data governance regulations, notify data governance when they
encounter source systems that do not comply, and ensure that new EDW
designs do align with those standards.
• •
Because they are working closely with many business staff members, they can
collect end-user opinions regarding the effectiveness and accuracy of the data
governance regulations.
Because they are working closely with many business staff members, they ca
collect end-user opinions regarding the effectiveness and accuracy of the da
governance regulations.
• •
They can document cross-business-unit data elements encountered within
their work on individual projects and bring them to the data governance board
for inclusion in the EIM standards.
They can document cross-business-unit data elements encountered within
their work on individual projects and bring them to the data governance boar
for inclusion in the EIM standards.
• •
They can provide the repositories and data transformations needed to im-
plement the data governance decisions in existing or new portions of the
enterprise data warehouse.
They can provide the repositories and data transformations needed to im-
plement the data governance decisions in existing or new portions of the
enterprise data warehouse.
• •
The can prototype proposed EDW features in a way that allows business staff t
o see and evaluate each element’s impact on data fields included in the data
governance plan.
The can prototype proposed EDW features in a way that allows business staff
o see and evaluate each element’s impact on data fields included in the data
governance plan.
• •
When application prototypes are approved, they can implement those en-
hancements to the EDW in a business-reasonable time frame.
When application prototypes are approved, they can implement those en-
hancements to the EDW in a business-reasonable time frame.
In essence, the EDW team can provide an important service for detecting discrep-
ancies between the corporate data as it exists and EIM’s data governance standards.
When those gaps reside in the enterprise data warehouse, the EDW team can work
quickly to resolve them.
In essence, the EDW team can provide an important service for detecting discrep-
ancies between the corporate data as it exists and EIM’s data governance standards.
When those gaps reside in the enterprise data warehouse, the EDW team can work
quickly to resolve them.
Machine-Assisted Data Governance for the Subrelease Cycle
Machine-Assisted Data Governance for the Subrelease Cycle
So that the agile EDW team can provide the invaluable services outlined above, I
have defined Step 1 on the subrelease delivery cycle proposed below to support
data governance. The EDW team can execute this step manually, but my experience
shows that the development team will be far more effective if it leverages its efforts
So that the agile EDW team can provide the invaluable services outlined above, I
have defined Step 1 on the subrelease delivery cycle proposed below to support
data governance. The EDW team can execute this step manually, but my experience
shows that the development team will be far more effective if it leverages its efforts
with a workflow-driven data governance and prototyping tool. Whether manual or
machine-assisted, the four actions within this data governance step will be as follows:
the stakeholder clicks on the URL in the email to see that particular term in the
tool’s user interface, reads the proposed definition of the shared item, and then
either approves the definition or types in how one could improve upon it. Later,
the business analyst can review the comments from all respondents in the data
governance repository and update the candidate definition using the input from
the stakeholders. He or she can then resubmit each element to the workflow engine
for recirculation and review among the stakeholders.
the stakeholder clicks on the URL in the email to see that particular term in the
tool’s user interface, reads the proposed definition of the shared item, and then
either approves the definition or types in how one could improve upon it. Later,
the business analyst can review the comments from all respondents in the data
governance repository and update the candidate definition using the input from
the stakeholders. He or she can then resubmit each element to the workflow engine
for recirculation and review among the stakeholders.
Eventually, the stakeholders will either arrive at a consensus on a definition or
suggest that an element be divided into two or more parallel definitions in order to
allow for variations by business unit. By utilizing a workflow-driven data governance
utility, the entire company has (1) avoided many hours of expensive meetings, (2)
arrived at a set of usable definitions and stored them in an online corporate data
dictionary, and (3) documented the evolution and approvals of each definition in
that dictionary.
Eventually, the stakeholders will either arrive at a consensus on a definition or
suggest that an element be divided into two or more parallel definitions in order to
allow for variations by business unit. By utilizing a workflow-driven data governance
utility, the entire company has (1) avoided many hours of expensive meetings, (2)
arrived at a set of usable definitions and stored them in an online corporate data
dictionary, and (3) documented the evolution and approvals of each definition in
that dictionary.
With approved items in the repository, the EDW team can begin modeling standard-
ized BI qualifiers and metrics (Action 2) by using this data governance tool to visually
stack the defined items into hierarchies, combine the hierarchies into proposed
dimensions, and connect those dimensions to the standardized metric definitions
also residing in the repository. Using the same workflow engine, the team would
send out this candidate dimensional model to the business stakeholders, again
letting them approve or send back comments until they reach a consensus on the
proposed design.
With approved items in the repository, the EDW team can begin modeling standard-
ized BI qualifiers and metrics (Action 2) by using this data governance tool to visually
stack the defined items into hierarchies, combine the hierarchies into proposed
dimensions, and connect those dimensions to the standardized metric definitions
also residing in the repository. Using the same workflow engine, the team would
send out this candidate dimensional model to the business stakeholders, again
letting them approve or send back comments until they reach a consensus on the
proposed design.
Once the organization has a working business design for standard metrics and
dimensions, the EDW leaders can then collaborate with their product owner to
search through source systems for good examples of the data to place in this new
dimensional model (Action 3). Once they have identified a modest number of usable
data records, the EDW team would use the tool to load the sample data into the
dimensional prototype. Using the workflow engine again, they would send out
the URL to the stakeholders so that they can see the hierarchies they agreed on
previously, this time with representative data displayed within them. Based on the
comments fetched by the workflow engine on this data-enriched prototype, the EDW
team leaders will evolve the proposed dimensional solution until the stakeholders
decide whether it is worth building.
Once the organization has a working business design for standard metrics and
dimensions, the EDW leaders can then collaborate with their product owner to
search through source systems for good examples of the data to place in this new
dimensional model (Action 3). Once they have identified a modest number of usable
data records, the EDW team would use the tool to load the sample data into the
dimensional prototype. Using the workflow engine again, they would send out
the URL to the stakeholders so that they can see the hierarchies they agreed on
previously, this time with representative data displayed within them. Based on the
comments fetched by the workflow engine on this data-enriched prototype, the EDW
team leaders will evolve the proposed dimensional solution until the stakeholders
decide whether it is worth building.
At this point, the EDW developers possess
At this point, the EDW developers possess
• •
a rock-solid, tangible expression of business requirements for those upcoming
aspects of the next EDW subrelease that will support data elements under data
governance;
a rock-solid, tangible expression of business requirements for those upcomin
aspects of the next EDW subrelease that will support data elements under da
governance;
• •
approved definitions for the entities and attributes involved; and
approved definitions for the entities and attributes involved; and
• •
sample data that the company can use for testing and demonstrations once
the necessary data transform modules have been programmed.
sample data that the company can use for testing and demonstrations once
the necessary data transform modules have been programmed.
All this was accomplished via asynchronous workflow with little time spent in
meetings listening to the business staff argue over definitions and little or no time
spent performing ETL programming.
All this was accomplished via asynchronous workflow with little time spent in
meetings listening to the business staff argue over definitions and little or no time
spent performing ETL programming.
Have the DG team address this work product before any discussions or reviews are
held with other stakeholders. This will help the team tighten any loose ends and
prepare explanations of the meaning of certain processes.
Have the DG team address this work product before any discussions or reviews are
held with other stakeholders. This will help the team tighten any loose ends and
prepare explanations of the meaning of certain processes.
Engagement
Engagement
John Ladley, in Data Governance (Second Edition), 2020
John Ladley, in Data Governance (Second Edition), 2020
Business benefits and ramifications
Business benefits and ramifications
There are benefits from examining benefits. If the DG team is not tuned into
business needs, it will start to see where they can clearly speak to the value of DG.
How can DG be a business program if it is not tuned into business direction? I
am still stunned at how many employees in all varieties of large and/or well-known
companies have no idea where the company is supposed to be headed.5
There are benefits from examining benefits. If the DG team is not tuned into
business needs, it will start to see where they can clearly speak to the value of DG.
How can DG be a business program if it is not tuned into business direction? I
am still stunned at how many employees in all varieties of large and/or well-known
companies have no idea where the company is supposed to be headed.5
Besides the ultimate assignment of some financial value to DG, the business gets
the material to think of DG as a business program vs an annoying IT effort.
Besides the ultimate assignment of some financial value to DG, the business gets
the material to think of DG as a business program vs an annoying IT effort.
> Read full chapter
> Read full chapter
Data Quality Service Level Agreements
Data Quality Service Level Agreements
David Loshin, in The Practitioner's Guide to Data Quality Improvement, 2011
David Loshin, in The Practitioner's Guide to Data Quality Improvement, 2011
13.1.1 Business Drivers
13.1.1 Business Drivers
Identifying the business drivers establishes the operational governance direction
by enabling the data governance team to prioritize the information policies in
relation to the risk of material impact. Listing the expectations for acceptable data
suggests quantifiable measurements, and this allows business analysts or data
stewards to specify acceptability thresholds related to the success criteria. By listing
the critical expectations, methods for measurement, and specific thresholds, the
business clients can associate data governance with levels of success in their business
activities.
Identifying the business drivers establishes the operational governance direction
by enabling the data governance team to prioritize the information policies in
relation to the risk of material impact. Listing the expectations for acceptable data
suggests quantifiable measurements, and this allows business analysts or data
stewards to specify acceptability thresholds related to the success criteria. By listing
the critical expectations, methods for measurement, and specific thresholds, the
business clients can associate data governance with levels of success in their business
activities.
And this connects two aspects that we have covered: the first is the categorization
of business impacts of poor data quality described in chapter 1, and the second is
the solicitation of business issues as part of the data quality assessment performed
in chapter 11. Instead of just asserting the existence of a business impact, the
important questions focus on comparing the costs of ignoring a problem to the
costs of addressing it, determining the business risks of ignoring that problem, and
determining how the answers to those questions merge to prioritize an action plan
for monitoring and remediation.
And this connects two aspects that we have covered: the first is the categorization
of business impacts of poor data quality described in chapter 1, and the second is
the solicitation of business issues as part of the data quality assessment performed
in chapter 11. Instead of just asserting the existence of a business impact, the
important questions focus on comparing the costs of ignoring a problem to the
costs of addressing it, determining the business risks of ignoring that problem, and
determining how the answers to those questions merge to prioritize an action plan
for monitoring and remediation.
> Read full chapter
> Read full chapter
Strategy
Strategy
John Ladley, in Data Governance (Second Edition), 2020
John Ladley, in Data Governance (Second Edition), 2020
Approach considerations
Approach considerations
This is not a task to take lightly.We often see a list of principles lifted from a published
source, plopped into a document, and then mailed out with a decree that these are
the principles. These rarely succeed.
This is not a task to take lightly.We often see a list of principles lifted from a published
source, plopped into a document, and then mailed out with a decree that these are
the principles. These rarely succeed.
The principles need to be derived and refined formally, not casually. For a low-profile
effort, either settle on a generic SINGLE principle or defer principles until a subse-
quent iteration (but use the first use case or iteration to demonstrate the need for
principles). But when you decide to develop principles, you are starting the journey
toward visibility.
The principles need to be derived and refined formally, not casually. For a low-profile
effort, either settle on a generic SINGLE principle or defer principles until a subse-
quent iteration (but use the first use case or iteration to demonstrate the need for
principles). But when you decide to develop principles, you are starting the journey
toward visibility.
Minimally invasive programs need to understand that at some point, a principle is
required. There needs to be unification to the various efforts. Remember you are
making something formal, which may exist in an informal manner. Business value
and better data management are certainly an outcome, but long-term, you want a
mind-set change, not a project success factor. So at some point, your DG team needs
to formally approach principles.
Minimally invasive programs need to understand that at some point, a principle is
required. There needs to be unification to the various efforts. Remember you are
making something formal, which may exist in an informal manner. Business value
and better data management are certainly an outcome, but long-term, you want a
mind-set change, not a project success factor. So at some point, your DG team needs
to formally approach principles.
The duration of this phase depends entirely on the ability of the DG team to tune the
principles to their organization and get sincere and effective review from leadership.
These activities can be a great opportunity to build consensus and increase the
internalization of DG—or it can drag out and dissolve into a seemingly typical
exercise of irrelevant meetings. If your organization starts to spend more time on
“wordsmithing” principles so as not to offend anyone, you have encountered either
one of two cultural issues.
The duration of this phase depends entirely on the ability of the DG team to tune the
principles to their organization and get sincere and effective review from leadership.
These activities can be a great opportunity to build consensus and increase the
internalization of DG—or it can drag out and dissolve into a seemingly typical
exercise of irrelevant meetings. If your organization starts to spend more time on
“wordsmithing” principles so as not to offend anyone, you have encountered either
one of two cultural issues.
1. 1.
The principles represent changes that are perceived as an admission the
organization is deficient, or “bad,” which the sponsor needs to assuage.
The principles represent changes that are perceived as an admission the
organization is deficient, or “bad,” which the sponsor needs to assuage.
2. 2.
The participants in the process are in fear of being pointed at as instigators of
bad things. The sponsor needs to make sure the team knows it is covered and
someone has their back.
The participants in the process are in fear of being pointed at as instigators o
bad things. The sponsor needs to make sure the team knows it is covered an
someone has their back.
Do not forget to spend time with the implications and ramifications of the principles.
It is only fair to be able to explain why a principle has come about (the rationale). The
implications are very important, not only from a perspective of understanding, but
also because implications almost always provide requirements for policies.
Do not forget to spend time with the implications and ramifications of the principles.
It is only fair to be able to explain why a principle has come about (the rationale). The
implications are very important, not only from a perspective of understanding, but
also because implications almost always provide requirements for policies.
If you have a lot of wordsmithing associated with development of your principles, the
leader of the DG deployment may need to declare the principles are good enough.
If you have a lot of wordsmithing associated with development of your principles, the
leader of the DG deployment may need to declare the principles are good enough.
They will evolve slightly anyway, so there is not much risk in starting to publicize
them and begin policy development.
They will evolve slightly anyway, so there is not much risk in starting to publicize
them and begin policy development.
The general outline for a principle should contain the following elements:
The general outline for a principle should contain the following elements:
1. 1.
Short description of the principle
Short description of the principle
2. 2.
Long description and full definition of the principle
Long description and full definition of the principle
3. 3.
Rationale, or a statement of why the principle is necessary
Rationale, or a statement of why the principle is necessary
4. 4.
Implications, or statements of potential and known impact the principle will
have
Implications, or statements of potential and known impact the principle wil
have
The most common mistake with principle development is to create policies and call
them principles. If your principles are showing any of the following warning signs,
you doing policy making:
The most common mistake with principle development is to create policies and call
them principles. If your principles are showing any of the following warning signs,
you doing policy making:
• •
More than 10 principles: while not unheard of, when you have more than 10
principles you are starting to get very specific about what they mean.
More than 10 principles: while not unheard of, when you have more than 10
principles you are starting to get very specific about what they mean.
• •
Using the description to declare how the principle will be enforced
Using the description to declare how the principle will be enforced
• •
Mentioning specific business areas or functions within the principle
Mentioning specific business areas or functions within the principle
In general, you will start with 12–14 principles and then whittle them down to 3–4.
In general, you will start with 12–14 principles and then whittle them down to 3–4.
Let’s consider the Playbook framework again as shown in Fig. 6.1 and look at the
potential workstream tracks.
Let’s consider the Playbook framework again as shown in Fig. 6.1 and look at the
potential workstream tracks.
Figure 6.1. Business data governance framework.
Figure 6.1. Business data governance framework.
The Playbook framework implemented in Microsoft Excel is a wonderful tool for
managing the business vocabulary, critical data elements, and initial governance
implementation. However, Excel is not the only tool the governance team may need
to scale to large enterprise capabilities. As you work through the activities across the
maturity stages, you will need more than Microsoft Office technology.
The Playbook framework implemented in Microsoft Excel is a wonderful tool for
managing the business vocabulary, critical data elements, and initial governance
implementation. However, Excel is not the only tool the governance team may need
to scale to large enterprise capabilities. As you work through the activities across the
maturity stages, you will need more than Microsoft Office technology.
Most of the activities in the Define stage require more functionally robust technology
support to enable maturity scale improvements. These technical data management
tools have traditionally been confusing to business stakeholders, and today we are
asking those individuals to sponsor the selection of these tools.Additionally the tools
have lacked functionality to support the business governance of data, and technology
management professionals have shouldered the burden of educating the business
and working hard to fill in the technology gaps. Your IT or procurement group
already have a process for selecting technologies, but if you do not have a process
defined we recommend you follow one similar to the selection process defined in
the next section.
Most of the activities in the Define stage require more functionally robust technology
support to enable maturity scale improvements. These technical data management
tools have traditionally been confusing to business stakeholders, and today we are
asking those individuals to sponsor the selection of these tools.Additionally the tools
have lacked functionality to support the business governance of data, and technology
management professionals have shouldered the burden of educating the business
and working hard to fill in the technology gaps. Your IT or procurement group
already have a process for selecting technologies, but if you do not have a process
defined we recommend you follow one similar to the selection process defined in
the next section.
TOP_PASSOS GOV DADOS.pdf
TOP_PASSOS GOV DADOS.pdf

More Related Content

Similar to TOP_PASSOS GOV DADOS.pdf

Data_Warehouse_Methodology_A_Process_Driven_Approa.pdf
Data_Warehouse_Methodology_A_Process_Driven_Approa.pdfData_Warehouse_Methodology_A_Process_Driven_Approa.pdf
Data_Warehouse_Methodology_A_Process_Driven_Approa.pdfaliramezani30
 
Building an Effective & Extensible Data & Analytics Operating Model
Building an Effective & Extensible Data & Analytics Operating ModelBuilding an Effective & Extensible Data & Analytics Operating Model
Building an Effective & Extensible Data & Analytics Operating ModelCognizant
 
The Internal And External And Media Relations...
The Internal And External And Media Relations...The Internal And External And Media Relations...
The Internal And External And Media Relations...Melissa Moore
 
An ERP Implementation Method Studying A Pharmaceutical Company
An ERP Implementation Method  Studying A Pharmaceutical CompanyAn ERP Implementation Method  Studying A Pharmaceutical Company
An ERP Implementation Method Studying A Pharmaceutical CompanyJoe Osborn
 
MDM AS A METHODOLOGY
MDM AS A METHODOLOGYMDM AS A METHODOLOGY
MDM AS A METHODOLOGYJanet Wetter
 
BRIDGING DATA SILOS USING BIG DATA INTEGRATION
BRIDGING DATA SILOS USING BIG DATA INTEGRATIONBRIDGING DATA SILOS USING BIG DATA INTEGRATION
BRIDGING DATA SILOS USING BIG DATA INTEGRATIONijmnct
 
Application of Google Cloud and Google Apps in Data Structuring
Application of Google Cloud and Google Apps in Data StructuringApplication of Google Cloud and Google Apps in Data Structuring
Application of Google Cloud and Google Apps in Data StructuringIOSRjournaljce
 
Running head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docxRunning head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docxhealdkathaleen
 
Running head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docxRunning head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docxtodd271
 
Enterprise Architecture Proposal
Enterprise Architecture ProposalEnterprise Architecture Proposal
Enterprise Architecture ProposalStacey Cruz
 
Assessment Of An Enterprise-Level Business System
Assessment Of An Enterprise-Level Business SystemAssessment Of An Enterprise-Level Business System
Assessment Of An Enterprise-Level Business SystemTiffany Graham
 
Essay On Implementation ERP
Essay On Implementation ERPEssay On Implementation ERP
Essay On Implementation ERPKelley Hunter
 
IntroductionJava EE is a standard, robust, adaptable, and secure p.docx
IntroductionJava EE is a standard, robust, adaptable, and secure p.docxIntroductionJava EE is a standard, robust, adaptable, and secure p.docx
IntroductionJava EE is a standard, robust, adaptable, and secure p.docxnormanibarber20063
 
Assignment 3 - Big Data - Ed.02
Assignment 3 - Big Data - Ed.02Assignment 3 - Big Data - Ed.02
Assignment 3 - Big Data - Ed.02Hosein Nafisi
 
Sim an innovative business oriented approach for a distributed access management
Sim an innovative business oriented approach for a distributed access managementSim an innovative business oriented approach for a distributed access management
Sim an innovative business oriented approach for a distributed access managementchristophefeltus
 
Data Governance for EPM Systems with Oracle DRM
Data Governance for EPM Systems with Oracle DRMData Governance for EPM Systems with Oracle DRM
Data Governance for EPM Systems with Oracle DRMUS-Analytics
 

Similar to TOP_PASSOS GOV DADOS.pdf (18)

Data_Warehouse_Methodology_A_Process_Driven_Approa.pdf
Data_Warehouse_Methodology_A_Process_Driven_Approa.pdfData_Warehouse_Methodology_A_Process_Driven_Approa.pdf
Data_Warehouse_Methodology_A_Process_Driven_Approa.pdf
 
Building an Effective & Extensible Data & Analytics Operating Model
Building an Effective & Extensible Data & Analytics Operating ModelBuilding an Effective & Extensible Data & Analytics Operating Model
Building an Effective & Extensible Data & Analytics Operating Model
 
The Internal And External And Media Relations...
The Internal And External And Media Relations...The Internal And External And Media Relations...
The Internal And External And Media Relations...
 
An ERP Implementation Method Studying A Pharmaceutical Company
An ERP Implementation Method  Studying A Pharmaceutical CompanyAn ERP Implementation Method  Studying A Pharmaceutical Company
An ERP Implementation Method Studying A Pharmaceutical Company
 
MDM AS A METHODOLOGY
MDM AS A METHODOLOGYMDM AS A METHODOLOGY
MDM AS A METHODOLOGY
 
BRIDGING DATA SILOS USING BIG DATA INTEGRATION
BRIDGING DATA SILOS USING BIG DATA INTEGRATIONBRIDGING DATA SILOS USING BIG DATA INTEGRATION
BRIDGING DATA SILOS USING BIG DATA INTEGRATION
 
Application of Google Cloud and Google Apps in Data Structuring
Application of Google Cloud and Google Apps in Data StructuringApplication of Google Cloud and Google Apps in Data Structuring
Application of Google Cloud and Google Apps in Data Structuring
 
Running head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docxRunning head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docx
 
Running head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docxRunning head Database and Data Warehousing design1Database and.docx
Running head Database and Data Warehousing design1Database and.docx
 
Enterprise architecture
Enterprise architectureEnterprise architecture
Enterprise architecture
 
Enterprise Architecture Proposal
Enterprise Architecture ProposalEnterprise Architecture Proposal
Enterprise Architecture Proposal
 
Assessment Of An Enterprise-Level Business System
Assessment Of An Enterprise-Level Business SystemAssessment Of An Enterprise-Level Business System
Assessment Of An Enterprise-Level Business System
 
Essay On Implementation ERP
Essay On Implementation ERPEssay On Implementation ERP
Essay On Implementation ERP
 
IntroductionJava EE is a standard, robust, adaptable, and secure p.docx
IntroductionJava EE is a standard, robust, adaptable, and secure p.docxIntroductionJava EE is a standard, robust, adaptable, and secure p.docx
IntroductionJava EE is a standard, robust, adaptable, and secure p.docx
 
Assignment 3 - Big Data - Ed.02
Assignment 3 - Big Data - Ed.02Assignment 3 - Big Data - Ed.02
Assignment 3 - Big Data - Ed.02
 
Sim an innovative business oriented approach for a distributed access management
Sim an innovative business oriented approach for a distributed access managementSim an innovative business oriented approach for a distributed access management
Sim an innovative business oriented approach for a distributed access management
 
Sim an innovative business oriented approach for a distributed access management
Sim an innovative business oriented approach for a distributed access managementSim an innovative business oriented approach for a distributed access management
Sim an innovative business oriented approach for a distributed access management
 
Data Governance for EPM Systems with Oracle DRM
Data Governance for EPM Systems with Oracle DRMData Governance for EPM Systems with Oracle DRM
Data Governance for EPM Systems with Oracle DRM
 

Recently uploaded

Decoding Movie Sentiments: Analyzing Reviews with Data Analysis model
Decoding Movie Sentiments: Analyzing Reviews with Data Analysis modelDecoding Movie Sentiments: Analyzing Reviews with Data Analysis model
Decoding Movie Sentiments: Analyzing Reviews with Data Analysis modelBoston Institute of Analytics
 
6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...
6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...
6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...Dr Arash Najmaei ( Phd., MBA, BSc)
 
why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...
why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...
why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...Jack Cole
 
Statistics For Management by Richard I. Levin 8ed.pdf
Statistics For Management by Richard I. Levin 8ed.pdfStatistics For Management by Richard I. Levin 8ed.pdf
Statistics For Management by Richard I. Levin 8ed.pdfnikeshsingh56
 
Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...
Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...
Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...ThinkInnovation
 
Presentation of project of business person who are success
Presentation of project of business person who are successPresentation of project of business person who are success
Presentation of project of business person who are successPratikSingh115843
 
Bank Loan Approval Analysis: A Comprehensive Data Analysis Project
Bank Loan Approval Analysis: A Comprehensive Data Analysis ProjectBank Loan Approval Analysis: A Comprehensive Data Analysis Project
Bank Loan Approval Analysis: A Comprehensive Data Analysis ProjectBoston Institute of Analytics
 
Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...
Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...
Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...Boston Institute of Analytics
 
Digital Indonesia Report 2024 by We Are Social .pdf
Digital Indonesia Report 2024 by We Are Social .pdfDigital Indonesia Report 2024 by We Are Social .pdf
Digital Indonesia Report 2024 by We Are Social .pdfNicoChristianSunaryo
 
DATA ANALYSIS using various data sets like shoping data set etc
DATA ANALYSIS using various data sets like shoping data set etcDATA ANALYSIS using various data sets like shoping data set etc
DATA ANALYSIS using various data sets like shoping data set etclalithasri22
 
IBEF report on the Insurance market in India
IBEF report on the Insurance market in IndiaIBEF report on the Insurance market in India
IBEF report on the Insurance market in IndiaManalVerma4
 
Role of Consumer Insights in business transformation
Role of Consumer Insights in business transformationRole of Consumer Insights in business transformation
Role of Consumer Insights in business transformationAnnie Melnic
 
Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...
Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...
Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...ThinkInnovation
 

Recently uploaded (16)

Decoding Movie Sentiments: Analyzing Reviews with Data Analysis model
Decoding Movie Sentiments: Analyzing Reviews with Data Analysis modelDecoding Movie Sentiments: Analyzing Reviews with Data Analysis model
Decoding Movie Sentiments: Analyzing Reviews with Data Analysis model
 
2023 Survey Shows Dip in High School E-Cigarette Use
2023 Survey Shows Dip in High School E-Cigarette Use2023 Survey Shows Dip in High School E-Cigarette Use
2023 Survey Shows Dip in High School E-Cigarette Use
 
6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...
6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...
6 Tips for Interpretable Topic Models _ by Nicha Ruchirawat _ Towards Data Sc...
 
why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...
why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...
why-transparency-and-traceability-are-essential-for-sustainable-supply-chains...
 
Statistics For Management by Richard I. Levin 8ed.pdf
Statistics For Management by Richard I. Levin 8ed.pdfStatistics For Management by Richard I. Levin 8ed.pdf
Statistics For Management by Richard I. Levin 8ed.pdf
 
Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...
Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...
Predictive Analysis - Using Insight-informed Data to Plan Inventory in Next 6...
 
Insurance Churn Prediction Data Analysis Project
Insurance Churn Prediction Data Analysis ProjectInsurance Churn Prediction Data Analysis Project
Insurance Churn Prediction Data Analysis Project
 
Presentation of project of business person who are success
Presentation of project of business person who are successPresentation of project of business person who are success
Presentation of project of business person who are success
 
Bank Loan Approval Analysis: A Comprehensive Data Analysis Project
Bank Loan Approval Analysis: A Comprehensive Data Analysis ProjectBank Loan Approval Analysis: A Comprehensive Data Analysis Project
Bank Loan Approval Analysis: A Comprehensive Data Analysis Project
 
Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...
Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...
Data Analysis Project Presentation: Unveiling Your Ideal Customer, Bank Custo...
 
Digital Indonesia Report 2024 by We Are Social .pdf
Digital Indonesia Report 2024 by We Are Social .pdfDigital Indonesia Report 2024 by We Are Social .pdf
Digital Indonesia Report 2024 by We Are Social .pdf
 
DATA ANALYSIS using various data sets like shoping data set etc
DATA ANALYSIS using various data sets like shoping data set etcDATA ANALYSIS using various data sets like shoping data set etc
DATA ANALYSIS using various data sets like shoping data set etc
 
IBEF report on the Insurance market in India
IBEF report on the Insurance market in IndiaIBEF report on the Insurance market in India
IBEF report on the Insurance market in India
 
Data Analysis Project: Stroke Prediction
Data Analysis Project: Stroke PredictionData Analysis Project: Stroke Prediction
Data Analysis Project: Stroke Prediction
 
Role of Consumer Insights in business transformation
Role of Consumer Insights in business transformationRole of Consumer Insights in business transformation
Role of Consumer Insights in business transformation
 
Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...
Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...
Decision Making Under Uncertainty - Is It Better Off Joining a Partnership or...
 

TOP_PASSOS GOV DADOS.pdf

  • 2. Data Governance Team Related terms: Related terms: Business Intelligence, Internet of Things, Data Governance, Master Data Manage- ment, Data Governance Program, Programme Management, Term Definition Business Intelligence, Internet of Things, Data Governance, Master Data Manage- ment, Data Governance Program, Programme Management, Term Definition View all Topics View all Topics
  • 3. 13.
  • 4. 13. Term definition example Term definition example 14. 14. Term use description (how to and how not to use) Term use description (how to and how not to use) 15. 15. Last update date Last update date 16. 16. Term category, subcategory name (related to taxonomy or subject area) (1 or many) Term category, subcategory name (related to taxonomy or subject area) (1 or many) 17. 17. Term acronym Term acronym 18. 18. Term abbreviation Term abbreviation 19. 19. Related term name (1 or many) Related term name (1 or many) 20. 20. Replacement term name Replacement term name 21. 21. Managed by business unit Managed by business unit 22. 22. Managed by application Managed by application 23. 23. Managed by business function Managed by business function 24. 24. Data steward name Data steward name 25. 25. Data steward contact phone, email, location Data steward contact phone, email, location 26. 26. Data steward alternate contact phone, email, location Data steward alternate contact phone, email, location 27. 27. Term logical business rules Term logical business rules 28. 28. Term use restrictions Term use restrictions 29. 29. Security and compliance rules and restrictions Security and compliance rules and restrictions 30. 30. Mapped IT assetsa.Physical column name and table name (1 or many)b.- Database name/scheme name (1 or many)c.Report name (1 or many)d.Data integration process name (1 or many) Mapped IT assetsa.Physical column name and table name (1 or many)b.- Database name/scheme name (1 or many)c.Report name (1 or many)d.Data integration process name (1 or many) 31. 31. Data-quality expectations/profilinga.Column name (1 or many)b.Business term namec.Date profiledd.Completeness percentagee.Validity percentagef.- Nonvalid percentage Data-quality expectations/profilinga.Column name (1 or many)b.Business term namec.Date profiledd.Completeness percentagee.Validity percentagef. Nonvalid percentage
  • 5. 3.
  • 6. 3. Term definition example (can be imbedded in the definition attribute but we recommend against it) Term definition example (can be imbedded in the definition attribute but we recommend against it) 4. 4. Term acronym Term acronym 5. 5. Term abbreviation Term abbreviation 6. 6. Term security and compliance restrictions Term security and compliance restrictions 7. 7. Defined by person name (name of the person creating the term definition) Defined by person name (name of the person creating the term definition) 8. 8. Data steward name (assuming there is not just one steward) Data steward name (assuming there is not just one steward) 9. 9. Data steward contact information (phone, email, location) Data steward contact information (phone, email, location) 10. 10. Term logical business rules (business, referential integrity, and quality) Term logical business rules (business, referential integrity, and quality)
  • 7. sufficient “air coverage” (i.e., be introduced or initially sponsored by a respected executive). If an MDM project is initiating DG, then the project sponsor needs to kick this off.
  • 8. sufficient “air coverage” (i.e., be introduced or initially sponsored by a respected executive). If an MDM project is initiating DG, then the project sponsor needs to kick this off.
  • 9. The Agile EDW Subrelease Cycle
  • 10.
  • 11. departments will maintain their own data marts because they cannot understand or trust the information in the enterprise data warehouse. Third, changing the data warehouse for a new requirement takes months just to research and plan because the impact on master data elements cannot be readily assessed [Eckerson 2001].
  • 12.
  • 13. as an asset [Ladley 2010]. EIM is comprised to two complementary practices: data governance and information management.
  • 14. as an asset [Ladley 2010]. EIM is comprised to two complementary practices: data governance and information management. As shown in Figure 19.1, an informal way to describe the division of labor between these two practices is that “data governance is defining and planning the right things to do, information management is actually doing those things right” [Ladley 2013]. Data governance is the business-led portion of the EIM effort. Information management comprises the systems design and implementation work that IT must provide to achieve the data governance the business has defined. As shown in Figure 19.1, an informal way to describe the division of labor between these two practices is that “data governance is defining and planning the right things to do, information management is actually doing those things right” [Ladley 2013]. Data governance is the business-led portion of the EIM effort. Information management comprises the systems design and implementation work that IT must provide to achieve the data governance the business has defined. Figure 19.1. Enterprise information management includes a business-led data gov- ernannce program and an IT-led information managment program. Figure 19.1. Enterprise information management includes a business-led data gov- ernannce program and an IT-led information managment program. In his 2010 book, John Ladley provides an iterative approach for the business side of a company to pursue when it decides to invest in EIM [Ladley 2010]. I believe this cycle provides a reliable, step-by-step process that companies should follow in order to achieve effective data governance. During the previous chapters on requirements management, this book described an enterprise-capable requirements manage- ment (ERM) process for defining the application an agile EDW team intends to build. This project definition process started with sponsor concept briefings, included a vision document, and resulted in a current estimate. Not only does this ERM value chain of artifacts enable a team to move smoothly into the development iterations of a subrelease cycle but also it links quite well with the EIM process Ladley proposes, as shown in Figure 19.2. Because this linkage is so extensive, the agile EDM project startup process provides a strong sequencing for the information management activities needed to support a company’s data governance program, should one exist. I summarize the complementary nature of these two processes level by level, as each progresses through its own particular form of planning, approaching the moment when a team can execute upon those plans. The dividing line between steps 5 and 6 in Figure 19.2 indicates where both of these linked cycles transition from planning activities to putting their plans into action. In his 2010 book, John Ladley provides an iterative approach for the business side of a company to pursue when it decides to invest in EIM [Ladley 2010]. I believe this cycle provides a reliable, step-by-step process that companies should follow in order to achieve effective data governance. During the previous chapters on requirements management, this book described an enterprise-capable requirements manage- ment (ERM) process for defining the application an agile EDW team intends to build. This project definition process started with sponsor concept briefings, included a vision document, and resulted in a current estimate. Not only does this ERM value chain of artifacts enable a team to move smoothly into the development iterations of a subrelease cycle but also it links quite well with the EIM process Ladley proposes, as shown in Figure 19.2. Because this linkage is so extensive, the agile EDM project startup process provides a strong sequencing for the information management activities needed to support a company’s data governance program, should one exist. I summarize the complementary nature of these two processes level by level, as each progresses through its own particular form of planning, approaching the moment when a team can execute upon those plans. The dividing line between steps 5 and 6 in Figure 19.2 indicates where both of these linked cycles transition from planning activities to putting their plans into action.
  • 15.
  • 16. Figure 19.2. Agile EDW project start-up aligns well with the data governance cycle.- Adapted from [Ladley 2013]. Figure 19.2. Agile EDW project start-up aligns well with the data governance cycle.- Adapted from [Ladley 2013]. The EIM cycle begins with alignment, which Ladley describes as an effort to un- derstand the goals and objectives needed to articulate a direction for enterprise information management within a company [Ladley 2010]. Alignment includes a discovery process to uncover the primary drivers that determine the performance of the business. Examples of these drivers are the executives’ desire to improve market share, increase customer interactions, or achieve faster product innovation. This discovery process will identify the same high-level goals and objectives that the agile EDW team leaders uncover when they draft their sponsor’s concept briefing and stakeholder requests, artifacts created as part of Iteration –1 of the ERM project-de- finition process. The EIM cycle begins with alignment, which Ladley describes as an effort to un- derstand the goals and objectives needed to articulate a direction for enterprise information management within a company [Ladley 2010]. Alignment includes a discovery process to uncover the primary drivers that determine the performance of the business. Examples of these drivers are the executives’ desire to improve market share, increase customer interactions, or achieve faster product innovation. This discovery process will identify the same high-level goals and objectives that the agile EDW team leaders uncover when they draft their sponsor’s concept briefing and stakeholder requests, artifacts created as part of Iteration –1 of the ERM project-de- finition process. The next level in the EIM cycle is vision, during which the data governance team proposes information management goals in terms that the business staff can under- stand so that they can achieve buy-in for particular area of the enterprise where the The next level in the EIM cycle is vision, during which the data governance team proposes information management goals in terms that the business staff can under- stand so that they can achieve buy-in for particular area of the enterprise where the
  • 17. EIM program has decided to improve the company’s management of information assets. The EIM vision artifacts include business cases for the proposed policy changes, a preliminary set of information requirements, and an initial business model. These elements closely match the solution statements, feature and benefits listing, and target business model called for by the agile EDW project definition process’s vision document.
  • 18. EIM program has decided to improve the company’s management of information assets. The EIM vision artifacts include business cases for the proposed policy changes, a preliminary set of information requirements, and an initial business model. These elements closely match the solution statements, feature and benefits listing, and target business model called for by the agile EDW project definition process’s vision document. Level 3 of the EIM process is an increasingly detailed business model. This model consists of a more complete expression of the company’s conceptual data model, information requirements, usage scenarios, and information taxonomy. These ele- ments align very well with the work product that the EDW team leaders will deliver as part of their Iteration 0 startup work, which includes a 80/20 logical data model for the warehouse, a supporting data dictionary, ETL design patterns, and the first set of source-to-target mappings. Level 3 of the EIM process is an increasingly detailed business model. This model consists of a more complete expression of the company’s conceptual data model, information requirements, usage scenarios, and information taxonomy. These ele- ments align very well with the work product that the EDW team leaders will deliver as part of their Iteration 0 startup work, which includes a 80/20 logical data model for the warehouse, a supporting data dictionary, ETL design patterns, and the first set of source-to-target mappings. Next, the data governance team invests in an architecture, during which the team drafts the following artifacts in a business-intelligible format [Ladley 2013]: Next, the data governance team invests in an architecture, during which the team drafts the following artifacts in a business-intelligible format [Ladley 2013]: • • Enterprise metric architecture Enterprise metric architecture • • Information application framework Information application framework • • Business data management architecture Business data management architecture • • Data governance architecture Data governance architecture • • Data quality architecture Data quality architecture • • Information value chain architecture Information value chain architecture • • Community social network architecture Community social network architecture • • Detailed taxonomy Detailed taxonomy Many of these components will provide crucial requirements for the data warehous- ing applications that the EDW team has been asked to develop. The previous list is daunting if one views it as a set of artifacts that must be complete and perfect before the data governance team moves on to the next level of the EIM process. Providing 100% complete versions of these artifacts is counter to EIM best practices, however. Ladley urges EIM teams to never implement more data governance than they can sustain [Ladley 2013]. He defined the EIM cycle so that companies can approach information management iteratively, implementing with each effort only the policies that the business staff will be able to support with the changes in their thinking and daily work actions. Many of these components will provide crucial requirements for the data warehous- ing applications that the EDW team has been asked to develop. The previous list is daunting if one views it as a set of artifacts that must be complete and perfect before the data governance team moves on to the next level of the EIM process. Providing 100% complete versions of these artifacts is counter to EIM best practices, however. Ladley urges EIM teams to never implement more data governance than they can sustain [Ladley 2013]. He defined the EIM cycle so that companies can approach information management iteratively, implementing with each effort only the policies that the business staff will be able to support with the changes in their thinking and daily work actions. The fact that the data governance team will be pursuing the EIM architecture incre- mentally essentially mandates that the enterprise data warehouse be constructed The fact that the data governance team will be pursuing the EIM architecture incre- mentally essentially mandates that the enterprise data warehouse be constructed
  • 19. iteratively as well. Fortunately, agile EDW practices will accelerate IT’s ability to support iterative EIM, to the point that slow development of DW/BI applications will no longer limit how much EIM the company can achieve. The philosophies and techniques offered in this book are thus perfectly aligned with the realities of the business-led data governance process in which EDW’s customers will be immersed. When starting a project, the agile EDW team pursues an elaboration phase during the first couple of iterations. Those iterations are dedicated to proving out the architecture of the new areas being added to the enterprise data warehouse. As the data governance team works through each increment of the EIM architecture, the agile EDW team leaders can utilize the resulting EIM artifacts as business and technical requirements for the modules their teams will build during their elaboration development work.
  • 20. iteratively as well. Fortunately, agile EDW practices will accelerate IT’s ability to support iterative EIM, to the point that slow development of DW/BI applications will no longer limit how much EIM the company can achieve. The philosophies and techniques offered in this book are thus perfectly aligned with the realities of the business-led data governance process in which EDW’s customers will be immersed. When starting a project, the agile EDW team pursues an elaboration phase during the first couple of iterations. Those iterations are dedicated to proving out the architecture of the new areas being added to the enterprise data warehouse. As the data governance team works through each increment of the EIM architecture, the agile EDW team leaders can utilize the resulting EIM artifacts as business and technical requirements for the modules their teams will build during their elaboration development work. The last prep step in the EIM cycle before the company executes its data governance plan is to provide a roadmap. This roadmap prescribes milestones for rolling out the newly defined data governance process as well as the order in which the company’s major business applications should align with the data governance plan. Here, the agile EDW method can enable the data governance team to be more precise. Working in isolation, the EIM roadmap can depict the desired alignment of business applications only in terms of EIM maturity phases [Ladley 2013]. Because they are not close enough to the IT work required to align these systems, the EIM team cannot provide a roadmap with the likely dates when these systems will be adapted to support the data governance plan. The agile EDW team, however, will prepare a current estimate once it has completed the elaboration-phase iterations. Using the development team velocity established during these iterations, the team can story point the entire backlog of work and then calculate the number of iterations that will be required to achieve the target changes in the enterprise data warehouse. Of course, this calculation is a rough estimate, and the team’s velocity can later change, but at least this estimate of the number of iterations needed will be evidence-based and can thus provide meaningful dates for when the features called for by the EIM roadmap will be available. The last prep step in the EIM cycle before the company executes its data governance plan is to provide a roadmap. This roadmap prescribes milestones for rolling out the newly defined data governance process as well as the order in which the company’s major business applications should align with the data governance plan. Here, the agile EDW method can enable the data governance team to be more precise. Working in isolation, the EIM roadmap can depict the desired alignment of business applications only in terms of EIM maturity phases [Ladley 2013]. Because they are not close enough to the IT work required to align these systems, the EIM team cannot provide a roadmap with the likely dates when these systems will be adapted to support the data governance plan. The agile EDW team, however, will prepare a current estimate once it has completed the elaboration-phase iterations. Using the development team velocity established during these iterations, the team can story point the entire backlog of work and then calculate the number of iterations that will be required to achieve the target changes in the enterprise data warehouse. Of course, this calculation is a rough estimate, and the team’s velocity can later change, but at least this estimate of the number of iterations needed will be evidence-based and can thus provide meaningful dates for when the features called for by the EIM roadmap will be available. Finally, the EIM team needs to put the data governance plan into action and then sustain the corporate data quality. The sustain activities include training business staff in the new work patterns required, the development or modification of the information systems that the staff will use, plus metrics-gathering activities and corrective actions when data quality does not meet the goals laid out in the roadmap. For the agile EDW team, the sustain level of the EIM process translates directly to iterative DW/BI application development. The subrelease cycle will provide the small doses of requirements, design, development, and quality assurance work necessary to evolve the corporate data warehouse to support the master data, standardized Finally, the EIM team needs to put the data governance plan into action and then sustain the corporate data quality. The sustain activities include training business staff in the new work patterns required, the development or modification of the information systems that the staff will use, plus metrics-gathering activities and corrective actions when data quality does not meet the goals laid out in the roadmap. For the agile EDW team, the sustain level of the EIM process translates directly to iterative DW/BI application development. The subrelease cycle will provide the small doses of requirements, design, development, and quality assurance work necessary to evolve the corporate data warehouse to support the master data, standardized
  • 21. measures, and data quality metrics the EIM plan needs in order to track busi- ness-unit compliance with the data governance policies adopted.
  • 22. measures, and data quality metrics the EIM plan needs in order to track busi- ness-unit compliance with the data governance policies adopted. Data Governance Actions for the EDW Team Data Governance Actions for the EDW Team The agility of the EDW team to deliver evolving business analytics systems will translate directly into fast feedback loops for the data governance team, making the EIM process all the more effective at detecting and correcting data quality issues. To this end, the agile EDW team leaders can support the EIM program as they work with the company’s various business units to develop the enterprise-level data integration and reporting applications: The agility of the EDW team to deliver evolving business analytics systems will translate directly into fast feedback loops for the data governance team, making the EIM process all the more effective at detecting and correcting data quality issues. To this end, the agile EDW team leaders can support the EIM program as they work with the company’s various business units to develop the enterprise-level data integration and reporting applications: • • They can familiarize themselves with the standards defined by the current version of data governance regulations, notify data governance when they encounter source systems that do not comply, and ensure that new EDW designs do align with those standards. They can familiarize themselves with the standards defined by the current version of data governance regulations, notify data governance when they encounter source systems that do not comply, and ensure that new EDW designs do align with those standards. • • Because they are working closely with many business staff members, they can collect end-user opinions regarding the effectiveness and accuracy of the data governance regulations. Because they are working closely with many business staff members, they ca collect end-user opinions regarding the effectiveness and accuracy of the da governance regulations. • • They can document cross-business-unit data elements encountered within their work on individual projects and bring them to the data governance board for inclusion in the EIM standards. They can document cross-business-unit data elements encountered within their work on individual projects and bring them to the data governance boar for inclusion in the EIM standards. • • They can provide the repositories and data transformations needed to im- plement the data governance decisions in existing or new portions of the enterprise data warehouse. They can provide the repositories and data transformations needed to im- plement the data governance decisions in existing or new portions of the enterprise data warehouse. • • The can prototype proposed EDW features in a way that allows business staff t o see and evaluate each element’s impact on data fields included in the data governance plan. The can prototype proposed EDW features in a way that allows business staff o see and evaluate each element’s impact on data fields included in the data governance plan. • • When application prototypes are approved, they can implement those en- hancements to the EDW in a business-reasonable time frame. When application prototypes are approved, they can implement those en- hancements to the EDW in a business-reasonable time frame. In essence, the EDW team can provide an important service for detecting discrep- ancies between the corporate data as it exists and EIM’s data governance standards. When those gaps reside in the enterprise data warehouse, the EDW team can work quickly to resolve them. In essence, the EDW team can provide an important service for detecting discrep- ancies between the corporate data as it exists and EIM’s data governance standards. When those gaps reside in the enterprise data warehouse, the EDW team can work quickly to resolve them. Machine-Assisted Data Governance for the Subrelease Cycle Machine-Assisted Data Governance for the Subrelease Cycle So that the agile EDW team can provide the invaluable services outlined above, I have defined Step 1 on the subrelease delivery cycle proposed below to support data governance. The EDW team can execute this step manually, but my experience shows that the development team will be far more effective if it leverages its efforts So that the agile EDW team can provide the invaluable services outlined above, I have defined Step 1 on the subrelease delivery cycle proposed below to support data governance. The EDW team can execute this step manually, but my experience shows that the development team will be far more effective if it leverages its efforts
  • 23. with a workflow-driven data governance and prototyping tool. Whether manual or machine-assisted, the four actions within this data governance step will be as follows:
  • 24.
  • 25. the stakeholder clicks on the URL in the email to see that particular term in the tool’s user interface, reads the proposed definition of the shared item, and then either approves the definition or types in how one could improve upon it. Later, the business analyst can review the comments from all respondents in the data governance repository and update the candidate definition using the input from the stakeholders. He or she can then resubmit each element to the workflow engine for recirculation and review among the stakeholders.
  • 26. the stakeholder clicks on the URL in the email to see that particular term in the tool’s user interface, reads the proposed definition of the shared item, and then either approves the definition or types in how one could improve upon it. Later, the business analyst can review the comments from all respondents in the data governance repository and update the candidate definition using the input from the stakeholders. He or she can then resubmit each element to the workflow engine for recirculation and review among the stakeholders. Eventually, the stakeholders will either arrive at a consensus on a definition or suggest that an element be divided into two or more parallel definitions in order to allow for variations by business unit. By utilizing a workflow-driven data governance utility, the entire company has (1) avoided many hours of expensive meetings, (2) arrived at a set of usable definitions and stored them in an online corporate data dictionary, and (3) documented the evolution and approvals of each definition in that dictionary. Eventually, the stakeholders will either arrive at a consensus on a definition or suggest that an element be divided into two or more parallel definitions in order to allow for variations by business unit. By utilizing a workflow-driven data governance utility, the entire company has (1) avoided many hours of expensive meetings, (2) arrived at a set of usable definitions and stored them in an online corporate data dictionary, and (3) documented the evolution and approvals of each definition in that dictionary. With approved items in the repository, the EDW team can begin modeling standard- ized BI qualifiers and metrics (Action 2) by using this data governance tool to visually stack the defined items into hierarchies, combine the hierarchies into proposed dimensions, and connect those dimensions to the standardized metric definitions also residing in the repository. Using the same workflow engine, the team would send out this candidate dimensional model to the business stakeholders, again letting them approve or send back comments until they reach a consensus on the proposed design. With approved items in the repository, the EDW team can begin modeling standard- ized BI qualifiers and metrics (Action 2) by using this data governance tool to visually stack the defined items into hierarchies, combine the hierarchies into proposed dimensions, and connect those dimensions to the standardized metric definitions also residing in the repository. Using the same workflow engine, the team would send out this candidate dimensional model to the business stakeholders, again letting them approve or send back comments until they reach a consensus on the proposed design. Once the organization has a working business design for standard metrics and dimensions, the EDW leaders can then collaborate with their product owner to search through source systems for good examples of the data to place in this new dimensional model (Action 3). Once they have identified a modest number of usable data records, the EDW team would use the tool to load the sample data into the dimensional prototype. Using the workflow engine again, they would send out the URL to the stakeholders so that they can see the hierarchies they agreed on previously, this time with representative data displayed within them. Based on the comments fetched by the workflow engine on this data-enriched prototype, the EDW team leaders will evolve the proposed dimensional solution until the stakeholders decide whether it is worth building. Once the organization has a working business design for standard metrics and dimensions, the EDW leaders can then collaborate with their product owner to search through source systems for good examples of the data to place in this new dimensional model (Action 3). Once they have identified a modest number of usable data records, the EDW team would use the tool to load the sample data into the dimensional prototype. Using the workflow engine again, they would send out the URL to the stakeholders so that they can see the hierarchies they agreed on previously, this time with representative data displayed within them. Based on the comments fetched by the workflow engine on this data-enriched prototype, the EDW team leaders will evolve the proposed dimensional solution until the stakeholders decide whether it is worth building. At this point, the EDW developers possess At this point, the EDW developers possess • • a rock-solid, tangible expression of business requirements for those upcoming aspects of the next EDW subrelease that will support data elements under data governance; a rock-solid, tangible expression of business requirements for those upcomin aspects of the next EDW subrelease that will support data elements under da governance; • • approved definitions for the entities and attributes involved; and approved definitions for the entities and attributes involved; and • •
  • 27.
  • 28. sample data that the company can use for testing and demonstrations once the necessary data transform modules have been programmed. sample data that the company can use for testing and demonstrations once the necessary data transform modules have been programmed. All this was accomplished via asynchronous workflow with little time spent in meetings listening to the business staff argue over definitions and little or no time spent performing ETL programming. All this was accomplished via asynchronous workflow with little time spent in meetings listening to the business staff argue over definitions and little or no time spent performing ETL programming.
  • 29. Have the DG team address this work product before any discussions or reviews are held with other stakeholders. This will help the team tighten any loose ends and prepare explanations of the meaning of certain processes.
  • 30. Have the DG team address this work product before any discussions or reviews are held with other stakeholders. This will help the team tighten any loose ends and prepare explanations of the meaning of certain processes.
  • 32. Engagement John Ladley, in Data Governance (Second Edition), 2020 John Ladley, in Data Governance (Second Edition), 2020 Business benefits and ramifications Business benefits and ramifications There are benefits from examining benefits. If the DG team is not tuned into business needs, it will start to see where they can clearly speak to the value of DG. How can DG be a business program if it is not tuned into business direction? I am still stunned at how many employees in all varieties of large and/or well-known companies have no idea where the company is supposed to be headed.5 There are benefits from examining benefits. If the DG team is not tuned into business needs, it will start to see where they can clearly speak to the value of DG. How can DG be a business program if it is not tuned into business direction? I am still stunned at how many employees in all varieties of large and/or well-known companies have no idea where the company is supposed to be headed.5 Besides the ultimate assignment of some financial value to DG, the business gets the material to think of DG as a business program vs an annoying IT effort. Besides the ultimate assignment of some financial value to DG, the business gets the material to think of DG as a business program vs an annoying IT effort. > Read full chapter > Read full chapter Data Quality Service Level Agreements Data Quality Service Level Agreements David Loshin, in The Practitioner's Guide to Data Quality Improvement, 2011 David Loshin, in The Practitioner's Guide to Data Quality Improvement, 2011 13.1.1 Business Drivers 13.1.1 Business Drivers Identifying the business drivers establishes the operational governance direction by enabling the data governance team to prioritize the information policies in relation to the risk of material impact. Listing the expectations for acceptable data suggests quantifiable measurements, and this allows business analysts or data stewards to specify acceptability thresholds related to the success criteria. By listing the critical expectations, methods for measurement, and specific thresholds, the business clients can associate data governance with levels of success in their business activities. Identifying the business drivers establishes the operational governance direction by enabling the data governance team to prioritize the information policies in relation to the risk of material impact. Listing the expectations for acceptable data suggests quantifiable measurements, and this allows business analysts or data stewards to specify acceptability thresholds related to the success criteria. By listing the critical expectations, methods for measurement, and specific thresholds, the business clients can associate data governance with levels of success in their business activities. And this connects two aspects that we have covered: the first is the categorization of business impacts of poor data quality described in chapter 1, and the second is the solicitation of business issues as part of the data quality assessment performed in chapter 11. Instead of just asserting the existence of a business impact, the important questions focus on comparing the costs of ignoring a problem to the costs of addressing it, determining the business risks of ignoring that problem, and determining how the answers to those questions merge to prioritize an action plan for monitoring and remediation. And this connects two aspects that we have covered: the first is the categorization of business impacts of poor data quality described in chapter 1, and the second is the solicitation of business issues as part of the data quality assessment performed in chapter 11. Instead of just asserting the existence of a business impact, the important questions focus on comparing the costs of ignoring a problem to the costs of addressing it, determining the business risks of ignoring that problem, and determining how the answers to those questions merge to prioritize an action plan for monitoring and remediation. > Read full chapter > Read full chapter
  • 34. Strategy John Ladley, in Data Governance (Second Edition), 2020 John Ladley, in Data Governance (Second Edition), 2020 Approach considerations Approach considerations This is not a task to take lightly.We often see a list of principles lifted from a published source, plopped into a document, and then mailed out with a decree that these are the principles. These rarely succeed. This is not a task to take lightly.We often see a list of principles lifted from a published source, plopped into a document, and then mailed out with a decree that these are the principles. These rarely succeed. The principles need to be derived and refined formally, not casually. For a low-profile effort, either settle on a generic SINGLE principle or defer principles until a subse- quent iteration (but use the first use case or iteration to demonstrate the need for principles). But when you decide to develop principles, you are starting the journey toward visibility. The principles need to be derived and refined formally, not casually. For a low-profile effort, either settle on a generic SINGLE principle or defer principles until a subse- quent iteration (but use the first use case or iteration to demonstrate the need for principles). But when you decide to develop principles, you are starting the journey toward visibility. Minimally invasive programs need to understand that at some point, a principle is required. There needs to be unification to the various efforts. Remember you are making something formal, which may exist in an informal manner. Business value and better data management are certainly an outcome, but long-term, you want a mind-set change, not a project success factor. So at some point, your DG team needs to formally approach principles. Minimally invasive programs need to understand that at some point, a principle is required. There needs to be unification to the various efforts. Remember you are making something formal, which may exist in an informal manner. Business value and better data management are certainly an outcome, but long-term, you want a mind-set change, not a project success factor. So at some point, your DG team needs to formally approach principles. The duration of this phase depends entirely on the ability of the DG team to tune the principles to their organization and get sincere and effective review from leadership. These activities can be a great opportunity to build consensus and increase the internalization of DG—or it can drag out and dissolve into a seemingly typical exercise of irrelevant meetings. If your organization starts to spend more time on “wordsmithing” principles so as not to offend anyone, you have encountered either one of two cultural issues. The duration of this phase depends entirely on the ability of the DG team to tune the principles to their organization and get sincere and effective review from leadership. These activities can be a great opportunity to build consensus and increase the internalization of DG—or it can drag out and dissolve into a seemingly typical exercise of irrelevant meetings. If your organization starts to spend more time on “wordsmithing” principles so as not to offend anyone, you have encountered either one of two cultural issues. 1. 1. The principles represent changes that are perceived as an admission the organization is deficient, or “bad,” which the sponsor needs to assuage. The principles represent changes that are perceived as an admission the organization is deficient, or “bad,” which the sponsor needs to assuage. 2. 2. The participants in the process are in fear of being pointed at as instigators of bad things. The sponsor needs to make sure the team knows it is covered and someone has their back. The participants in the process are in fear of being pointed at as instigators o bad things. The sponsor needs to make sure the team knows it is covered an someone has their back. Do not forget to spend time with the implications and ramifications of the principles. It is only fair to be able to explain why a principle has come about (the rationale). The implications are very important, not only from a perspective of understanding, but also because implications almost always provide requirements for policies. Do not forget to spend time with the implications and ramifications of the principles. It is only fair to be able to explain why a principle has come about (the rationale). The implications are very important, not only from a perspective of understanding, but also because implications almost always provide requirements for policies. If you have a lot of wordsmithing associated with development of your principles, the leader of the DG deployment may need to declare the principles are good enough. If you have a lot of wordsmithing associated with development of your principles, the leader of the DG deployment may need to declare the principles are good enough.
  • 35. They will evolve slightly anyway, so there is not much risk in starting to publicize them and begin policy development.
  • 36. They will evolve slightly anyway, so there is not much risk in starting to publicize them and begin policy development. The general outline for a principle should contain the following elements: The general outline for a principle should contain the following elements: 1. 1. Short description of the principle Short description of the principle 2. 2. Long description and full definition of the principle Long description and full definition of the principle 3. 3. Rationale, or a statement of why the principle is necessary Rationale, or a statement of why the principle is necessary 4. 4. Implications, or statements of potential and known impact the principle will have Implications, or statements of potential and known impact the principle wil have The most common mistake with principle development is to create policies and call them principles. If your principles are showing any of the following warning signs, you doing policy making: The most common mistake with principle development is to create policies and call them principles. If your principles are showing any of the following warning signs, you doing policy making: • • More than 10 principles: while not unheard of, when you have more than 10 principles you are starting to get very specific about what they mean. More than 10 principles: while not unheard of, when you have more than 10 principles you are starting to get very specific about what they mean. • • Using the description to declare how the principle will be enforced Using the description to declare how the principle will be enforced • • Mentioning specific business areas or functions within the principle Mentioning specific business areas or functions within the principle In general, you will start with 12–14 principles and then whittle them down to 3–4. In general, you will start with 12–14 principles and then whittle them down to 3–4.
  • 37. Let’s consider the Playbook framework again as shown in Fig. 6.1 and look at the potential workstream tracks.
  • 38. Let’s consider the Playbook framework again as shown in Fig. 6.1 and look at the potential workstream tracks. Figure 6.1. Business data governance framework. Figure 6.1. Business data governance framework. The Playbook framework implemented in Microsoft Excel is a wonderful tool for managing the business vocabulary, critical data elements, and initial governance implementation. However, Excel is not the only tool the governance team may need to scale to large enterprise capabilities. As you work through the activities across the maturity stages, you will need more than Microsoft Office technology. The Playbook framework implemented in Microsoft Excel is a wonderful tool for managing the business vocabulary, critical data elements, and initial governance implementation. However, Excel is not the only tool the governance team may need to scale to large enterprise capabilities. As you work through the activities across the maturity stages, you will need more than Microsoft Office technology. Most of the activities in the Define stage require more functionally robust technology support to enable maturity scale improvements. These technical data management tools have traditionally been confusing to business stakeholders, and today we are asking those individuals to sponsor the selection of these tools.Additionally the tools have lacked functionality to support the business governance of data, and technology management professionals have shouldered the burden of educating the business and working hard to fill in the technology gaps. Your IT or procurement group already have a process for selecting technologies, but if you do not have a process defined we recommend you follow one similar to the selection process defined in the next section. Most of the activities in the Define stage require more functionally robust technology support to enable maturity scale improvements. These technical data management tools have traditionally been confusing to business stakeholders, and today we are asking those individuals to sponsor the selection of these tools.Additionally the tools have lacked functionality to support the business governance of data, and technology management professionals have shouldered the burden of educating the business and working hard to fill in the technology gaps. Your IT or procurement group already have a process for selecting technologies, but if you do not have a process defined we recommend you follow one similar to the selection process defined in the next section.