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 email@example.com At VALU, the MITRE “Island” 202-XXX-XXXX © 2013 The MITRE Corporation. All rights reserved.
Pages to are hidden for
"Data Governance at VALU"Please download to view full document