How should project teams use the Enterprise Data Model?

How should project teams use the Enterprise Data Model?

There is a team of data architects that have been working on a logical enterprise data model (EDM) for three months, and the EDM is estimated to be 40% complete. Many projects are underway that can benefit from the EDM, yet the architects are divided as to how project teams should use the EDM. Some prefer Approach A while some prefer Approach B.

In Approach A, the project modeler meets with the EDM architect and together they decide on the subset of the EDM that is relevant for the project. Then the project modeler uses this subset as a starting point for their logical data model (LDM) and extends this model to meet the project requirements. The architect then reviews this project LDM and reconciles it back to the EDM. Once the architect approves the project LDM, the physical data model (PDM) could then be built.

In Approach B, the project modeler meets with the EDM architect and together they extend the EDM to contain the project requirements, and then the project data modeler uses this EDM subset as the starting point for the project PDM.

Which is the better approach and why?


  1. Greg 7 years ago

    I like option B as the EDM gets modified before it is used in a physical and the project does not have to create their own LDM. In option A what happens if there are reconciliation issues back to the EDM from the project LDM. If you have multiple projects going on you could end up with many items to reconcile that may have been handled differently from project to project.

    The downside of B is having enough architect(s) bandwidth to extend the EDM with multiple projects going on.

  2. Fakrudin Jivanjee (FJ) 7 years ago

    I guess depending on the scope of the project and the size of the team, it may be resource intensive to include the EDM on every project and this could leave the larger EDM tasks to start falling back and eventually could cost the quality to the organisation.

    Assuming the project modeler is equally able to to design fitting PDM and LDMs, this would make the EDM more of a consulting member for the deployed PDM.

  3. Stephen Ford 7 years ago

    The best answer depends upon whether the systems are deployed in a dispersed or centralised fashion.

    If the systems are generally implemented on their own system-specific autonomous platforms, that may not even use consistent technology then Approach A will probably be the only way to go.

    On the other hand if you have a single centralised platform that hosts many projects/sub-systems then Approach B is preferable.

  4. tanja 7 years ago

    I would go for approach A. You don’t know yet if the project will be a succes and to amend the EDM for just one project is not a viable option. Of course you can file the project model and implement it in the EDM if the project is a success and if other parts of the company will gain from the knowledge gained in the project. I also think you should praise the project modeller for taking the time and effort to consult with the EDM architect, so he or she will do this again with the next project.

  5. Tom Bilcze 7 years ago

    I am a proponent of approach A. The complexities of most enterprises make working solely in the enterprise model on a logical model difficult. There are bound to be multiple efforts running concurrently. Logical models are built incrementally as project requirements are uncovered and become firmer. As noted, the EDM is 40% complete, that means it is also not cast in stone but is undergoing growth and change. This all clashes in model development efforts with some objects well defined and others still shaky.

    Using EDM objects in a project logical model allows the project a space to develop the project model free of clashes and missteps with not-so-ready model objects. The challenge here becomes the sync back to the EDM. There is an added cost when another model comes is created. It is difficult to sync, often gets little support or attention, and is constrained by a limited data architect staff. If you can overcome the problems with syncing in your enterprise, things are golden.

  6. Pete Stiglich 7 years ago

    Approach A typically works best in my experience – as the project LDM often has objects which aren’t enterprise in nature and are specific only to the project or department. Also, speed of modeling is impacted as modeling everything in the ELDM would require a lot of effort as there are many relationships which need to be added or changed and possibly entity naming changes that would need to take place in order to extend the enterprise model – and the time to review all of these changes with Data Stewards in a Data Governance program would be prohibitive. The enterprise data model is the foundation for enterprise information systems and so should not be changed lightly. In my opinion, a conceptual data model should be the starting point – for either the enterprise or project LDM’s in order to describe the business and help ensure alignment of downstream data models to the business.

  7. Ron Warden 7 years ago

    It all depends! If the EDM has all of the entities that the project need and the analysis for the project show that there are no new entities, then approach B works; however, if the answer to the questions are no, then approach A is the only way to proceed. Given that the EDM is only 40% complete it is likely that projects will be using approach A for a while.

    Even if the EDM is thought to be 100% complete, the review of what entities are required for a project needs to start with what is in the EDM and if the project team finds there are new entities the team has to revert to approach A. The most compelling reason revolves around keeping the “EDM” valid and it should be treated as a living document.

  8. Susan Earley 7 years ago

    I think Approach A is best. Working in a subset copy of the Enterprise LDM gives the project team the flexibility to adjust to changes in understanding and design during the project. Once the project LDM is complete, it can be merged back into the Enterprise LDM. Approach B is more risky due to multiple projects/people tinkering with it concurrently. With Approach A, you can version the Enterprise LDM and issue Releases based on a planned schedule, working with development teams that may need to merge Enterprise LDM changes from projects going live before they do.

  9. Author
    Steve Hoberman 7 years ago

    Most of us would prefer Approach A. I wonder if the scales would be more tilted towards approach B, if in this scenario the EDM architect has a flexible and efficient (agile?) process to work with project teams to ensure there are no bottlenecks using the EDM. I also wonder if we would all choose Approach A if we were guaranteed both a standard process and easy-to-use tool that can manage the linkages between the different project LDMs and the enterprise LDM.

  10. Madani BASHA 7 years ago

    My vote is for approach-A. Increasingly, packages dominate the enterprise, esp. in non-software-vendor organisations.
    In such organisations, the derivation of EDM is itself a great challenge and a rather expensive labour-of-love effort.
    EDM-s tend to evolve over a long period of time.

    A project focused LDM can evolve more rapidly and the EDM would stand to benefit from taking-in the evolution in the individual LDM-s progressively.

    Yes, an effective tool and process/es to discern the differences between the LDM-that-is- yet-to-be-merged-into-EDM and the EDM is essential.
    The Enterprise Data Architect responsible for the EDM can then assess and take appropriate step to update the EDM – as well as initiate re-adjustments to the LDM-s (with the aim of aligning the EDM and all the LDM-s).

  11. Thiyagarajan 6 years ago

    Interesting observations…I did not see this post until recently. My views…
    Although I have used Approach A widely and is very prevalent, recently I had the good fortune of using Approach B for one of the large State Govt initiatives. My experience….A is clear, simple and easy when you have focused/departmental initiatives that roll up to the enterprise (kind of Kimball?), but, I found B to be very easy as well.
    In my case there were disparate systems across the state for each department (ex: Transportation has multiple SOR in different regions attributed to different rules). So, when ‘State-level Enterprise Analysis/Reporting’ needs to be done, I found approach B to be very useful. We used the LDM in an AGILE mode to spin off several SOA services based on the LDM. There is no “physical-ization” of data. All SORs map to a single LDM (the EDM) and services are spun off.
    By adding the right h/w and storage resources we implemented it successfully.

  12. Rotimi Ademola 6 years ago

    I would normally go with approach A because an enterprise data architect might not have enough bandwidth to support multiple project lines at such a detail level. If we have to harvest a project PDM off an EDM, then the enterprise data architecture becomes the project data modeler by default. The standardization and guidelines that an EDM provides can be more easily propagated and enforced if the Project LDM is synchronized first with EDM and then each project decides how best to physicalize their PDM – based on their performance needs, database platforms, etc. They will know their deployment environment best and that might be different from similar projects.

  13. Bob Zoltok 6 years ago

    Option A, as I believe it gives the project team a reason to meet with the EDM team. That reason is it gives the project team a “head-start”, a preliminary model (conceptual?) that helps them hit the ground running with a preliminary framework that meets their needs. It also gives them a head-start on the vocabulary, class words, entity names, etc., that maybe just maybe can be introduced to the project team’s client (i.e. the business) and see if they will buy those possibly abstract terms.
    Option B appears to suggest changing the EDM, based on the project LDM. In my experience, the project team has no motivation to do this for a variety of reasons, number one being it could slow down their project timetable (they really don’t care that much about the EDM). Number 1A reason is that changing the EDM to align to every project’s view of data is a never-ending losing proposition. Number 1AA reason is the EDM modellers often resist changing the EDM to match the project LDM. Number 1AAA reason is the EDM has its own schedule and shouldn’t be subject to all the projects out there that will impact their delivery schedule, priorities, etc.

    I will add that I believe the EDM should not have any attribution (PKs if you insist). As long as the project LDMs support (somehow) the relationship structures implied by the LDM, good to go.

  14. James Lee 2 years ago

    I realize I’m very late to this conversation, but just recently got back into the modeling world. I, too, prefer A as it allows the project teams to move quickly. They get a headstart from the EDM and can then move forward from there. One caution though is if you have multiple project teams that are impacting the same subject-areas, you could end up with conflicts in how things are modeled or names, which could cause problems when reconciling back to the EDM. Thus the enterprise architect needs to stay engaged with the project teams to help resolve this issues.

Leave a reply

Your email address will not be published. Required fields are marked *