“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 heb ik bij LeasePlan het concept van het canonical datamodel 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.
De minimale benadering heeft te maken met het feit dat in een landschap van los gekoppelde services, de services zélf het merendeel van “data” (ik spreek liever van persistentie) managen. Zij zijn er zelf voor verantwoordelijk. Alleen de data die aangeleverd moet worden door de vragende service, zodat een ontvangende service zijn werk goed kan doen (en hier wordt data informatie: het heeft betekenis in de context van een service interactie) behoeft centrale management.
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.
Ik kan niets uit eigen ervaring vertellen over CDM i.c.m. microservices. Het probleem met CDM zoals zoveel goede ideeën is dat het zo lang als silver bullet werd verkocht (vaak letterlijk “verkocht”). Zodoende wordt het een doel an sich. En dat leidt o.a. tot een CDM met allerlei data definities die alleen met een specifieke integratie te maken hebben en helemaal niet herbruikbaar zijn.
Een CDM-light zou nuttig (en misschien essentieel) kunnen zijn. Dat kunnen we langzaam opbouwen op basis van de behoeftes van concrete situaties. Microservices biedt een redelijk kans om hier een succes van te maken. En als we het een informatie model i.p.v. een data model zouden noemen is er de kans dat we beter nadenken over wat nu daadwerkelijk daarin hoort te staan.
Groet!