Challenges for Data Architecture in a Package Environment Dawn Michels May 4, 2004 May 2-6, Los Angeles/Century City, California, USA
Topics Show continued value of data analysis Discuss whether IDE is a possible solution Understand the data layer of software packages Integrate corporate data models while working with disparate packages. Discuss who should be involved in the data modeling work Control "run-away" programming Define deliverables that add value with package implementations
The Value of Data Architecture – in an IAE Why do we data model? Why do we define a data architecture? To be sure that we fully understand the business needs behind what we are planning to do. To assist in the evaluation of whether a particular application can support the business needs. To begin to prepare to map the business need to the data available through the application(s).
IDE a Solution? IDE – Integrated Data Environment IDE – Integrated Development Environment IDE – Integrated Drive Electronics IDE – Integrated Digital Environment
IDE – A solution - possibly Integrated Data Environment Data Model(s) of all needed Data Architectural Diagrams of impacted systems (Target and Source) Business Process Diagrams Knowledge of systems of record Awareness and Projections for future analysis. Message Brokering
Which Data Architect Tools to use? Conceptual Models – Set Scope Logical Models – More detailed representation of the business data needs, without regard to implementation, technology and organizational structure. Physical Models – is the specific mapping of what is implemented. Data Dictionaries/Mappings to the Applications – for knowledge.
Business rules need to be developed to define: Who creates what data? Where is data stored and maintained? Who has access to what data? Who can update, revise, or delete data? Under what conditions or events is data accessed?
Understanding the data layer of software packages Some vendors willing to share their models Reverse Engineer Attend Presentations Try out Demos Look for inconsistencies Abstractions
Integrating Corporate /Enterprise Models The Enterprise Model is the primary data design tool for strategic planning, communicating information requirements throughout the organization. Whenever possible locate any corporate models or standards you have on key subject areas. Understand Main Subject Areas Evaluate the fit of the application to the subject area
Data modeling roles? Business Analyst – usually SME – Subject Matter Expert – knows business rules Data Architect / Data Modeler – understands all aspects of Data and able to produce artifacts to communicate with. Application Architect – understands the applications inside and out. Technical /System Architect – over- arching architect who understands the technical infrastructure required for the full environment. Others?
Control Run Away Programming – How? Force development to be around the business need and the data defined. Continue to participate and keep design up-to-date with what actually gets developed Use design as concepts for the adaptations that the applications require Lay out requirements, so that no development is done that doesn’t tie to a requirement.
In Conclusion Define in advance deliverables that add value Have clear understanding on the set of architectural deliverables, and who holds what roles around getting them. Understand the data layer of the applications When applicable map data and applications to corporate models Help maintain a sense of control around programming.
Questions? Ideas! Dawn Michels
Thanks for your time and Patience! Dawn Michels Sr. Data Architect Past Pres DAMA MN Past VP Chapter Services DAMA-I Adjunct Faculty Member College of St. Catherine Passionate data Architect
Additional Deeper Reading Functional%20Process%20Integration%20and%20the%20IDE.pdf Functional%20Process%20Integration%20and%20the%20IDE.pdf nte.pdf nte.pdf DAMA INTL & Local DAMA Chapters Awesome Directory of Data & Info Mgmt Resources The Data Administration Newsletter Enterprise Warehouse Solutions