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. Social media-based features are also emerging in data modeling to encourage more sharing and collaboration.

Mistake 3: Assuming that business users can’t understand or review models

This pitfall typically happens when a project team has a history of poor preparation for model walkthroughs. Business users will resist reviewing models if they do not have the proper training, or if presenters have unclear and inconsistent methods for presenting the models.

Most business users can understand and review models if they are given proper training, if they are guided through a structured review process and if they have regular access to the models. It can become commonplace for users to insist that data models be used, and they tend to insist on these models due to training they have received so that they understand the importance of data models. One or two days of user-targeted training can expose these valuable team members to the issues a modeler faces in creating and maintaining a model, as well as the goals and benefits of an enterprise approach to modeling.

It is important for business users to be able to access and digest data models so they can make informed business process decisions, yet they typically do not have access to a data modeling tool. This is why it is key to give them data model viewing and reporting capabilities. When setting this up, a best practice is to restrict access to read-only to prevent people from inadvertently making changes.

Every data modeler should remember that business users who see models regularly are more likely to support the allocation of resources to future efforts.

Mistake 4: Thinking that data models are only about databases

Both logical and physical data models can support more than databases. Logical models, with their technology independence, organize data requirements in a manner that no text-based document alone could do. Physical models allow team members to see how business concepts are implemented without having to provide access to production systems.

Data models are not just a means to building a database. They can be used by a team performing package evaluations. They can be used to develop requests for proposals and evaluation criteria. They can even be used as training materials for new staff or as references for ad hoc queries.

Data models should be made available to team members who are developing related models, such as UML Class Models, XML schemas and other interface products. Allowing team members to import and export metadata contributes to a model-driven design environment and establishes integration of model metadata with other platforms.  

Mistake 5: Throwing models “over the wall”

Some IT professionals see data models as deliverables that are completed early in the project and then handed off to others to decide how and when they use the models.

This approach is almost always guaranteed to cause a breakdown in communication between the business needs and what is implemented. A modeler should be involved in how the requirements are captured as well as how they are implemented. She should understand where they are implemented, and what changes, if any, have been made due to technical constraints or performance requirements. A data modeler is the mediator between business requirements and physical implementations.

A “throwing over the wall” approach will lessen the value of data models, as round-trip modeling is almost always going to be a manual process that is prone to errors and will slow down the benefits inherent in enterprise data management. Synchronized models and databases and denormalization mapping are features that help with avoiding this mistake.

Mistake 6: Forgetting about the sizzle

Since one of the main benefits of effective enterprise data management is better communication, presentations of models must be clear and understandable. Model diagrams should include guides so the nonmodeler can follow the intent and meaning of modeling objects. They should be easy to read and well commented. Models should be interesting, and the successful data modeler must never underestimate the value of sizzle. By simply “jazzing up” models with color and by diagramming objects, it not only customizes the models for an enterprise, but it also makes the user review process more engaging and enjoyable.

Mistake 7: Thinking of them as “your” models

Finally, the most critical mistake that can be made is treating data models as if the modeler personally owns them. The models should be presented as belonging to the business and tended to by the modelers. That means sharing them openly, providing access to those who want it, keeping extra printouts available, offering training on how to read them and making every effort to make them clear and understandable.

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 only by developers and database administrators, they will not provide the benefits of an enterprise data architecture.

Avoid the Mistakes

Enterprise data management promotes better data integration and project coordination while reducing project risks. Enhanced communication and increased confidence in the IT organization are crucial to meeting business needs, especially those imposed by external sources. Reduced cost and faster response to change are natural products of taking an enterprise approach to data management.

Risk is a natural part of all projects. Organizations that understand potential risks are better positioned to avoid them. Recognizing and avoiding these seven mistakes will go a long way toward reducing risks and maximizing the success of every enterprise data modeling effort.