I hear a lot of talk about canonical data models and how they will help get a more unified view of data throughout the enterprise. And then I see that what really happens is that we build bloated representations of some idealized view of the data that doesn't serve anyone well. Perhaps it isn't always like that, but we architects seem to think that they are better ideas than the poor schmucks who have to use them.
Actually, a lot of the time, we aren't building a canonical data MODEL, but defining a canonical data STRUCTURE. The difference (and yes it really matters), is that with canonical data STRUCTURES we pass around the data structure in its complete form, and require that the consumers filter the meaning from it. I used to think that was a good idea.
But then, I fell back to my modeling roots, and realized that maybe we should use the MODEL as a lens through which to view data structures. By that I mean that a Canonical Model is intensional and descriptive. It doesn't have an extension or implementation expressed as a data structure. When a (services) consumer of the data wishes to consume some data, the consumer binds to the model (some time prior to execution), and instructs the model to manifest the data in the way the service consumer needs it.
Of course this requires that the model has the ability to choose among its data sources, perform the transforms on behalf of the consumers, recognize that the contracts might change and evolve the schemata appropriately. It isn't easy.
It also turns some of the ideas of services on their heads. Instead of a one size fits all service (retrieve all the data about a reservation), we have the opportunity to have bespoke, services that give the service consumer exactly what it needs. Hmm, service proliferation, that doesn't sound good - and it isn't if you don't have proper service management disciplines. But it is probably a whole lot better than passing bloated, unnecessary giant structures around clogging up the network and annoying the consumers.
Actually, a lot of the time, we aren't building a canonical data MODEL, but defining a canonical data STRUCTURE. The difference (and yes it really matters), is that with canonical data STRUCTURES we pass around the data structure in its complete form, and require that the consumers filter the meaning from it. I used to think that was a good idea.
But then, I fell back to my modeling roots, and realized that maybe we should use the MODEL as a lens through which to view data structures. By that I mean that a Canonical Model is intensional and descriptive. It doesn't have an extension or implementation expressed as a data structure. When a (services) consumer of the data wishes to consume some data, the consumer binds to the model (some time prior to execution), and instructs the model to manifest the data in the way the service consumer needs it.
Of course this requires that the model has the ability to choose among its data sources, perform the transforms on behalf of the consumers, recognize that the contracts might change and evolve the schemata appropriately. It isn't easy.
It also turns some of the ideas of services on their heads. Instead of a one size fits all service (retrieve all the data about a reservation), we have the opportunity to have bespoke, services that give the service consumer exactly what it needs. Hmm, service proliferation, that doesn't sound good - and it isn't if you don't have proper service management disciplines. But it is probably a whole lot better than passing bloated, unnecessary giant structures around clogging up the network and annoying the consumers.
No comments:
Post a Comment