Failure to achieve the value of an enterprise information model, as the foundation for EIM, continues to frustrate those responsible for implementing EIM in many organizations.  In this article we‘ll identify some common reasons for this and present some suggestions for improving your chances of success.  To do this it will be helpful to understand what value may be expected from an enterprise model and to identify who will use it and for what purposes.  We will also describe what form the model should take, with different presentations of the model for various audiences.

For many years the data model has represented the schematic for construction of the relational database.  As DBA’s became more knowledgeable with the practice of data modeling they began to adopt it with a view to producing an application database design.  In many organizations DBA’s still perform the data modeling.  Subsequently many organizations have recognized the need for a logical data model produced during requirements definition that later gets transformed into a physical data model.  In many cases the data modeler doesn’t actually participate in the information requirements gathering sessions with the business, instead frequently relying on the business analysts to reiterate what they understand the data requirements to be.  It is very common for business analysts to have bias towards process orientation and frequently view the data as the byproduct of the process.  They usually don’t give much, if any, consideration to unambiguously defining the data requirements consistently in the context of an enterprise definition.  It is also commonplace to see data modelers organizationally align to functions or large application development initiatives.  So we may end up with different styles and standards for data modeling within the same enterprise depending on the nature of the area of study.  In extreme cases this results in the religious wars of dimensional modeling versus normalized models - further distancing the data professionals from realizing the goal of producing one model of the information needs of the enterprise. These factors present several barriers to the effective creation of an enterprise conceptual data model.

The practice of having DBAs develop the data models has in many cases created several problems.  Typically DBA’s are focused on designing and supporting high performance databases to support the needs of the users they are currently engaged with.  Although they may be trained and competent at developing third normal form data models they will invariably be focused on defining every entity, attribute, primary key, secondary key and relationship required to address the requirements.  They will also be interested in performance criteria and identifying the volumes of data, frequency of access and the access criteria to support the application.  This can lead to a mismatch in the systems development process where the project may be at a conceptual or logical phase for requirements discovery and the data modeler is focused on physical details.  This will lead towards the desire to disengage the data modeler from the process and may make it difficult to reengage them on future projects until the design phase. One of the barriers presented by the approach of having business analysts translate requirements for the data architects (modelers/data analysts) is that the business is not used to observing the evolution of the data model as they articulate their requirements.  When the business folks have direct interaction in facilitated sessions where the data architects draw the model in their presence they become familiar with the process and understand how the model represents their needs as it takes shape one entity at a time.  When they go through a business analyst they typically do not see the data model, if they see it at all, until it is well evolved and then it seems to have an overwhelming amount of information and complexity that they don’t have the inclination to read…resulting in their discounting it as a useful business tool.  They view the model as a back room technical specification which doesn’t concern them.  Once a barrier like this has been set through precedence it becomes exceedingly difficult to remove when the data architects seek direct interaction for activities such as the creation of the enterprise data model.  Frequently there is also resistance from the business analysts as they may see this as a threat to their responsibilities and may also fear damage to the relationships they have established with the business by having technical people introducing what they view as irrelevant detail oriented questions.  In some cases, as previously described, there may be validity to this concern if they have experienced only physical oriented data modeling practices.  In this interaction model it is most common for the business analysts to not engage the data modeler(s) until the detailed design or system specification phase of the Systems Development Lifecycle (SDLC) to model the data specifications for the solution design of the effort.

We have looked at some factors which create organization and cultural barriers to enterprise modeling that are fairly common practices for data modeling.  Now let’s look at some resource issues.  In the previously described scenarios data modelers are engaged to figure out very detailed data specifications in the form of a fully attributed and normalized, or star schema models, for a specific systems development initiative.  Due to the nature of this work the individuals performing it can tend to be very pedantic, thorough and concerned with adherence to detailed data standards for use of things such as classification keywords and naming conventions which is appropriate for the detailed design phase of the SDLC.   This work attracts individuals who prefer Sensing Perception (Refer to Myers-Briggs Personality Typing) which favor clear, tangible data and information that fits in well with their direct here-and-now experience. This is in stark contrast to those who prefer Intuition Perception (Refer to Myers-Briggs Personality Typing) who are drawn to information that is more abstract, conceptual, big-picture, and represents imaginative possibilities for the future.  So a major problem we have is that many organizations tend to draw upon those who have the current role as a data modeler for physical or detailed logical data models and look to them to deliver the enterprise conceptual data model.  There is a personality type mismatch between the work that is required to develop an enterprise conceptual data model and those who are most often engaged to perform the work.  When this happens they immediately look to their strength and attempt to construct the model from a bottom up versus a top down perspective.  In one Fortune 500 company that I am aware of they had been attempting to use a bottom up approach to build an enterprise model for the Vice President of Marketing.  This involved analyzing the existing third normal form data models and the database schemas and reconciling the semantic and structural differences to create the enterprise model.  They had been at it for over a year and had recently hired a data modeler just to get this done and were still nowhere close to having something they were comfortable sharing with the VP.  By pursuing a top down approach utilizing standard data model patterns and keeping the model at a high level I was able to satisfy the VP of marketing with an enterprise conceptual model in a period of three weeks.  This model subsequently became the foundation for all future data modeling efforts eventually becoming fully attributed and normalized as a result of several years of project development work which worked out the details within the scope of their initiatives.  This resulted in there being one model for all operational systems and the enterprise data warehouse (EDW).  Legacy applications were not migrated to the new model, with the exception of master data, but were mapped to it on an as needed basis such as the identification of data sources for the EDW. 

