Why You Should Avoid a Canonical Data Model

“As an enterprise architect, you might be tempted to strive for a
canonical data model for your systems’ interfaces. That’s not a good idea.”

Source: www.innoq.com (STEFAN TILKOV March 24, 2015)

In mijn werk als lead enterprise architect bij LeasePlan heb ik het concept geïntroduceerd, met name om verwarring rondom de betekenis van concepten te verminderen. De kunst is, zoals Stefan in dit artikel ook zegt, een minimale benadering te gebruiken. Het compleet definiëren van de complete structuur van alle data die in de communicatie tussen alle services heen en weer gaat is inderdaad een anti-pattern.

Het artikel is alleszins een all-out de grond inboren van het concept maar geeft veeleer aan dat voor je het weet het er insluipt dat je teveel centraal gaat definiëren. Stefan geeft ook aan dat (wanneer je een CDM wilt gebruiken) er een aantal randvoorwaarden zijn om dat succesvol te doen.

Een aspect dat Stefan niet noemt is de relatie tussen de (potentiële) omvang van een CDM en het ontwerp van de services. Mijn voorkeur voor micro-services in combinatie met een sterk business-centrische benadering (de services zijn business services, en de technische services zijn extreem versimpeld) leidt tot een interessante constatering dat deze ontwerpstrategie als neveneffect heeft dat de hoeveelheid data die over de lijn gaat ook extreem kleiner wordt. Er ontstaan enkele “aggregatie” services die misschien data vanuit verschillende services concateneren, maar er is weinig of geen incentive om deze data in zijn totaal te canonicaliseren, omdat de context van de verschillende datagebieden niet overlapt.

Conclusie: goed service-ontwerp leidt tot minder data om centraal te managen. Is dit een stelling waarmee men het eens kan zijn? Ik ben benieuwd wat de ervaringen zijn van CDM in combinatie met microservices.

Home » Development » Microservices? Hahaha, dat ga jij nóóit doen! – CIO.nl

Microservices gaan overwaaien, want het past niet bij hoe tegenwoordige organisaties werken.

Source: cio.nl

Een wat chargerende titel die de lading van het artikel niet helemaal dekt. De schrijver is namelijk helemaal geen tegenstander van het principe, misschien zelfs integendeel. Hij signaleert alleen heel terecht dat het invoeren van deze architectuurstijl niet alleen maar beperkt kan blijven tot een technische architectuurkeuze.

De Wet van Conway is belangrijker dan ooit, namelijk de noodzaak de organisatie zodanig ingericht te hebben dat het af te beelden is op de architectuurstijlen (zowel aan business als techniek zijde!) waarvoor gekozen wordt. Ik noem dit ook wel “fractale architectuur”: de structuur herhaalt zich op verschillende aggregatieniveaus.

Het is niet voor niets dat ik ook “slecht nieuws” heb voor organisaties die voor SOA hebben gekozen, maar niet een interne structuur (een dienstgerichte indeling) hebben die hiermee resoneert: jullie zullen ook  die interne structuur aan moeten passen, met een governance proces dat hierop afgestemd is.

Door dit af te stemmen op kantel initiatieven die in heel veel organisaties al speelt, kunnen soms meerdere vliegen in één klap worden geslagen!