Multiple Canonical Models: Databases or Messages?

Martin Fowler urges the data people and messaging people to talk, but not to define a single model.

This makes sense whether you are talking about enterprise databases or enterprise messages. I would add two points. The final one, if you want to cut to the chase, is addressed pretty well by Cutter's Doug Barry.

The first is that although enterprise models are not easily "big designed upfront" there are proven techniques for supporting their emergence. The best I know of comes from Ralph Kimball, who I've written about before in the context of enterprise integration.

The other point I would add is that Martin is really addressing at least two significant issues. In addition to the perils of enterprise modeling, he's made an implicit point about messaging and databases. I'm not going to put words in his mouth but he could have pointed to his peers efforts to illustrate what he means by enterprise messaging.

I am not sold on the idea of general messaging. There are special cases where a high performance message product makes sense, e.g. broadcasting large volumes of financial information on a trading floor is the motivating example.

In the general case, messaging is just too much like a crippled database that assumes the consumer is not the provider. You end up with an additional product and all the associated costs. I think there is a lot of room for improving 80 percent of the cases a relational database is applied to, but not at the expense of an entirely new and yet severely limited product like messaging. (Hint: every messaging product has some kind of simple persistence mechanism you can't get to in a general way. Why?)

I would choose either low cost databases for Martin's integration scenarios, or, more ideally, a simple XML-based tuple space-like database. Either approach can be used in a myriad ways without assuming the consumer is not also the provider.

Doug Barry kind of addresses this issue in a Cutter report. He is a fellow traveller from the Object Oriented Database market. A full OODB is overkill. So is a full relational database, but at least they are commodity and not so esoteric.

This second point is we need simpler database products rather than messaging products.