I've just finished working for a client which has burnt millions on a project to come up with the 'one true domain model' for their business. This was the project's sole deliverable.
What are your thoughts on this? Is a single version of the truth realistic?
The key word here is "model". Any domain model is an abstraction of the key entities and behaviour in the model of a system.
As an example, a traffic management system might have an entity Car, which is indivisible. A driving simulation will have much more structure: components, weight, colour, occupants and so forth.
The point here is that there is no global definition of Car. There is only state and behaviour that you care about for your particular application (or even a part of an application).
No, it's not realistic. Yes, it's a fallacy ;-)
In my opinion, it's the well-known trade-off between re-usability and maintainability. If there is one most important aspect of maintainability, I would say it is: minimizing dependencies. The 'one true domain model' for the whole business obviously creates a lot of dependencies, no matter how clever it is engineered.
I would go for better maintainability.
Hmm, domain model. Modeling is a an abstraction technique in which we create representation of real objects, which will abstract from (omit) unnecessary details (so usually we have to specify important aspects beforehand). Domain is a certain area of business. The problem is, that there might be different views on the domain even in one organization and different viewpoints, so it is hard to define important aspects and therefore model. The issue which is even worse, is that tis domain and those viewpoints change in time and therefore model might change in time - this is important when we talk about business agility. I personally think, that domain models, especially when they need to be used for certain purpose, are too fluent. It is imho better to capture the current state and view of/on domain for given purpose at demand.
One thing that doesn't help is that you don't specify the modelling language.
You probably mean a data model: relational, ER, UML classes, or something like it. Possibly not. In any case, let's hope the language used is clear enough for there to be at least a consensus on what sort of information is supposed to be in the model and how it should be represented. Drawing boxes and lines with various types of shapes and decorations without a clear meaning won't give you good models.
That being said my vote is for markus's answer: the more information you include, the more you have to drag along. Besides, what information you need and how best to model it depends on what you need it the information for, how easily and reliably you can obtain and store the information, possibly on access control considerations (can everybody see everything?) and umpteen other considerations. Without knowing these requirements and how they may change in the future, there is no such thing as a good model, let alone a perfect one. Except that there are of course intrinsic quality considerations - e.g. redundant representation of information is usually a bad idea unless you have a specific requirement that makes it attractive.
This doesn't mean modelling or reconsidering existing models is a waste of time: on the contrary, often you only become aware of existing requirements or design limitations once you try to design a model and consider its implications. And it's good to strive for consistent representation, to make everything fit within a possible single universal model of everything. But that certainly isn't the goal of modelling.
Perhaps the business needed to think long and hard about what information they have, where they need it, who maintains it, how, and how all this can be improved. In that case I suppose setting the goal of designing a single big, consistent and complete universal information model can be a good way to achieve that. But that model probably won't be the main outcome.