enterprise data maps
TRANSCRIPT
Three Year IT Management and Budget Plan
Enterprise Data Maps
07.21.2006
Agenda Clarify 3 Year Plan Instructions Enterprise Data Maps Discussion Open Discussion
Clarify 3 Year Plan Instructions
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
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
Any Other Questions?
Enterprise Data Maps
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
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
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.
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
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
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.
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
Example #1 – Too much information
Example #2 – Correct Level of Information
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
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
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.
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
Final Reminder Three year plans are due September 1st.
Questions?
Open Discussion
Contact Information Bill Roth, CITA, 785-296-2108
Bryan Dreiling, 785-296-2809 [email protected]
http://da.ks.gov/kito/ITMBP-07.htm