I am not aware of any industry recognized standard definition of what an enterprise data model is.  The ones I have been presented with as being enterprise data models  have varied from a one page PowerPoint, with five subject area blocks, and point to point lines between all of them, to an ERWin diagram of the SAP R3 database (with thousands of tables) reverse engineered using Saphir.  To arrive at what an enterprise data model should be, we need to understand what it can be used for and by whom.  The primary purpose of having an enterprise model is to provide the big picture of what information is required to support all the business processes of the organization. This will enable both tactical and strategic planning, architecture, impact analysis and compliance.  It should be a tool for semantic reconciliation within the enterprise and a common conceptual/logical mapping source and target for the data assets of the organization.  It should be mapped to an enterprise business function model to articulate what data is required to support the business processes.  The enterprise data model can be used to define:

• What data stewards are
• Stewards of what data 
• Who has governance authority over what data

The enterprise data model becomes an essential part of enterprise architecture and planning as it can be used to understand what data is impacted by changes to business processes and applications and what business processes and applications are impacted by data changes.  It can be used to identify what information practices and policies apply to what types of data and in turn where the actual data exists by mapping the model to existing applications and data stores.  It should also be the vehicle for defining the scope of data for systems development initiatives both in terms of what is internal to the system and the interfaces to other systems.  By utilizing the enterprise data model for these purposes it can become an invaluable tool for the prevention of data proliferation and application and data portfolio rationalization.  It is also an essential tool in pursuing enterprise master data management initiatives and identifying the authoritative sources for business intelligence and data warehousing efforts.

Based on these uses we can envision for an enterprise data model we can begin to understand who would use this tool leading to a better understanding of what it should be.  First let’s look at level of detail.  If we are using an enterprise data model as a tool to assist in enterprise architecture and strategic systems planning then the participants are likely executive IT management and should involve senior business management.  The discussions will also involve the enterprise data architects.  I think we can safely assume that business management and the CIO of any large organization are not going to be able to take the time to understand a 4,000 entity data model.  I think we can also assume that the enterprise data architect is not going to be happy with five boxes on a PowerPoint as being useful in identifying system impacts based on business changes or strategy.  Therefore we need to find a level of detail between these two extremes that enterprise architecture can get value from and that management (business and IT) will relate to.  In my experience this has been an Entity Relationship Diagram (ERD) that fits on one page and can still be legible. The page size may be up to tabloid size provided it can be projected and be read in a presentation.  The ERD should show major super entities (e.g. customer, product, supplier, order, location, process, GL account) and show key relationships between these entities.  The model should not contain more than 100 entities and ideally more like 50.  It is useful to color code these super entities by subject areas (e.g. Finance, Manufacturing, Sales and Marketing) to aid in data stewardship accountability and governance authority.  When using the model in presentations to senior management it may be more effective to present only the subject area model with the detail obscured (illegible) but using the same layout as the complete model and having the ability to reveal details as needed.  Ideally the model should be in a form that can be decomposed into a third normal form logical data model so that the scope of projects can begin at the enterprise model and then be refined through the further steps of the SDLC.  The long term goal would be to complete a third normal form model for the entire enterprise with all the entities, relationships and attributes as opportunities arise through regular system development activities.

Here are some other suggestions to greatly increase your chances of success in the creation, use and sustainment of an enterprise data model. Create a centralized data architecture group if it does not already exist.  By having a functionally aligned pool of data architects all working from the same model and set of standards it is much easier to ensure all data models are consistent with the enterprise data model and it is being leveraged to achieve value across functional and organizational boundaries.  Ensure that the data architects are assigned to tasks that match their inherent personality traits and skill levels.  Assign detail-oriented sensing individuals to the applications development phases of the SDLC.  Assign intuition-oriented individuals to enterprise level tasks such as the creation of the enterprise data model and planning and strategy activities.  Get the business used to working directly with the data architects as they define their business processes, in an interactive manner, so the models are developed within a context that the business can relate to.

I like to use the analogy of Christopher Columbus sailing in search of a passage to India to help people understand the value of an Enterprise Data Model.  If Christopher Columbus had had a World Map to track and plan his progress, he wouldn’t have mistaken the Caribbean for India.  When you only rely on line of sight navigation you can get way off track.

About The Author

Andy Field has been involved in information management activities for over thirty years in both the private and public sectors internationally and domestically. He has held senior leadership positions accountable for establishing Enterprise Information Management practices in several organizations, including a Fortune 100 company.  Andy has also consulted with clients from many industries and government sectors over the years and established and ran as president a consulting firm specializing in strategic information systems planning.  He has broad experience in both operational and data warehouse projects from both a hands on and leadership perspective. Andy is currently a Principal Consultant with EWSolutions, Inc. Andy can be reached at AField@ewsolutions.com