From a business analysis perspective, a logical data model should be a very important tool in developing and defining requirements and in communication of those requirements. It concisely scopes the business domain.

logical data model

Nothing has really changed fundamentally over the last few decades in the steps that must be worked through in working out what is required and how we build business systems (other than different methodologies over time with their own take on it and own naming conventions for essentially the same thing…but that is another story), and any set of requirements and resulting system must have a foundation in data and implement a set of functions and business rules that act on that data.  It is fundamental, and even more so in a Dynamics CRM project.

In a business system, generally (and there are some exceptions) all functions operate on data, whether it is retrieving the data, creating the data, or updating the data.

I have seen a trend in past years where the data model is not being used as much in requirements definition, and I believe that this has potential to lose a lot of benefits. I have even been told recently by an architect (not one in my organisation, thankfully) that I should not include a logical data model, and I should leave that to the technical people! I ignored his advice.

The requirements can be written in many ways depending on your methodology of choice, e.g. a Function List with Requirement Descriptions, a Use Case List with Use Case Descriptions, a Feature List with User Stories. They all have the same intention and all end up with the same result…defined requirements.

However, without a defined data model as part of these requirements, and only relying on essentially lists of functions/features and associated text, it can sometimes make it difficult for a business analyst to crystalise and verify the data requirements, and for architects and developers to understand the underlying data structures without making assumptions that may sometimes be incorrect. The architects and developers won’t have the breadth of understanding of the business domain that a business analyst will because the architects and developers have not necessarily been involved in the requirements exercise. Their view of the world will be limited to the Feature List Stories in the iteration they are dealing with only.

Sure, we could use text to describe the data requirements, but in the age of everyone assuming that Agile is the answer to all things and that less documentation is better, then the data model is surely a great tool in conveying the data structure. It is not volumes of text in detailed documentation, but it conveys so much at the same time.


In my experience, I have found many benefits in constructing a logical data model as part of the requirements exercise. For example:

  • Business Entity identification
    • All objects discussed and identified as part of the requirements exercise where data is to be stored, retrieved, and modified.
    • This provides the domain of the business or system and allows much instinctive deduction of the functionality to expect.
  • Relationships between business entities
    • How a business entity relates to another, e.g. an Owning relationship, or a Reference relationship
  • Optionality and Cardinality
    • Definition of whether a relationship from one business entity is to another owning or referring business entity is required or not
    • Definition of whether a business entity can have none, one, or more related business entities
  • Requirements Validation
    • Building a data model helps a business analyst to cross check and verify potential missed requirements. If you have a function/feature that does not have a business entity defined in the data model, then you potentially have a missed business entity or you could have an unnecessary feature. Conversely, if you have a business entity that does not have a function/feature that operates on it, then you may have a missing feature that was not discussed.
  • Scope
    • It helps to provide scope in discussions with the client. If a new business entity is identified during construction, then it is an easier discussion if you can point to the data model and show that it was not part of the existing agreed domain scope.  This will certainly help project managers.
  • Input into Acceptance Criteria
    • Regardless of how the architect implements the physical data model, it must still adhere to the logical data model. For example, if it does not pass the relationship, or optionality, or cardinality rules when entering data, or if it doesn’t allow for more than one related data record, then it fails the acceptance criteria.
  • Reduces re-factoring between Construction Iterations
    • The process of an architect working through a set of text in the requirements (say User Stories) and constructing a data model may lead to a misunderstanding of the data rules. In addition, if the architect is only referring to a subset of the features as part of say iteration 1, they do not have the full data scope and the decision to design the data structure a certain way may then need to be refactored or changed in a subsequent iteration, causing more work and time overruns.
  • Intuitively natural for Dynamics CRM
    • The Dynamics CRM platform has its foundation in Business Entities. A logical Data Model is a natural fit into a Dynamics CRM solution.



The logical data model provides many benefits, and it is an important tool for a business analyst or consultant to articulate and conceptualise the distinct data from functional components of requirements, validate requirements, minimise construction refactoring, and help define the business domain scope.

I use them all the time as they allow me to define and decompose the two distinct elements of a business system……data and function. Not sure about you, but once I understand the data domain of a process or system, I essentially can instinctively deduce up to 70% or more of the type of functionality that the system will likely have.