1 / 71

DRM Implementation Guide: IAC White papers

DRM Implementation Guide: IAC White papers. -DAS Support Status and Working Group December 3, 2007. Business & Data Goals. drive. The Rule: All 3 pillars are required for an effective data strategy. Governance. Data Strategy. Information Sharing/Exchange (Services).

usoa
Download Presentation

DRM Implementation Guide: IAC White papers

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. DRM Implementation Guide: IAC White papers -DAS Support Status and Working Group December 3, 2007

  2. Business & Data Goals drive The Rule: All 3 pillars are required for an effective data strategy. Governance Data Strategy Information Sharing/Exchange (Services) Data Architecture (Structure) Goals drive; governance controls; structure defines; and services enable data strategy. Information Sharing/Exchanges key Pillar of Data Strategy

  3. Inventory Discovery Data Oversight Definitions/Semantics Policy & Procedures Structure Communities of Interest Education/Training Syntax Search Processes and Practices Pedigree Data Registries Issue Resolution Authoritative Sources Data Catalogs Metrics/Incentives Security/Protection Data Shared Spaces Data Transfer Standards Access Services Brokering Mediation Information Sharing/Exchange (Services) Data Architecture(Structure) Governance Bringing Order to the Many Elements

  4. Mapping the Strategy to the DRM Our Focus! Data Contextenables… Data Descriptioncaptures… Data Sharingguides…

  5. BRM DRM Common Understanding Consistent Models COI Cross-Agency Business Need Improved Discovery Rapid Harmonization Increased Information Sharing Org 1 Org 3 Org 2 Screening Emergency Management COIs are both Intra and Inter- Organization Law Enforcement Intelligence Agility … The DRM is Business-Driven

  6. Information Exchange Summary Logos Quote on Success………………………… and lessons learned.” - XXXXXX, CIO, YYYYYYY Type of Practice Information Sharing/Exchange Summary Information Sharing Techniques used • What are the organizations that must share information • Amount of data by topic areas • Complexity • Number of users with • Cross Enterprise Sharing • Describe the solution • Describe the set of practices that have been used….. • Any special technology used- ontologies, translators, policy management, meta data management? Challenges Faced Results & Lessons Learned • What are the current results? • What are the long term expected results? • How did it effect the performance on given areas? • What are some of the lessons learned? • What are key success factors? • What was big problem you faced? (Pain Points) • How was it overcome? (Coping Strategies) • What would you recommend? For those starting? Those mature organizations? • What should be avoided?

  7. Information Sharing and Exchange Projects • Global Justice Network and NIEM • Environmental Data Network • Army-NATO Exchange • National Health Interoperability Network (NHIN) • IC Information Sharing • Others……many….

  8. THE END

  9. DRM Implementation White Papers • DRM Getting Started Task • Issues involved with getting started- what, why and how • Draft SOW to bring on your Data Architecture Contractor • Getting Management Engaged and interested • Getting Started Workshop • Business and Data Process Scenarios and Data Architecture Planning • Assessment and Information Gathering Templates • Strategic Data and Information Value Analysis • Early Data Governance- a little data governance goes along way- focus! • DRM Value Trade-offs and Proposition • Data Value aligned with Strategic Direction • Balancing Modeling and Strategic Data Management versus tools and techniques for data services, data integration and transformation • Measuring your Data Transformation: Progress and Outcomes • Data Architecture early and often results- success stories

  10. DRM Implementation White Papers Interoperability and Information Sharing Practices • Planning for What you have and what you want • Analysis with the NIEM- IEPD and other techniques • Meta Data Patterns and their use • Standard set of data services for data and data services connecting with policy, identity, and entitlement-based security • Interoperable Data Reference Model – having consistent standards first data references with a master data management • Identifying and resolving conflicts early with a verification and validation process built in.

  11. Data Architecture Support for DRM Start-Up How Data Architecture can support DRM during the critical Start-Up Phase

  12. Data Architecture Quick Start Initiatives 4- 6 months……… Project Initiation: DA Sub-phase BRM:SRM: Alignment & Linking Charter: Value Proposition Precipitating Events Early Results: Outcomes and Next Steps Select: Situation Focused Data Models and Design Early Discovery & Definition Early Design & Focused Data Model /Implementation Leverage: Situation Focused Solution Alignment Selected Project Integration

  13. Project Initiation: DA Sub-phase • Objective: • To ensure project scope is well defined, and that important roles are defined • Provide a “quick start” 4-6 months with early results for a “sponsors” key concerns and value from Data Architecture. • Develop Project Charter • Identify Project Sponsor • Define Project Scope, Objectives • Identify Key Resources (high level)

  14. Kickoff of Data Architecture Phase • Probably the most important event in assuring the success of the project! • The Project Sponsor will be heavily involved (with the Leader of the Project) • The Project Sponsor will make clear the importance of the project to the organization • He will also make clear the level of support expected from the various levels of the organization

  15. Roles in Introducing Data Architecture • The Leader • Sponsor (from Senior Management) • The Team • Important supporting Players; Subject Matter Experts (SMEs)

  16. Data Architecture: the Key Part • Data is a valuable corporate asset, that • Must support business mission/ objectives • Strategic Alignment of Data and Information Goals • Surveys-Information Gathering • Data and Information Contexts- connecting into Business Processes and Models • See FEA Framework (next Page)

  17. Federal Enterprise Architecture Framework (FEA) • Add Graphic to illustrate key role of DRM in the FEA • Note that the FEA is Federally mandated in OMB300 funding applications

  18. The Project Charter • Identify Scope, • Identify Project Sponsor • Define Objectives • Identify Key Resources (high level)

  19. Outline: Data Architecture Sub-task • Project Initiation • Kickoff of Data Architecture Sub-task • The Project Charter: Scope, Other Things • The Project Sponsor • The Precipitating Event • Project Planning • Project Organization • Current and Target Architecture • Project Execution • Project Monitoring and Control • Project Closure

  20. Readiness-Acceptance Planning • Add graphic from document

  21. Promote Importance of Enterprise Architecture and Data • Do Data Profiling to quickly assess the impact that high quality data can have in the future (and conversely, the impact of poor quality data • Use these results to promote the role of Enterprise Architecture Plan and Roadmap to both Senior Management and Implementers of systems

  22. Why is Data Architecture Not Perceived as High Value ? • Data IS a valuable corporate asset – often not seen as such!!! • Strategic Initiatives may be dependent on high quality data, but someone must make that connection!!!!

  23. Value Proposition • Data Architecture must offer a compelling value proposition; • Many competing projects will offer a) high returns, or b) are “must do” projects for strategic reasons • Very often, Data Architecture not initially perceived to fit into either category!!!

  24. Business Services Technical Capability Matrix Technical Services Application Architecture Technology Standards Solution Sets What Are the Parts of the Information Architecture MITA Framework Business Architecture Concept of Operations Maturity Model Business Process Model Business Capability Matrix State Self-Assessment Information Architecture Technical Architecture Data Management Strategy Conceptual Information Model Logical Information Model Data Standards 2629-06—012

  25. Data Governance • DRM and Data Architecture programs should seek out ongoing Data Governance programs • Models and data definitions will be much more easily and rapidly finalized– since SMEs (Subject Matter Experts) will already be identified, with responsibilities assigned, etc. • If a program is not in place, the functions normally performed will need to be performed, and may be more difficult, than if supported in an ongoing program

  26. The Precipitating Event • There will often be a Precipitating Event that will force the move to DRM (and Data Architecture) • Data (and DRM) has not historically been a area for which funds were easily justified, when related to other priorities • Precipitating Events are usually high profile, such that a major change of direction from senior management occurs, and there are then few issues with funding the project or getting the “right” people assigned.

  27. Precipitating Events:Examples • If your agency has data-related issues that result in: • Embarrassing questions asked in Congress • An article on page one of the Washington Post • Inability of government-sponsored financial institution to produce timely financial statements • These examples are all from real life!

  28. The Project Sponsor • Not the day-to day leader of the project • An executive level manager, who is “at the table” and is willing and able to support the project when difficulties arise (and they will . . .) • The Project Sponsor must be someone who “gets it”, as to the importance of the DRM program (and Data Architecture) to the organization

  29. Project Planning • Confirm Scope and Objectives and Readiness • Review Prior Work • Establish Project Organization • Tailor Project Approach • Develop and Document Project Plan • Establish Project Infrastructure • Plan Project Team

  30. Project Execution (1) • Establish Project Infrastructure • (Tools/ Team/ Support) • Orient and Train Project Team • Understand Current Architecture and Creating a Portfolio Analysis • Review Architecture Source Materials • Obtain Tools • Metadata Management/ Modeling • Metadata capture from existing data, using capture tools • Obtain Orientation/Training for new Tools • Document Current Business Architecture and Linkage to Data Models and Data Services

  31. Project Execution (2) • Document Current Projects- What are their Data Approaches? • Create Portfolio Analysis: Data Portfolio of Data Models and Data Services • Develop Target Data Architecture • Support for New Business Strategies • New Business Rules • Define Data Requirements • Use Tools to extract existing Data and Metadata • Use Data Governance (access to SMEs)

  32. Conceptual Information Model Logical Information Model XML Schemas Data, Business Processes, and Capability Levels Message Message Message Message Message Business Process C Message Business Process B Message Message Message Message Shared data Shared data Shared data Shared data Business Process D Message Message Business Process E Business Process A Message Message Messages (Triggers and Results) + Shared Data = Information Models (Conceptual and Logical)

  33. Data and Business Processes Message Message Business Process C Message Business Process B Message Message Shared data Shared data Business Process D L4 Business Process Message Business Process E Business Process A Message

  34. Logical Model Is the Serializable Object Model, Vocabulary, Data Types, and Interactions that Comprise the Service Definition Payload LogicalInformation Model Object Model Supported Interactions Vocabulary and Code Sets Data Types

  35. LIM Development Process • LIM based on the MITA CIM, a subset of early adopter data models and HL7’s Reference Information Model (RIM) • Validate the harmonized LIM against the business process requirements • Distribute the draft LIM to early adopters for review • Update the model with comments • Submit the model for second review to early adopters and then to all States • Submit the updated model to MITA for adoption as the standard MITA LIM

  36. The CIM Is Comprised of a “Static” Concept Model and a “Dynamic” Activity Diagram Conceptual Information Model Static Concept Model Formalized Business Process Model Dynamic Activity Diagram

  37. Business Process Business Process Capabilities Level 1 Level 2 Level 3 Level 4 Level 5 Level 1 Level 2 Level 3 Level 4 Level 5 Business Process Model Formal Business Process Model Business Process Static Concept Model Business Process Dynamic Activity Model Business Process Object Model Business Process Vocabulary Business Process Data Types

  38. Data and Information Reference Model (DRM) • Add graphic from document on the DRM

  39. BP-1 Enroll Provider Level 1 Level 1 Level 1 Level 1 Level 2 Level 2 Level 2 Level 2 Level 3 Level 3 Level 3 Level 3 Level 4 Level 4 Level 4 Level 4 Level 5 Level 5 Level 5 Level 5 Level 1 Level 1 Level 1 Level 1 Level 2 Level 2 Level 2 Level 2 Level 3 Level 3 Level 3 Level 3 Level 4 Level 4 Level 4 Level 4 Level 5 Level 5 Level 5 Level 5 Detail of the MITA Information Model BP-2 BP-78 BP-79 Business Process Model Conceptual Information Model Logical Information Model

  40. Define Security and Privacy (S&P) Requirements and their Data Alignment • Design Security Architecture • Include Requirements for • Authorization • Authentication • Review to ensure Requirements support organization, without being too costly or complex.

  41. Define Security and Privacy (S&P) Requirements • Add graphic from document

  42. Develop Enterprise Transition Strategy • Develop Legacy Transformation Strategy • Define Sequencing Plan • Develop Estimates • Allocate Systems and Interfaces to Releases • Allocate Systems and Interfaces to Projects • Coordinate With Budgeting Process • Define Intermediate Release Architectures • Package Enterprise Transition Strategy (ETS) for Review

  43. Project Monitoring and Controlling • Monitoring based on Project Plan • Reporting Schedule for Sponsor, and important Committees • Escalation procedures for project Issues

  44. Package Target EA for Review • Provide a series of milestone reviews • Review with Sponsor • Review with other Stakeholders • Review Target Enterprise Architecture

  45. Review of Target Common Services / Infrastructure Strategy • Review for Compatibility with SRM, components under development within e-government projects: e-grants, e-benefits, e-authentication, etc.

  46. Review with Service Component Reference Model (SRM) • The SRM Identifies and classifies horizontal and vertical IT service components that support Federal agencies. SRM will aid in recommending service capabilities to support the reuse of business components and services across the Federal Government.

  47. Service Component Reference Model (SRM) • Add graphic from document

  48. Project Closure • Assessment of Project Objectives, Goals Reached • Lessons Learned: Difficulties Encountered • Suggestions for Next Project Phase; • Based on additional important Subject Areas significant to the organization

  49. Data Sharing Query Points and Exchange Packages Data Description Data Context Taxonomies (Categories) Data Elements FEA DRM Concepts How do I exchange the data? What does the data mean? How do I find the data?

  50. Data Element Data Object Data Property Data Representation FEA DRM Structure Data Context How do I find the data? The broad categories of data that support business processes of a line of business or community of interest. Business Context Subject Area The sub-categories of data used for mapping data groupings of many lines of business or communities of interest. Information Class How do I exchange the data? Data Sharing Information that is generated or required by a Unit of Work and is subsequently passed to another Unit of Work. Units of Work consume and produce data. Information Exchange & Query Points What does the data mean? Data Description Data Representation The organized description of data to convey semantic understanding usually through an entity relationship diagram. Structured Semi-structured Data that has characteristics of both structured and unstructured data, such as an e-mail. Unstructured Data that is of more free-form format, such as multimedia files, images, sound files, or unstructured text. Based on FEA DRM Version 1.0 and 2.0

More Related