Enterprise Architecture – Parts of a Data Architecture
The data architecture program within an Enterprise Architecture initiative will include many documents about the data processes within your organization. To begin this exercise you must determine what applications are in scope to explore and document. Beginning with the physical database schema for the applications included create a physical data model. This should be the easiest to obtain giving today’s relational database tools. Once completed you need to determine what are the subject areas within the application and what tables exist to support the data for the subject area. Examples of subject areas are Customer, Product, or Employees. Within all applications there are critical data elements that are key to each organizations decision making. These must be identified and documented as to there level of data quality. One method I use to determine the range of valid values in each table I use an open source program such as R and have it explore the data. This is the easiest method I have found to see what is actually stored in each table. This will also enable you to see how dirty your data is in each table and work with business owners to clean up those fields that are critical and should be part of a Data Quality Program. Finally you need to document what data flows into this application and what data this application sends to other applications.
Listed below are the areas to include within the scope of the Data Architecture program. If you are just beginning your Enterprise Architecture documentation then I suggest starting with one application and building out a document for each item below on a limited set of tables such as 5 to 8. This will give you enough data to work with to understand what needs to be captured.
- Physical Data Model
- Logical Data Models
- Subject Areas
- Business Entities
- Valid Values
- Data Quality Rules
- Data Flow
I hope this helps you get your data architecture program started.