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.
Be the first to comment on this post using the section below.