Data Governance at VALU

Document Sample
Data Governance at VALU Powered By Docstoc
					Data Governance and Analytics at
VALU

An Orientation for the VALU Directors
Sept 23, 2013




                                        © 2013 The MITRE Corporation. All rights reserved.
                                                             | ‹#› | 


My Task: VALU Data Use Plan

                      1.   What do we have today? Identify and
                           characterize baseline of databases and
                           uses among VALU stakeholders using
                           a questionnaire that will later be
    Current Data           compiled.
  Infrastructure &    2.   What do we need? Interview to verify
      Practices            stakeholders prioritized requirements
                           using data for reporting, queries and
                           dashboard support.
     Stakeholder 
      Practices &     3.   Create a plan of practice? From the
     Requirements          collected items (from #1 & 2), develop
                           an actionable plan for use of data and
      VALU Data
        Plan
                           standard reporting for VALU.
         PRE          4.   What are the future options leading to
         SEN
          T                an integrated plan and standard
         OPTI
         ONS               practices? Analyze and present the
                           findings with options as a final
                           deliverable.
                                                          | ‹#› | 



My Task for VALU

1. Identify the outputs of VALU from historical questions, 
   periodic reporting, Dashboard, other. [OUTPUTS]
2. Identify the repository and source data to determine: 
   “what does VALU need on data?” [INPUTS]
3. Local use: what do you need? Limitations: what issues 
   do you encounter to fulfill your tasks? Are there future 
   requirements on reporting or use of data? 
   [Questionnaire]




© 2013 The MITRE Corporation. All rights reserved.
                                                                                     | ‹#› | 



Hi-level View
Data is a fundamental asset, enables VALU processes and core to VALU’s performance




                  © 2013 The MITRE Corporation. All rights reserved.
                                                                                                                                         | ‹#› | 



Frequent Thought Questions…..
§   What is a data-driven organization? How does this look for VALU?



§    What are the benefits to “being analytic”? How could VALU benefit?



§   What answers can analytics provide? What answer does VALU provide and need to provide?




                                                                               Source: Tom Davenport, “What it means to put analytics to work?”

§   When are analytics not practical?
     –    No available time
     –    No prior history or history is misleading
     –    Decision makers already have considerable experience
     –    Variables cannot be measured. 




© 2013 The MITRE Corporation. All rights reserved.
                                                                             | ‹#› | 



Benefits of Data Governance

“Data governance is the discipline of administering data and information assets 
across an organization through formal oversight of the people, processes, 
technologies and lines of business that influence data and information outcomes 
to drive the VALU mission of the VA.”


§ Ensures authority and accountability for the data is defined.
§ Provides a clear escalation path for users and data stewards to raise issues 
  in an efficient manner and get a timely response
§ Provides transparency into lineage, data quality, and data risk
§ Improves data quality and manages data risk through adoption of best 
  practices
§ Promotes collaboration on data issues between university areas and between 
  the operations & IT




© 2013 The MITRE Corporation. All rights reserved.
                                                                    | ‹#› | 



 Post-it® Focus Group Session with Directors

§ Question: What are the uses and limitations (what is missing or
  could be better) of data in VALU?




 © 2013 The MITRE Corporation. All rights reserved.
                                                                    | ‹#› | 



 Post-it® Focus Group Session with Directors

§ Question: What are the uses and limitations (what is missing or
  could be better) of data in VALU?




 © 2013 The MITRE Corporation. All rights reserved.
                                                                                                | ‹#› | 




                Appendix: A Primer on Data
                Governance




© 2013 The MITRE Corporation. All rights reserved.   © 2013 The MITRE Corporation. All rights reserved.
                                                                                                                                 | ‹#› | 

 Notional Data Governance Framework
Data governance should be an ongoing program, not a project that ends. It’s not enough to standup data
governance bodies; there’s work to move the organization forward and change the culture.




                                                                                          §   The Executive Level is composed of 
                                                                                              an executive sponsor and members of 
                                  Executive           Provides sponsorship
                                                                                              senior management. These are the 
                                    Level             and leadership                          decision makers, setting the 
                                                                                              enterprise vision for data.
                            s
                       tion




                                Decision Making                                           §   The Management Level are typically 
                   era




                                                              Establish data                  mid-level management.  They execute 
                  Op




                                                              management policy &
                        Management Level                      standards
                                                                                              the university vision but they are also 
                     
                nce




                                                                                              trusted advisors to the executive who 
             rna




                           Policy & Operational
                                                                                              frame options and provide 
           ove




                                Decisions                                                     recommendations.
        ta G




                                                                   Implement data
                                Data Stewards
                                                                   management             §   Data Stewards can be a variety of 
      Da




                                                                   policy &                   levels. They’re responsible for day-to-
                                                                   standards
           Requirements Definition, User Acceptance,                                          day operations of functional 
            Data Quality Monitoring and Resolution
                                                                                              processes that create/maintain data. 
                                                                             Align with       They are the backbone of data 
               Data Users, External Partners, etc.                           policy &
                                                                             standards
                                                                                              management and governance.
                                                                                          §   Data Governance Operations
                                                                                              (DGO) is a small group that supports 
                                                                                              each level of the data governance 
                                                                                              hierarchy.
 © 2013 The MITRE Corporation. All rights reserved.
                                                                                                                   | ‹#› | 



Roles & Responsibilities for the
Executive Level
§       Chaired by the executive sponsor, ideally a C-level officer with a
        high stake in quality data like the CFO or CIO. Comprised of leaders representing
        each part of the business; no more than 10 people. May be facilitated by the head of
        Data Governance Operations.

§       Example Roles:
           §     Provides leadership, setting the vision for enterprise data management.
           §     Makes decisions about resource and budget allocations for data initiatives based on enterprise 
                 business goals and risk.
           §     Oversees corporate reports and dashboards.
           §     Ensures legal and compliance standards are followed.

§       Example Responsibilities:
           §     Engages the business community and identifies members of the Management Level.
           §     Approves data management principles, policies and standards.
           §     Promotes the use of enterprise data assets like MDM and an Enterprise DW.
           §     Approves data-related strategies and roadmap priorities.
           §     Ultimate decision point for escalated issues of risk, resource and budget allocations.

§       Meetings: Probably monthly, could be concurrent with existing executive meetings.




    © 2013 The MITRE Corporation. All rights reserved.
                                                                                                                    | ‹#› | 



Role & Responsibilities for Management
Level
§     Identified by the Executive Level; includes representatives from both business and IT.
      May be chaired by the head of Data Governance Operations.

§     Example Roles:
          §     Executes the Executive Level’s vision.
          §     Brokers data requests from data stewards and users.
          §     As trusted advisors to the Executive Level, frames options and 
                provides recommendations.

§     Example Responsibilities:
          §     Defines data management principles, policies and standards for Executive Level approval.
          §     Educates their areas on practices and promotes their use of enterprise data assets.
          §     Identifies data stewards from in their areas.
          §     Coordinate with IT to publish the list of authoritative sources.
          §     Collaborates on data-related strategies and roadmap priorities.
          §     Depending on authority delegated by the Executive Level, the Management Level may decide 
                escalated issues or just frame options and make recommendations to the Executive Level.

§     Meetings:
          §     Could be once a week to every other week; initially while the organization is being stood up and 
                defined, meetings could be more frequent.




    © 2013 The MITRE Corporation. All rights reserved.
                                                                                                                      | ‹#› | 



Levels of Governance with estimated
time commitments
Data Governance Role                                  Likely Time Commitment
Executive Level Members                               •   1 hour update/prep session per month with associated 
                                                          members at the Management level
                                                      •   1-2 hour group meeting per month

                                                      Total: 3 hours per month

Management Level Members                              •   1/2 hour meeting per week with associated Data Stewards
                                                      •   1-2 hour group meeting per week initially, may move to 
                                                          biweekly later
                                                      •   1 hour update/prep session per month with their Executive 
                                                          member
                                                      •   4 hours per month on escalations, action items or 
                                                          supporting work

                                                      Total: 13 hours per month initially dropping to 10

Data Stewards                                         •   1/2 hour meeting per week with associated Management 
                                                          level members
                                                      •   Time on data-specific responsibilities could vary widely 
                                                          depending on whether quality expectations are understood, 
                                                          scope/frequency of data profiling, state of data quality & 
                                                          metadata, backlog of issues, etc.

                                                      Total: 16 to 40 hours per month 

Data Governance Operations (DGO)                      • To support 3 working levels of data governance, this could 
                                                        easily be 2 full-time people and more depending upon how 
                                                        broadly their role is defined, e.g. if they facilitate escalation 
                                                        of issues or actively participate in researching and resolving 
                                                        issues
 © 2013 The MITRE Corporation. All rights reserved.
                                                                                                | ‹#› | 



What are your subject and data categories?

§ Most enterprises with a data modeling function have high-level subject areas (~10).
     – Useful for general communication purposes, e.g. describing what your enterprise does in 
       1 sentence to someone on the street,  or for categorizing data models.
     – Too high for useful discussions of stewardship, etc.
§      Your data modeling function already may have defined data categories (~50) that
       serve as a level in between subject areas and entities.
          − This is a reasonable and achievable level for which you can define a useful list data 
                stewards (& authoritative sources) that can be refined and fleshed out over time.
          − Prioritize your data categories based on your issues backlog. 
                       Subject Area                   Data Category

                       Customer                       -   Customer Profile
                                                      -   Financial Risk
                                                      -   Preferences


                       Employee                       -   Employee Profile
                                                      -   Dependents
                                                      -   Benefits
                                                      -   Performance Evaluations




© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                      | ‹#› | 



What is a Data Governance Office/Function?

A small group that supports each level of data governance. It’s not always visible but is critical to
the success of your data governance program.

Example Roles:
§   Keeps data governance moving forward.
§   The glue that brings the levels of Data Governance together.

Example Responsibilities:
   § Provides ongoing meeting support, including scheduling meetings for the Executive and Management level bodies,
     sending out agendas and meeting materials, documenting meeting minutes, and following up on action items.
   § Works with others to draft material for data governance bodies to discuss.
            § When standing up data governance, this can be intense and could include drafting charters, 
              data principles, policies and standards or guidelines, the escalation process, and processes / 
              templates for Data Stewards. 
            § On an ongoing basis, it would include the creation of meeting materials for the bodies or 
              coordinating the creation of those materials.
    § Creates and manages the communications plan to rollout data governance to the enterprise.
    § Facilitates escalation of cross-organization issues and communicates issues and decisions to impacted parties. Could
      optionally include a more active role that participates in research and management of resolution of enterprise data
      quality issues.
    § Fields data questions from Data Stewards and business users.
    § Measures and reports on Key Performance Indicators and metrics for data governance, data management, and the
      data ecosystem as a whole.


     © 2013 The MITRE Corporation. All rights reserved.
                                                                         | ‹#› | 



Options for Moving Forward

§ Possible Approaches
  1. Dive in… to resolve “fires” (issues and risks) to figure out the 
     “enterprise” perspective as you go. 
  2. Build a framework for the “enterprise” only then proceed.
  3. Use a hybrid approach.

§ Things to Consider:
  – Segment work in achievable chunks.
  – Show progress and demonstrate value.
  – Achieve momentum to keep people engaged.
  – Tie back to your original drivers for establishing data governance 
    in the first place

    Example: Collaborating on issues


© 2013 The MITRE Corporation. All rights reserved.
                                                                         | ‹#› | 



Example for Collaborating on Issues

1.       Diving right into resolving issues engages people, shows
         value, and may achieve momentum (if you’re successful).
     – Risk: if you don’t give people a framework to solve issues, 
       they may not solve them well. The results may not be 
       consistent across issues, may not benefit the enterprise as a 
       whole, and may not move the culture forward.
2.       First building out an enterprise framework for resolving
         issues, e.g. getting agreement on data management
         principles, stewardship, and authoritative sources, can
         move the culture forward and ensure consistency.
     – Risk: this approach takes longer to show tangible value and if 
       you have pressing issues, this may be perceived as “just 
       talk” and result in a loss of momentum. 
3.       Use a hybrid: Use the data governance bodies to compile
         and prioritize existing issues and begin addressing low
         hanging fruit /pressing issues. Simultaneously try to
         move the ball forward on principles, stewardship, and
         authoritative sources, in a very scoped way, etc.
     – Risk: this is a tricky balancing act.

© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                  | ‹#› | 



Hybrid Option:                                       Keep it simple.


First, use DGO to define Issue Management and Escalation processes
     §    Ensure you have a DGO email account for communication and a website to publish issues and supporting 
          information on the processes, roles, frequently asked questions, etc.
     §    Will the DGO research issues? Facilitate? Or just track? 
     §    How will they track? What kinds of metrics or reporting does management need?
     §    When and how should an issue be escalated?

Track 1                                                         Track 2 in parallel

Use the management-level data governance body  Simultaneously, introduce them  to data 
to start compiling/categorize issues, offline (aka  management principles. 
homework). 
                                                    Use the DGO to draft materials; this also allows 
                                                    you to introduce concepts you want to include 
                                                    (aka plant seeds).

Begin addressing issues that are “low-hanging        Identify existing Data Stewards and authoritative 
fruit”: urgent but relatively easy issues that will  sources but scope your efforts and prioritize 
provide some quick wins and buy you time.            based on your issues
• Who do I talk to about x? Who has authority to 
     approve y? Who can tell me which of my ‘top 
     priorities’ are really the most important?

© 2013 The MITRE Corporation. All rights reserved.
                                                                       | ‹#› | 



Data Management Principles

   Why do you need data management principles?
    • Principles convey an enterprise approach. 
    • They are foundational statements of organization values. 
    • They are a means to begin to change behavior.

• Getting “buy-in” may take time but just discussing data management
  principles starts to move the culture forward.

• If you can’t reach agreement on a basic concept like “data should be
  managed as an enterprise asset”, you’re not likely to get agreement on
  the more complex data issues such as accountability, collaboration, or
  the need to share data.

  Principles also drive policy, standards, and guidelines.




© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                     | ‹#› | 



Principles/Policy/Standards
                                                                                        Illustrative Example



  DM Principle                                       DM Policy                        DM Standard
                                                                                       Projects introducing new 
                                                                                       data to the organization 
                                                                                      must collaborate with Data 
                                                                                       Governance to identify a 
                                                                                            Data Steward
                                                          Data Stewards are 
             Data must be managed as                   primarily responsible for       Projects using data must 
             an asset with real value to               data quality and integrity     include the Data Steward 
                  the organization                     for a given data domain           as a stakeholder and 
                                                        throughout its lifecycle       collaborate with them on 
                                                                                             requirements.


                                                                                      When data is integrated for 
                                                                                       users, the Data Steward 
                                                                                         must be involved in 
                                                                                         defining integration 
                                                                   DM                       requirements. 




© 2013 The MITRE Corporation. All rights reserved.
                                                                                                  | ‹#› | 



Defining Principles

1.       Use the Data Governance Office (DGO) to draft a set of principles, rationale
         and implications to start the discussion.
          § Try to limit the list to no more than 10.
          § Keep statements of principle concise.
          § Focus on what, not who or how.

2.       Have the Management level body discuss them, including the rationale and
         implications for each principle. This is an investment of time that will:
          § Get everyone on the same page regarding data governance
          § Identify other candidate principles, possible risks and candidate standards
          § Help later to communicate to the enterprise, e.g. in Data Steward training and for 
            website FAQs

3.       Vote to adopt the principles; ask the Executive level to endorse them too.

4.       Review existing policies and related standards for conflicts and gaps. Look
         under topics like data management, privacy, security, data classification, or
         data dissemination.



© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                       | ‹#› | 



An Example Principle and its Rationale & Implications

Principle: Data must be managed as an asset with real value to the organization
Rationale (What does the statement mean? Why is it important)
Business decisions are based on accurate and timely information.  As an agency asset, data and metadata have real, 
tangible value and should be carefully managed to ensure the enterprise knows where data resides, understands its 
quality, knows who’s accountable for it, and can access it when needed.
The true value of information is not realized when it remains in isolated pockets built to meet only local needs; shared, 
integrated information results in consistent and improved decisions. Shared Services and Systems such as an 
Enterprise Data Warehouse (EDW) or Master Data Management (MDM) solution can facilitate the business’ access to 
consistent data.  Note that some data will be localized and need not be managed on an enterprise level or shared. 
Identifying what should be shared is important, since managing data at an enterprise level is expensive.
Implications (What are the challenges or even barriers to living by this principle?)
Data is owned by the enterprise, not by systems or individuals.  The enterprise should recognize and formalize the 
responsibilities of roles, such as Data Stewards, with specific accountabilities for managing data.  A data governance 
framework and guidelines must be developed to allow Data Stewards to coordinate with their peers, and communicate 
and escalate issues when needed.  Data should be governed cooperatively to ensure the interests of Data Stewards 
and Users are represented and value to the enterprise is maximized. 
The enterprise should design an enterprise data architecture with systems of record and other authoritative sources as 
well as guidelines for process changes.  The enterprise needs buy in and commitment from both business areas and IT 
for this approach to achieve an effective enterprise data management environment that supports the business while 
managing risk and cost.




© 2013 The MITRE Corporation. All rights reserved.
                                                                     | ‹#› | 


Other Examples of Data Management
Principles
§ Data must be governed cooperatively to ensure the interests of both 
  Data Stewards and Users are represented and value to the 
  enterprise is maximized. (separate or implication of asset?)
§ Data must be managed as an asset with real value to the 
  organization.
§ Enterprise data must be shared across the enterprise and beyond.
§ Enterprise data must be accessible across the enterprise.
§ Each data element needs a system of record (SOR) and/or 
  authoritative sources.
§ Data must be collected, used, and shared in ways that respect 
  individuals' privacy rights and must be kept secure.
§ Data must be compliant with laws and regulations.
§ Enterprise data must have defined quality requirements that are 
  measured, published, and enforced.


© 2013 The MITRE Corporation. All rights reserved.
                                                                                              | ‹#› | 



Data Steward Role
                           “A Data Steward’s role is to ensure that data assets are 
                           understandable, trusted, accessible, and interoperable.” 2
§        “Understandable” means a responsibility to define the data, e.g. by maintaining and 
         publishing metadata. There are also implications such as not reusing fields for 
         multiple purposes.

§        “Trusted” requires metadata but also controls (predictive, detective, and corrective) 
         to ensure the quality of the data and the quality should be published for users.

§        “Accessible” is a responsibility to provide the data in some way to users who have a 
         legitimate business need. E.g. access to the SOR for transactional systems or via file 
         extracts if performance is a concern, loading the data to the analytics environment for 
         analysts, etc.

§        “Interoperable” at a minimum ensures that the data is mapped to the enterprise 
         logical model, if you have one, or a common standard and these mappings should be 
         published and accessible. 


2   Peter Goodstein, MITRE Corp., Critical Success Factors for Data Sharing, 2013



© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                                                            | ‹#› | 


Industry-Typical Data Stewardship
Responsibilities
§   Individual Responsibilities:
          1.        Manage day-to-day business processes that create data and supply shared data to the 
                    enterprise.
          2.        Implement and facilitate requests for new or changed data.
          3.        Maintain the quality of data for their respective domain.
               a.     Work with known consumers to define data quality requirements/expectations.
               b.     Periodically execute data profile reports.
               c.     Resolve data conflicts and inconsistencies within their authority.
               d.     Coordinate with other groups as needed to drive resolution of cross-area data issues.
          4.        Coordinate with their data governance representatives, e.g. to field data requests and 
                    escalate issues.
          5.        Maintain/publish metadata corresponding to the data for which they are responsible.                            Destroy         Create


          6.        Mentor users in Data Stewardship.
          7.        Actively participate (defining requirements, user acceptance testing) in projects for 
                    capabilities that support their business processes.                                          Archive           Focus on the                        Store


          8.        Participate as a stakeholder (requirements review) in projects for capabilities that will                      data life-cycle, 
                    use the data for which they are the Steward.
                                                                                                                                   not systems
§   Group Responsibilities? Data Stewardship may or may not work collectively:
     1.        May draft a charter for approval by the Management level data governance body.                        Disseminate                               Share



     2.        Collaborate with users to monitor business patterns and trends in the data. 
               Communicate/escalate to the data governance bodies as needed.                                                                 Use



     3.        Promote standardization of data and iteratively work to standardize names, definitions, 
               quality expectations, etc.
© 2013 The MITRE Corporation. All rights reserved.
                                                                                                        | ‹#› | 



Scoping the Search for Data Stewards

                    Even a high-level list of Data Stewards can be a useful starting point.


§ At what level do you begin to identify Data Stewards (and 
  authoritative sources)?                     Subject Area Data Category

       Subject Areas (~10)                           Too high a level    Customer    -   Customer Profile
                                                                                     -   Financial Risk
       Data Categories (~50)                         Just right 3                    -   Preferences
                                                                         Employee    -   Employee Profile
       Entity (hundreds)                             Too detailed -                  -   Dependents
                                                                                     -   Benefits
                                                     at least to start               -   Performance 
                                                                                         Evaluations



§ By starting at the data category-level, you can fairly quickly define a 
  useful list Data Stewards that can be refined and fleshed out in time.
§ Prioritize your data categories based on your issues backlog.

3   See appendix for additional detail.



© 2013 The MITRE Corporation. All rights reserved.
                                                                                                | ‹#› | 



Defining Data Stewardship

Most organizations have people implicitly doing elements of data stewardship or the business
wouldn’t function. However, in many organizations stewardship is informal and varies in scope
and responsibilities across the enterprise. It may be done by a mix of IT and business and
stewards may not be clearly identified or published.


1.     Discuss data stewardship with the Management level body, what it means in general for
       your organization, and compared to an industry-typical Data Steward role.


2.     Ask each representative to identify the data categories their organizations create/maintain
       and identify who is fulfilling the role of Data Steward today (business or IT).
     – Who manages the business processes that create and maintain the data?
     – Who do you go to when you need to understand the data?


3.     Connect identified Data Stewards with their representatives from the data governance
       bodies


4.     Communicate Data Stewards to the enterprise and recognize them for the work they do.




© 2013 The MITRE Corporation. All rights reserved.
                                                                                                        | ‹#› | 



Evolving Data Stewardship

Once you have a list of Data Stewards by data category, you’re in a better position
to address data issues but you can also begin to evolve Data Stewardship at your
enterprise:
§ If the Data Stewards for a data category are all IT, try to identify the business person  responsible 
  for the business process. Establish a line of communication between them and look for 
  opportunities to get the business process owner more involved.


§ Don’t be surprised if you have multiple Data Stewards for a given data  category. Try to get them 
  talking, e.g. to identify differences in business processes and rules that could impact data users. 
  Over time, try to align how they manage their data. 


§ Try to connect Data Stewards and known data users to discuss data quality expectations and 
  data issues.


§ Opportunistically look for opportunities align the role of Data Steward across the enterprise and to 
  move toward a more industry-typical role and responsibilities.


§ Refine your Data Steward list down to the entity-level, or even attribute-level, only if necessary.


© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                                              | ‹#› | 



Authoritative Sources

                       Even a high-level list of authoritative sources  can be a useful 
                       starting point  for data governance, data management 
                       processes, and data architecture improvements


An authoritative source is one that is considered “official”.

Why do we need authoritative sources?
§ Provide a resource for business users and technical staff to determine 
  appropriate options for the data they need4.
§ Improve consistency of operational decisions and management reporting, 
  reduces data reconciliations.
§ Used by data governance in identifying data stewards and focusing data 
  quality improvement efforts.
§ Provide a starting point for data architecture improvement and the use of 
  authoritative sources simplifies enterprise data flow over time.

4Where in the data environment a user goes to get data depends upon what their doing with it, their specific requirements, as well as which
systems are authoritative.



© 2013 The MITRE Corporation. All rights reserved.
                                                                                  | ‹#› | 



SOR vs. Authoritative

§ A system of record (SOR) is the point at which data is created or
  imported, and maintained.
§ SORs are authoritative by definition.
§ The SOR concept applies to all data, not just personally
  identifiable information (PII).
     – While the term “system of record” is used in the Privacy Act, this 
       legislation dates from the 1970s when information was paper-based and 
       large IT systems weren’t common. 
     – The Privacy Act defines “system” very generally as a “group of records” 
       and the intent of the SOR Notice (SORN) is simply to tell the general 
       public what kinds of information a government agency tracks and how it’s 
       used, without regard to how it’s physically stored or implemented in 
       today’s IT systems. 
     – If you work in the federal government and find this a source of confusion, 
       it may be useful to adopt the term “architectural SOR” to distinguish it from 
       a privacy SORN.


© 2013 The MITRE Corporation. All rights reserved.
                                                                                                         | ‹#› | 



Other Authoritative Sources

Most enterprise data architectures include limited, managed redundancy in the
form of enterprise shared solutions such as Masters, an Operational Data Store, or
an Enterprise Data Warehouse (EDW). Enterprise shared solutions are often built
to be authoritative.
§ Alternate systems, or proxies for the SOR, can be approved as authoritative if
   they meet certain criteria.
                                                     Customer               Enterprise 
                                                      System                   DW
                                                      (SOR)                  (Proxy)


§ What constitutes “authoritative”? Example criteria could include:
     • Gets data from the SOR or another authoritative source.
     • Meets some standard of documentation (e.g. data model, published dictionary, published 
       source to target lineage, etc.)
     • Has controls in place for copied data to ensure it is copied correctly (Record counts, checksums, 
       detective reports, etc.)
     • “Certification” by the Data Steward. “Certification” could include the following:
          • The requirements and test results for data movement and integration (virtual or physical) 
            have been approved by the data steward.
          • The Data Steward is notified of data quality issues and as needed, participates in the 
            resolution or escalation of the issue.
© 2013 The MITRE Corporation. All rights reserved.
                                                                                  | ‹#› | 



Authoritative Sources Template

§          When capturing authoritative sources, consider capturing the
           following information:
       –        Subject area, e.g. Customer
       –        Data category, e.g. Financial Risk
       –        System/Database Name
       –        Whether it’s an SOR or an approved proxy
       –        Description of the data. This might just be the data category 
                description but if you know more detail, such as specific entities, 
                record it! E.g. the customer’s credit report
       –        Population if relevant, e.g. SOR for customers of catalog sales
       –        Transition state if relevant, e.g. the EDW is authoritative but only 
                has customers that are approved to do business.
       –        Use notes to capture miscellaneous information

© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                                              | ‹#› | 



    How do you find information on
    Authoritative Sources?
§   Architecture documents, if they exist
§   Lineage metadata for a data warehouse
§   SORNs for PII5
§   In many organization, this information is in people’s
    heads, however, and you just have to find the right
    people:
     – Business and technical system SMEs
     – Known Data Stewards

5Ideally SORNs should be created by type of data, e.g. Employee Health Records, and not be tied to physical IT systems, which may result in
multiple SORNs for the same type of data. However, this practice also means that SORNs are a possible source of information to determine
authoritative sources.




     © 2013 The MITRE Corporation. All rights reserved.
                                                                                                    | ‹#› | 



Evolving Your Data Architecture (Example)
                                                                                -   Are the SORs 
                                                                                    clear? 
       Customer                                                                 -   If there are multiple 
                                                                                    SORs for a type of 
       System 1                                                                     data, do their edits 
      (Web-sales                                                                    match?
        SOR)                                         Customer   Enterprise 
                                                                                -   How is data 
                                                      Master       DW               shared?
                                                      (Proxy)    (Proxy)
                                                                                -   Are there unmet 
      Customer                                                                      integration needs?
      System 2                                                                  -   Where is there 
      (Catalog                                                                      redundancy? Is it 
     Sales SOR)                                                   Silo’d            justified?




                                                          X
                                                                                -   Are there systems 
                                                                Warehouse
                                                                                    getting data from 
                                                                 (Copy)             non-authoritative 
                                                                                    sources? What’s 
                                                                                    the risk?
           Fraud
          System                                                Key
          (Copy)                                                         Authoritative
                                                                         Not Authoritative
© 2013 The MITRE Corporation. All rights reserved.
                                                                                                                     | ‹#› | 


 How much formality do I need?
 What is achievable right now?

Data Governance 
bodies deal with 
                                           Informally agreed           Principles and           Mandatory data 
decisioning, policy,                       upon principles, roles      roles are                standards as well 
standards &                                and guidelines              formalized, e.g. in      as guidelines
guidelines                                                             policy

                                                        Less                                           More 
                                                       Formal                                         Formal
Assurance (aka 
                                         Consulting-based            Sample-based or           Mandatory project 
enforcement) 
                                         project reviews where       criteria-based project    reviews with 
processes measure                        project is advised          reviews and data          escalation to data 
adherence to policies,                                               governance is informed    governance who can 
standards & guidelines                                                                         stop a project
defined by the data 
governance bodies



 §     The degree of formality is based on culture, priorities and data maturity.
 §     Formality tends to increase over time. 
 §     Maturity of data governance and assurance processes go hand in hand.
 §     Data governance should be business-driven but assurance processes may be delegated to IT, e.g. 
       you might focus on new projects and leverage existing life-cycle reviews to measure adherence to 
       data management principles, policies, and standards.

  © 2013 The MITRE Corporation. All rights reserved.
                                                                                    | ‹#› | 



 Conclusion
ü Use a hybrid approach to move your enterprise forward:
  – Start to address data issues to engage people and gain momentum but 
    simultaneously establish an enterprise framework. 
ü Take actionable steps:
  1.      Establish your DGO.
  2.      Adopt data management principles to start to change the culture.
  3.      Identify existing data stewards and authoritative sources, but at the data 
          category-level to ensure a quick and useful list.
  4.      Determine how much formality makes sense for right now.
ü This approach will position you to do the following:
  – Address current issues. 
  – Expedite new projects and augment existing project life-cycle reviews to 
    include data considerations.
  – Evolve data stewardship at your enterprise.
  – Evaluate your existing data architecture and evolve it overtime.
  © 2013 The MITRE Corporation. All rights reserved.
                                                       | ‹#› | 



 Questions

§ Any questions?




§ Contact Information:
       Danny Moore
       MITRE Corp.
              703-987-8456 cell
              dmoore@mitre.org
              At VALU, the MITRE “Island”
              202-XXX-XXXX

  © 2013 The MITRE Corporation. All rights reserved.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:9/24/2013
language:English
pages:37