En spade er en spade er en skovl

Datakvalitet er netop en udfordring – men også en mulighed i relation til SOA.

Som du skriver er det ikke bare formen – i form af protokoller og standarder – men også indholdet, som man skal interessere sig for.

I den forbindelse er SOA med til at skærpe kravene til definition og konsolidering af data. Men samtidig giver SOA også nogle nye muligheder for at løse disse udfordringer. Dette kan fx ske ved at have nogle centrale eller måske ligefrem eksterne regler og hjælpedata, som er tilgængelige for hele ’forretningen’ i alle processer. Dette kan understøttes ganske godt af SOA tankegangen og de underliggende teknologier.

Det er godgørende at se en gammel sandhed bryde frem til overfladen igen - integrationer handler ikke kun om den tekniske betydning og syntaks, men i lige så høj grad om den forretningsmæssige betydning. Dette synspunkt har jeg først som løsningsarkitekt og siden som enterprise architect fremført for mange organisationer siden midten af 90'erne. De tager som regel godt imod synspunktet, men kun på skrømt - det er vel noget IT-drengene ordner - ikke?

Nixen - det er først og fremmest forretningens opgave og ansvar. Jeg har netop været med til at skrive en kogebog i intergration mellem ESDH-systemer og fagsystemer baseret på et pilotprojekt. Over 65% af ressourcer og kræfter skal inversteres i at afklare begreber og betydninger mellem de involverede parter i en læreproces før man tager fat på den tekniske integration.

Dette skal organisationerne involveret i integrationer erkende og være parat til at sætte kræfterne af til. Ellers for intergrationerne ikke nær den forretningsmæssige effekt, som de kan have.

Det er glædeligt at ønsket om forandringsparate værktøjer og arbejdsgange på tværs i det offentlige igen sætter dette på dagsordenen via SOAs popularitet og nødvendig som IT-arkitektur stil. Og det udtiller igen-igen at uden forretningsarkitektur i form af processer og begreber/information ingen SOA, der dur

Det kan vel kort opsummeres med disciplinen
"Domain Driven Design" ;-)

Eric Evans har skrevet en ny-klassiker om emnet

http://www.domaindrivendesign.org/books/index.html

@Niels, jeg er helt enig: Begreber skal bare være afklarede og ensrettede (eller deres forskellige betydninger fastlagt og beskrevne og også gerne versionerede) før man kan bruge services.

Det er en bekræftelse af ideen om "hvis du ikke kan få det til at fungere på papir, så kan du heller ikke elektronisk"

OIOXML initiativet fra IT&ST skulle være det offentliges garant for en vis kvalitet af veldefinerede begreber. Og det har masser af gode elementer i sig som kan hjælpe med at fastlægge begreber. Men her beskrives kun interfacet, ikke semantikken og alt for meget skrammel har sluppet igennem nåleøjet.

Fx. skal et CPR-nummer være på 10 cifre med et avanceret regulært udtryk til at tjekke formatet ... eller 10 nuller efter hinanden som bruges ”hvor personnummeret er påkrævet men ukendt” (det står der!). Og CPR-nummer strukturen bor i kernen af OIO, dvs. et element der SKAL genbruges. Så hvad gør man så, hvis man vil kræve et rigtigt CPR-nummer i et interface?

Se selv: http://rep.oio.dk/cpr.dk/xml/schemas/core/2005/03/18/CPR_PersonCivilRegi...

@Peter – ja, udfordringer er der nok af, men i jo heldige hos Kommunedata, at i sådan kan rende rundt og kræve CPR-numre af alle og enhver. Andre dødelige er nødt til at identificere folk som fx: ’Grigoriy Sostakovic, Oehlenschlægersgade 577, et sted i København’.

@Henrik, Nu er det vores kunder, der kan kræve CPR-numre af alle og enhver, ikke os. Og firmaet hedder KMD nu, ikke Kommunedata :-)

(jeg udtaler mig forresten aldrig herinde på vegne af KMD - jeg taler altid kun for mig selv)

Du peger på et andet vigtigt krav til en succesfuld SOA end fælles begreber, nemlig det at kunne identificere et objekt på tværs af systemer uden der er enighed om primærnøglen eller at den ikke må bruges som i CPR-nummerets tilfælde. Nogle af RKIs webservices afspejler problemet med at identificere en person når nu CPR-nummeret ikke må bruges – der skal bruges diverse underlige kombinationer af andre data, fx. fødselsdato, postnummer og vejnavn eller noget i den dur.

Og hvis et objekt ikke engang kan identificeres entydigt inden for et system, så er der tale om alvorlige datakvalitetsproblemer som i dit teleselskabs-eksempel i en anden kommentar ( http://www.version2.dk/artikel/6202#p12388 ). I en SOA bliver den slags kun værre.

@Peter – fuld respekt mht KMD og det at blogge for sig selv.

Her i landet sætter vi den personlige integritet højt – dette hensyn overgås kun af hensynet til skattevæsenet – så derfor er anvendelse af CPR-numre forbeholdt det offentlige og finanssektoren. Alle andre må bruge andre metoder til at opnå en unik identificering af privatpersoner.

Når det gælder firmaer, er der jo fri anvendelse af CVR. Men her driller det mange, at firmaregistrering ikke er lige så entydig som personregistrering.

Alt i alt er registrering af stamdata – på engelsk Master Data Management – en stor udfordring for mange. Som tidligere nævnt skærper SOA denne udfordring – men giver også nye muligheder.