TOP_PASSOS GOV DADOS.pdf

Data Governance Team
Related terms:
Related terms:
Business Intelligence, Internet of Things, Data Governance, Master Data Manage-
ment, Data Governance Program, Programme Management, Term Deﬁnition
Business Intelligence, Internet of Things, Data Governance, Master Data Manage-
ment, Data Governance Program, Programme Management, Term Deﬁnition
View all Topics
View all Topics

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.
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)

suﬃcient “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 oﬀ.

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 beneﬁts
listing, and target business model called for by the agile EDW project deﬁnition
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 oﬀered 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 ﬁrst 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 workﬂow-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.

Engagement
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
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

Recommended

Recommended

More Related Content

Similar to TOP_PASSOS GOV DADOS.pdf

Similar to TOP_PASSOS GOV DADOS.pdf (18)

Recently uploaded

Recently uploaded (20)

TOP_PASSOS GOV DADOS.pdf