What's my new world made up of?

The MS-CRM world is made up of nearly one hundred entities. The original, v1 database design had one goal - to be readable by IT folks. There were several designs prior to the current version that were far more complex to read, but far more extensible in theory. We pulled the plug on the complex model during v1's first milestone and we threw away nearly all of the code that worked against that model. I have mixed feelings about that decision though. The model had the potential to be extremely flexible in terms of semantics. But, the implementation was lacking. Customizations required opening a UML model, tweaking it, and regenerating everything. That's never a good plan. What we ended up with - the metadata model - is a far better solution to the customization story. But, the underlying schema is a problem.

If I were going to start over and create the CRM "schema" again, I'd take a completely different approach. Essentially I'd throw away the requirement that the database be readable by mere mortals (that's sarcasm by the way) and instead focus on four things:

Principals

Collaborations

Exchanges

Collateral

That doesn't mean the database would only have 4 tables, but that's a close approximation to the number we'd need to describe quite a bit of the CRM world (it's my belief that we can describe even more worlds than CRM with the same model, but I don't want to talk about what I don't know… yet).

If we had those four concepts along with their powertypes (concepts which describe concepts), we'd have eight "tables". Now, the most important thing in the data model is the relationships between the concepts. I'd argue that the most important thing about CRM, and other business applications, are the processes. We'll get to that later. If we took a very simple approach and created an M:M relationship between each of the concepts we'd end up with an additional six tables, for a grand total of fourteen. That's a far cry from the CRM database that ships today. We might take the extensibility one step further by creating powertypes for each of the M:M relationships which would increase the size of the model by six additional tables.

On top of those fourteen tables we could create dozens of database views that merged powertypes and concepts to expose higher-level concepts that are more familiar to CRM users: customers, orders, support incidents, phone calls, KB articles.

So, what are these four core concepts and how might they work? Principals capture the parties known to the world, the roles those parties play, and the relationships in which those roles are played. Collaborations are the long-running interactions between principals. Exchanges are the short-running interactions that move a collaboration through its states. Collateral is all the semi-static information that's used by parties during both short- and long-running interactions.

Let's look at a few examples. A party is the most fundamental concept within the principals. It's a static item representing a person, company, or even a piece of software. When two parties connect they do so in various roles where the connection is a relationship. For example, we might have Contoso Ltd. and Jonny Jones as two parties. We can connect these parties in various ways that are interesting to each party. Jonny might be a customer of Contoso and an employee at the same time. Customer and employer (notice how roles are asymmetrical) are roles that the parties play with respect to each other.

One example of a collaboration might be a support incident. In this case the long-running nature of the collaboration comes into play because there are typically many exchanges that occur to move the incident along. In this case the parties might email each other, fax documentation, or telephone each other. A support representative might involve an engineer or sales representative by creating additional collaborations or via simple exchanges.

Solving the incident might require delivery of different information such as a knowledge base article or technical note. If the incident requires purchase of additional services (another collaboration) then sales literature or a contract template might required.

So, these are the things in my new world. Watch this space for ways that these concepts pop up in software and services that we deliver.