1. 4

  2. 3

    I don’t really get this. Creating a canonical data model of anything implies getting everyone involved on the same boat language-wise. Just look at chemistry and biology.

    Saying that it’s not a good idea to build an understanding between people using the same terms is a complete resignation on the belief that people can actually, in time, understand each other. If we can’t, why bother doing anything?

    On the other side, yes, you have to start building such an understanding by having people actually talk to each other and then codify the stuff for the newcomers. Much like we do in the linguistics. It wouldn’t make sense to try to push an English 2.0 by force.

    1. 2

      Most importantly, don’t push your model from a central team downwards or outwards to the individual teams. Instead, it should be the teams who decide to “pull” them into their own context when they believe they provide value. […] It should be your goal to establish a minimal set of rules that allows people to work as independently as possible.

      Those remarks in the closing paragraphs remind me of a passage in Painless Functional Specs. There, Joel Spolsky writes:

      Don’t have coders report to the program manager. This is a subtle mistake. […] At the height of development for Excel 5.0, I estimated that every morning, 250 people came to work and basically worked off of that huge spec I wrote. […] The weird thing was that I was at the “bottom” of the reporting tree. That’s right. NOBODY reported to me. If I wanted people to do something, I had to convince them that it was the right thing to do. […] Some of them would have thought that it’s inappropriate to second-guess a superior. Other times, I would have just put my foot down and ordered them to do it my way, out of conceit or nearsightedness. As it was, I had no choice but to build consensus. This form of decision making was the best way to get the right thing done.

      1. 1

        A canonical data model is one of those concepts that’s great in theory but, in my experience, difficult to achieve in an enterprise context (quite often you’ll end up with a domain model that people call canonical). As the author highlights, it’s also deeply mired in those early 2000s buzzwords that now make people shudder - SOA, EAI, ESB, etc.

        As with microservices (love ’em or hate ’em) being the more pragmatic replacement for SOA, I think going the “microformats” route (as the author suggests) is probably a good idea. Much more flexible and definitely the more pragmatic approach.