Information Management Newsletters, May 2, 2011
Karen Lopez, Kamille Nixon
Models and their underlying metadata should be seen as corporate assets to be managed by a partnership of modelers and the business. If they are portrayed as just technical specifications that can be understood by developers and database administrators, they will not provide the benefits of an enterprise data architecture
Today’s IT professionals face varied challenges, including legislation, organizational change and fast technological innovation.
New methods, tools and techniques can overwhelm many IT professionals whose organizations are initiating enterprise data modeling programs. Enterprise data modeling uses logical and physical data models to encourage a practical balance between enterprise and project points of view. This type of data modeling comprises both application and enterprise data models, enables IT groups to respond quickly and effectively to business needs, delivers information that is the most useful to the business, and uses the proper tools and techniques in delivering project outcomes.
Eager to deliver a well-managed enterprise architecture, IT professionals sometimes still have concerns about possible missteps along the way. In fact, seven common mistakes that organizations can make in developing enterprise data models each have a cost that negatively impacts individual projects, and the information technology group as a whole.
Mistake 1: Forgetting that an enterprise architecture is a living framework
Some IT professionals think of data architecture as a final, fixed deliverable instead of a versioned view of the business. Many project plans arrive with a start and end date for the data modeling effort, where the logical model ends on a Thursday and the physical model starts (and can be completed) on Friday, with no tasks or resources assigned for refinements. This sort of finish-to-start mentality can lead to the
perception of incomplete tasks and projects – and unmet business needs – as refinements are a natural and expected part of any modeling effort. This type of pitfall is almost guaranteed if non-data management professionals develop project plans in isolation.
If team members do not understand that data models, like other project deliverables, can be versioned, shared and reused, they are likely to misunderstand the role of models during a project’s lifecycle. Every phase of a project can lead to refining previous decisions, understandings and changes due to external influences.
Any team member should be able to trace a business concept from the logical model to the physical model to the physical implementation of that concept. This traceability is a key to realizing the benefits of an enterprise data management program.
Mistake 2: Keeping data models invisible
An invisible model might as well not exist; the same goes for an invisible data modeler. If a data management effort is going to deliver business value, it must be accessible, understandable and shareable. Models need to be available in an easily searchable manner, including definitions. A model without definitions is just a diagram that could be interpreted in many ways, so it is important to supply the entire model with definitions and appropriate metadata.
It makes sense that the more available models are, the more likely they will be used by a wide variety of IT and business professionals. Implementing things like an enterprise data dictionary can ensure data definitions are consistently used and understood across an enterprise.
(No Ratings Yet)