En gemensam datamodell kräver avtalad betydelse

En gemensam datamodell ger en användbar grund för en integration när de deltagande teamen förstår dess data på samma sätt. Beslutet börjar därför med uppgifternas betydelse. Ett gemensamt fältnamn löser inte ensamt en verksamhetsmässig motsägelse.

Ett fält, två olika betydelser

I ett fiktivt företag har både CRM och ERP ett fält active. I CRM betyder det att säljavdelningen för närvarande arbetar med kontakten. I ERP betyder det att kunden får lägga order. Båda systemen kan underhålla sitt värde korrekt och ändå ge olika resultat.

Om projektet pressade in båda uppgifterna i ett gemensamt aktivfält skulle en försäljningsändring oavsiktligt kunna påverka beställningsbehörigheten. I exemplet överförs därför två separata uppgifter. Vilket system som får ändra respektive uppgift bestäms separat.

Ett schema genomför den avtalade betydelsen

JSON Schema beskriver struktur och begränsningar för JSON-data. En validator kan kontrollera om ett meddelande följer det avtalade schemat. De ansvariga måste avgöra om kontakthantering och beställningsbehörighet ska betyda samma sak. Den tekniska kontrollen kan återge de regler som därefter avtalas.

Utbytet behöver också ange betydelsen av ett saknat värde och hanteringen av motstridiga ändringar. Utan den överenskommelsen skulle samma tomma uppgift kunna ge ”okänt”, ”radera” eller ”ingen ändring”, beroende på mottagare. Dessa möjligheter måste väljas medvetet.

Använd gemensamma definitioner där de hjälper

För två stabila anslutningar kan en begriplig fältbeskrivning räcka. En företagsövergripande modell är värd den extra strukturen när flera deltagare faktiskt behöver samma betydelse. Olika lokala begrepp kan finnas kvar så länge översättningen är entydig.

Vi rekommenderar att pröva en modell med motstridiga exempeldata från de deltagande systemen. Om teamen kan bestämma samma målbetydelse för en konkret post går det att omsätta det beslutet i ett tekniskt schema.

Källor

• JSON Schema: What is JSON Schema?