In de vorige blog las je hoe we met belangrijkste businessobjecten een domeinmodel opzetten voor SynTouch Integrated Data Architecture Framework (SIDAF). Door het toekennen van autonomie aan domeinen wordt de organisatie wendbaarder, de governance duidelijker en data-uitwisseling efficiënter. Nu we weten hoe de domeinen ingedeeld worden, ga ik in deze blog verder in op hoe een domein georganiseerd is.

Elk domein kenmerkt zich door negen elementen:

• Businessobjecten
• Domeinnaam
• Domeingrens
• Business-functies
• Applicaties/microservices
• Domein-team
• Taal/Jargon/begrippenkader
• Datamodel & metadata
• Datawarehouse (DDS)

Businessobjecten, domeinnaam en domeingrens

Elk domein is verantwoordelijk voor het beheer van data rond de eigen businessobjecten. Elk businessobject hoort bij exact één domein. Om daarover geen verwarring te laten ontstaan is een duidelijke domeingrens nodig: het moet immers duidelijk zijn wat er wel en wat er niet tot het domein behoort. Een goede unieke naam die ‘de lading’ dekt identificeert het domein en helpt om snel te kunnen inschatten wat het domein omvat.

Domein-team

Het domein-team is het kloppend hart van het domein. Het adopteert het agile DevOps-team concept en bouwt dit uit met aanvullende rollen en verantwoordelijkheden. Dit vormt een team dat in hoge mate autonoom kan functioneren binnen de organisatie. Deze autonomie verhoogt de wendbaarheid en tegelijkertijd het eigenaarschap rond data en IT-oplossingen.

SIDAF onderkent onderstaande vijf rollen. Elke rol kan door meerdere personen worden ingevuld en elk persoon kan meerdere rollen vervullen. Een rol kan ook part-time worden opgevuld:

DevOps team

Allereerst zijn er de typisch DevOps rollen:

• Developer: ontwerpt en creëert oplossingen
• Tester/Integrator/Deployer: test en integreert releases
• Functioneel beheerder: ondersteunt users met functionele issues
• Technisch beheerder: ondersteunt users met technische issues

Architect

Elk domein heeft een eigen domein-architect-rol. Deze rol is verantwoordelijk voor business-, applicatie-, data- en infra-architectuur binnen het domein. Vanwege dit brede pallet aan skills zullen er vaak meerdere personen deze ene rol invullen.

Specialisten-rollen rond data & integratie

• Integratie specialist: ontwerpt en realiseert integratie-oplossingen
• Data engineer: ontwerpt en realiseert data-oplossingen
• Data steward: ziet toe op datakwaliteit en het gebruik
• Data custodian: is verantwoordelijk voor het beheer van opgeslagen data

Analisten

• Domein business analist: analyseert business behoeften en requirements
• Domein data analist: analyseert data en databehoeftes binnen het domein

Managers/Eigenaar(s)

• Product owner: is verantwoordelijk voor alle business en IT-capabilities en de prioritering hiervan
• Data-eigenaar: is verantwoordelijk voor de kwaliteit en het gebruik van domeindata
• Applicatie eigenaar: is verantwoordelijk voor één of meer specifieke applicaties

Taal/jargon

Elk domein en domein-team heeft een eigen taal/jargon. Deze kan afwijken ten opzichte van de van andere domeinen. Dezelfde begrippen kunnen bij verschillende domeinen een andere betekenis hebben. Het voordeel van een eigen jargon is dat een domein intern zeer effectief en autonoom kan communiceren. Het is hierdoor niet nodig dat er een bedrijfsbrede thesaurus wordt onderhouden met alle begrippen over alle domeinen. Het nadeel is dat als domeinen informatie met elkaar willen uitwisselen, dan moet er een vertaalslag gemaakt worden.

Elk domein heeft een eigen jargon. Het lijkt allemaal op elkaar maar er zijn verschillen waarmee bij data-uitwisseling tussen domeinen rekening moet worden gehouden

Domein datamodel

Elk domein beheert data rond de eigen businessobjecten. Het domein definieert en beschrijft deze data via een domein datamodel. Dit is vergelijkbaar met het domeinmodel dat ik in mijn vorige blog beschreef, maar dan gedetailleerder en met alleen de objecten die binnen het domein een rol spelen.

Applicaties

Elk domein heeft eigen applicaties die de data rond de domein-businessobjecten beheren. Deze zorgen voor vastlegging van de data. Daarnaast ondersteunen ze transacties op de data waarbij ze de vereiste bedrijfsregels bewaken. Tot slot stellen ze waar nodig specifieke data beschikbaar via interfaces voor gebruik buiten de applicatie.

Domein interfaces

In bepaalde gevallen hebben domeinen data nodig van andere domeinen. Daarvoor biedt een domein interfaces aan waarmee andere deze data kunnen verkrijgen. SIDAF biedt drie standaard interface vormen aan:

• API
• Events
• RDS (Read-only Datastore)

Deze worden alle behandeld in volgende blogs. Als andere domeinen de data willen gebruiken, zullen ze een vertaalslag van de definities (en het jargon) van het data-producerende domein naar de data-objecten en jargon in het eigen domein moeten maken.

Domein Data Store

Zoals hierboven beschreven onder Domein-team heeft een domein eigen data analisten. Zij maken in SIDAF gebruik van een Domein Data Store (DDS). Dit is vergelijkbaar met een datawarehouse, maar dan voor lokaal (domein)gebruik. Alle relevante data voor KPI’s en analyses wordt hierin vastgelegd. Hoe de DDS wordt ingericht is aan het domein zelf, mits de architectuurrichtlijnen worden gevolgd. Ook eventuele data van andere domeinen die voor de analyses nodig is, wordt in deze DDS vastgelegd als referentiedata. Het is aan het domein om deze referentiedata actueel te houden.

Samenvattend is een domein een autonoom functionerend orgaan, dat in hoge mate onafhankelijk is ten opzichte van andere domeinen. Dat maakt domeinen daadkrachtig en wendbaar. Natuurlijk maken de domeinen onderdeel uit van één organisatie en dienen alle dezelfde hoofddoelen. Het noodzakelijke alignement tussen de verschillende domeinen bespreek ik in mijn volgende blog.