Four guidelines for enterprise conceptual data model (ECDM) entity selection

1. The entity must have enterprise applicability (obviously) -- the entity and its relationships should represent how the enterprise views its business from a "data" perspective (really more of a business object perspective -- a data source for a conceptual entity does not need to exist).

The entity is representative of not just one business unit in the enterprise -- unless that business unit is the sole unit responsible for that portion of the business. If two or more business units are performing roughly the same tasks (e.g. order processing, product management) the modeler needs to work with representatives of all business units to determine standard, enterprise entities and their relationships. A data governance and stewardship organization is the ideal channel to address determination of enterprise data entities and relationships.

2. The entity MUST represent a business object/thing/concept. The enterprise conceptual data model -- also know as a business information model (BIM) -- is a business model, so if an entity represents a purely logical entity (e.g. logical entity representing an associative entity for resolving conceptual M:M relationships) or a technical entity (e.g. a database table which resulted from vertical partitioning for performance) in a source system, they should not be included. Some conceptual relationships might need to be "reified"* as a conceptual entity in the ECDM if that relationship is of key concern to the business, or will better express business rules via more detailed entity relationships. For example, if you are doing CRM, you probably will have a reified entity called "Household". A household is typically determined based on the relationship between Customer and Address, usually where you have multiple customers with the same last name at the same address. Instead of documenting the business rule in the relationship between Customer and Address, a conceptual entity called "Household" should be created.

3. If a business concept is mentioned or emphasized in your interviews with the business, it probably will need to be included in the enterprise conceptual data model. However, be sure to differentiate between "data" and process (most business people are process-oriented). ECDM's need to be developed in a top-down/bottom-up manner. Interviews are part of the top-down analysis process, whereas data profiling of existing data sources -- to VALIDATE the findings of top-down analysis -- is part of the bottom-up analysis process.

4. The entity should fall within the scope of the modeling effort -- you don't want to try to boil the ocean and represent every possible entity and relationship in one fell swoop. A common way of developing the initial pass at an enterprise conceptual data model is in conjunction with some enterprise level endeavor: For example, the institution of a data warehouse, ERP, SOA, MDM, etc. Enterprise level undertakings (ECDM included) work best when taking an iterative approach.

However, to support these enterprise applications it is very valuable to develop the "big" picture (enterprise conceptual data model) of the ENTIRE (or the majority) of the enterprise before going down the path of application design and development in order to minimize application rework downstream. (NOTE: I am not saying the entire ECDM needs to be fleshed out to the same degree of completeness).

One client wanted to start developing an EDW program and so tasked me with developing the enterprise conceptual data model before design and development of the EDW. I developed the enterprise conceptual data model to represent a broad spectrum of the enterprise (17 subject areas -- each with at least one separate model) – but I went into more detail in the ECDM for the areas that were going to be in the initial iteration of the EDW. This client had an excellent data governance organization which reviewed (in detail) and approved the ECDM. The value of developing the broad spectrum first (again -- don't want to boil the ocean but you do want at least a high-level representation of most subject areas) is that you can design flexibility into your enterprise applications for better integration with future phases of the enterprise app. However, don't let someone sell you that they would be able to introduce new subject areas into the enterprise application without some degree of rework (the goal is to minimize rework -- but it is not 100% attainable due to all the complexity involved in developing enterprise systems). Modeling each subject area in the ECDM to a high level of detail will again help minimize rework – but the reality is that development usually can't hold off until all the subject areas are fully fleshed out.

There are two schools of thought about what to include in the ECDM. One is that there should be only one conceptual data model in the entire enterprise -- the enterprise conceptual data model. The other school of thought is that there can be an ECDM and also project level CDMs, which are very detailed and might not necessarily be of interest to the larger enterprise. I favor the latter, though if what is being modeled is of interest to the enterprise, describes core business practices or impacts more than one business unit, I would place these entities in the enterprise conceptual data model.

Please let me know (PStiglich@EWSolutions.com) if you have other guidelines that you use for determining which entities to include in a conceptual data model (enterprise or otherwise).

* To regard or treat (an abstraction) as if it had concrete or material existence." The American Heritage Dictionary of the English Language, Fourth Edition. Houghton Mifflin Company, 2006.

More about enterprise conceptual data models