The client where I work has a set of analysts, a majority subset of whom are used to looking at a software application as “database-driven,” meaning they need to see the database table schema in order to understand the flow of the application. They’re technical enough that they can use the “language” of a database’s table diagram, its glyphs, to understand the business logic that it represents. They’re familiar with a database’s Entity-Relationship Diagram (Database ERD). They consider themselves masters of creating a database ERD and using that to communicate to a DBA what sort of database to create and to give that to a .NET developer to tell what to build around.
With Microsoft Dynamics CRM, as with other Enterprise-class software applications and many ORM-driven applications, the underlying database schema isn’t the “language” the business is written in – that underlying table schema is the representation of the CRM framework’s data store. The CRM Database ERD doesn’t contain only the business’s logic but also CRM’s. If CRM’s power is enabling business processes, then when these types of analysts look at a reverse-engineered database ERD of CRM’s organization database for insight, they come away bewildered, not understanding how such a different schema could even manage to encapsulate their business, or worse, irritated that it’s so difficult to read the database table ERD and can’t see how CRM would make application development any faster than if they just created a custom ASP.NET application.
One of the major issues they have is with a classic CRM Design Pattern – the Denormalized Attribute Pattern. This pattern provides one way of solving the need to display information on an entity from one or many related entities – copying them to the main entity in question. From a database ERD standpoint, it appears that there’s duplication of information, a major red flag from a database design perspective. Even when not using this design pattern, looking directly at a CRM database with its two tables per entity on custom entities and its attributes for related “foreign keys” for N:1 and N:N relationships tend to confuse analysts who aren’t familiar with the CRM framework.
What’s the solution to satisfy an analyst who feels like they’ve lost their primary means of communicating business data storage and logic via a db ERD? A better “language” or glyph system would be UML, a notational representation of an object model, or a more abstract (actual) Entity-Relationship Diagram.
In some following posts, I’ll describe communicating business and technical analysis via UML and a custom CRM ERD language and how it relates a traditional database ERD, particularly one reverse-engineered from a CRM organization.