mayo clinic's information architecture: a meta-data repository implementation copyright, 2000...
TRANSCRIPT
Mayo Clinic's Information Architecture: A Meta-data
Repository Implementation
Copyright, 2000 © Mayo Foundation
April 19, 2000Minnesota DAMA Chapter
Sonja Ziegler - Data AdministratorMayo Foundation, Rochester, Minnesota USA
Background
• Began the search for a comprehensive data model repository in 1995
• Purchased Rochade in 1996• Training and familiarization throughout
1996• Established steering committee in late 1996• Throughout 1996-1998 a variety of projects
were undertaken to address varying needs
Lessons Learned
• Identification of a specific business need that requires attention is crucial
• The scope of the implementation efforts must be tightly controlled
• An appropriately staffed repository team is needed for implementation and coordination
• A committed user/proponent must be engaged in the project
The Vision
Information Architecture• Data Architecture
Documentation of all pertinent information about an organization’s data and its interactions
• System ArchitectureThe documentation of applications areas and their relations to business areas,
information systems, vendors and IT personnel
• Business RulesThe documentation of business related knowledge that defines the rules of
behavior to support the business’ operating procedures using business vernacular
• Impact AnalysisThe ability of developers to gauge the impact that a change to some
architectural element will have upon its surrounding elements
The Scope
• The Mayo Data Architecture - our first step to a complete Information Architecture and we had a committed user base!
• A top-down approach was not feasible because of current company culture
• With a diverse multi-platform environment, just documenting what’s there is a vast improvement
• Recognizing the difference between the efforts that can be automated by the repository and those that can’t
The Data Architecture Project
• The Team• The RIMs (Repository Information Models)• The User Interface• The Infrastructure Components• Mayo’s Problem Space
– Summarization– The Data– Population– Our Goal
The TeamThe Team
• One FTE for Database and System Administration
• One FTE (at least) for Application Development
Plus a group of individuals to act as users.
- FTE (full time employee)
• One FTE for Project Coordination/Management
Mayo Data Conceptual Level RIM
DA/Subject-Area
DA/AbbreviationDA/Attribute-
CategoryDA/Synonym
DA/EntityDA/RelationshipDA/Prefer-
RepresentationDA/Attribute
DA/Entity-MAP Rule
DA/Relationship-MAP-Rule
DA/Attribute-MAP-Rule
Mayo Data Logical Level RIM
XREF/EntityXREF/Relationship XREF/Attribute
XREF/Data-Structure
XREF/Reference XREF/FieldXREF/Data-
Schema
XREF/Data-Model
DA/Entity-MAP Rule
DA/Relationship-MAP-Rule
DA/Attribute-
MAP-Rule
DA/Subject-Area
DA/EntityDA/Relationship DA/Attribute
PWRDES /EntityPWRDES /
Relationship
PWRDES/CDM-Model
PWRDES /Attribute
Mayo Data Physical Level RIM
SYB/ColumnSYB/TableSYB/Database NSSQL/Table NSSQL/Column
XREF/EntityXREF/Relationship XREF/Attribute
XREF/Data-Structure
XREF/Reference XREF/FieldXREF/Data-
Schema
XREF/Data-Model
PWRDES /EntityPWRDES /
Relationship
PWRDES/CDM-Model
PWRDES /Attribute
Mayo Application RIM
DA/Subject-Area
DA/EntityDA/Relationship DA/Attribute
DA/Entity-MAP Rule
DA/Relationship-MAP-Rule
DA/Attribute-
MAP-Rule
XREF/EntityXREF/Relationship XREF/Attribute
XREF/Data-Structure
XREF/Reference XREF/Field
XREF/Data-Schema
XREF/Data-Model
Appl/Attribute-MAP-Rule
Appl/CRUD-MAP-Rule
Appl/Application
Appl/Message
Appl/Interface
DA/Interface-Attribute
The User Interface & Infrastructure Components
USER INTERFACE• VIASOFT™ AutoPilot• MDX-Manager
BUSES AND SCANNERS FROM VIASOFT™
• Sybase™ Catalogs• PowerDesigner™ Models• DB2® Catalogs• COOL:Gen™• MVS JCL• COBOL Programs• COBOL Data Libraries• Assembler ProgramsDEVELOPED SCANNERS• Enscribe• FOCUS®
• NonStop™ SQLCSV IMPORT UTILITY• Microsoft® Access Data
Rochade™
Data Importation
MAINTENANCE• Application• Data Architecture• Cross Reference
Maintenance
METAQUEST™ QUERY/REPORTING MODULES• Easy (EZ)• Dual Display (DD)• Extended (EX)• Power (PW)
• Administration Tool
Query & Reporting
Problem Summarization
• Mayo has chosen to follow a philosophy of selecting many best-of-breed applications and then interfacing between them.
• Their relative data models were not designed from an overriding Enterprise Architecture (a bottom-up approach).
• As a result, we have data concepts represented differently and named in many different ways throughout our information architecture.
ISSUES: • the need to understand our diverse data concepts• the need to integrate our applications
The Data
• MICS (Mayo Integrated Clinical Systems) Data Architecture Project undertaken by Data Administration in cooperation with the application development teams
• The Data Architecture Model (DAM), the Application Logical Models (ALMs), and the database catalog information
Population of the Repository
• Real work here, no silver bullets
• Data entry by summer student personnel
• Commitment from management for project• Identified personnel from Data
Administration and development projects• Ongoing processes established to maintain
integrity of repository contents
Mayo’s Goal
To have information at hand that will facilitate the understanding needed for:• creating efficient application interfaces
• effectively designing new databases
• redesigning existing databases.
Now & Our Future
• Continued commitment from Data Administration to populate the Data Architecture
• Benefits are already being seen, which turns into good advertising for further IS involvement
• Prioritize and keep the scope under control of the varying requests for implementations of the repository (Mayo Rochade Steering Committee)
Contact Information
Sonja Ziegler - [email protected]
Mayo Foundation
200 1st Street SW – Massey Studio
Rochester, MN 55905