Your SlideShare is downloading. ×
Enterprise Data Maps
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Enterprise Data Maps

268
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
268
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Three Year IT Management and Budget Plan Enterprise Data Maps 07.21.2006
  • 2. Agenda
    • Clarify 3 Year Plan Instructions
    • Enterprise Data Maps Discussion
    • Open Discussion
  • 3. Clarify 3 Year Plan Instructions
  • 4. 3 Year Plan Clarification
    • Technology Assets -> Database
      • Production databases only
      • Mainframe and server based databases
      • Databases that are integrated into third party software probably should not be counted
      • Non-relational databases really do not have “tables” but use that area to list the number of non-relational databases that exist
  • 5. 3 Year Plan Clarification
    • Business Contingency Planning / IT Disaster Recovery
      • Hot button issue for ITAB and Executive CITO
      • The split was made to see the level of disaster planning that is occurring
      • These two plans can exist in one document
      • Simple “Yes” or “No” question, but feel free to add any additional information that helps to crystallize your agency’s disaster planning
  • 6. Any Other Questions?
  • 7. Enterprise Data Maps
  • 8. Overview
    • Part of the Enterprise Architecture models added to the Three Year Plan last year
    • Still and optional section in this year’s Three Year Plan
    • There is no timeline for this to be included, but would be a good idea to start looking at it sooner rather than later
  • 9. What is an Enterprise Data Map?
    • Graphical, condensed, high level representation of your agencies data
    • This could be shown in a number of ways
      • Conceptual Data Model
        • Non-technical, as seen by a business person
      • Logical Data Model
        • How business data objects would be implemented in an Information system, how the database designer would see it
      • Physical Data Model
        • How the logical data would be organized, how the database developer would see it
  • 10. What are we asking for?
    • Somewhere between the conceptual and logical model
      • We want conceptual information organized logically.
      • Want a list of subject areas, i.e. Customer, Product, Employee.
      • The logical part is that we would like to see some of the high level groupings, interactions, and relationships.
  • 11. Why an Enterprise Data Map?
    • A model that will allow the state to understand the data that exists
    • A model that will help develop common data standards
    • A model that will help data interoperability
    • A model that will allow for a discussion on data to take place
  • 12. Why? (continued)
    • High Level understanding of what data you are collecting as an agency
    • Find redundant and inefficient data exchanges
    • Find possible collaboration points or additional data exchanges
  • 13. Background: Federal Data Reference Model
    • The FEA Data Reference Model (DRM) is intended to promote the common identification, use, and appropriate sharing of data/information across the federal government through its standardization of data in the following three areas:
      • Data Context – A standard approach to representing taxonomies that an agency uses to categorize its data. Such categorization enables the business context of data to be well understood.
      • Data Sharing – A standard approach to describing the characteristics and requirements of interagency data exchanges, including data sources. Defines a standard message structure known as an Information Exchange Package.
      • Data Description – A standard approach to describing an agency’s structured, semistructured, and unstructured data. Structured data includes individual entities (such as those defined within a data architecture), their attributes, and the relationships between them. Unstructured data includes multimedia files, and documents created using earlier versions of applications such as Microsoft Word. Semi-structured data includes Web pages and e-mails.
  • 14. Our Approach vs. Federal Approach
    • We are not mandating anything.
    • Our approach is to give you complete flexibility in context, sharing, and description
    • In time we may look at standardization (and it will probably not be mandatory), but that is years down the road
      • Unless there are some interested parties and then we will be happy to start helping you develop strategies for this
  • 15. Example #1 – Too much information
  • 16.  
  • 17. Example #2 – Correct Level of Information
  • 18.  
  • 19. How to complete an Enterprise Data Map?
    • I am not a DBA / Application developer by trade, so my knowledge on this is limited
    • But remember we are looking for high level information
      • Customer Information rather than First Name, Last Name, Address, Billing information, ect
      • Critical information
      • Column level data
  • 20. How? (continued)
    • I would start by trying to compile all your agencies data by system
      • Could also look at stand alone databases
    • Then with that data look for any natural groupings that exist for naming consistency
    • Aggregating this master set of information will be critical to get this effort in the proper scope
    • Then begin to find any linkages between the different data sets
    • Finally plot all those pieces
  • 21. Issues
    • This is a large undertaking
      • We know this. We think it is an important undertaking for Kansas. That is why we are talking about it now and not making it required.
    • Trying to drill down to deeply in your data.
      • Having too much information will be a detriment to fitting this on a single page
      • Remember KDOT took 50+ databases, 4000+ tables, and 100000+ rows and fit the summary on a page.
  • 22. Level of Detail
    • Provide what ever level of detail you can realistically complete in the given time.
    • We would rather see a partial data map than no data map
      • Submit it to us as a “draft” and we will not publish it
  • 23. Final Reminder
    • Three year plans are due September 1 st .
  • 24. Questions?
  • 25. Open Discussion
  • 26. Contact Information
    • Bill Roth, CITA, 785-296-2108
      • [email_address]
    • Bryan Dreiling, 785-296-2809
      • [email_address]
    • http://da.ks.gov/kito/ITMBP-07.htm