Kanoniska meddelandeformat - hjälp eller stjälp ?

Kanoniskameddelandeformat- hjälpellerstjälp ? OAGIS, ARTS ellernåtannat - Vilkaärnyttornaochvilkaärsvårigheterna Johan Tuvstedt, Dynabyte AB

Grundproblemet • Meddelandebaserad integration med fler än två parter ger snabbt upphov till kombinatorisk expolosion • En lösning är att centrera på gemensamma grundläggande (kanoniska) dataformat och modeller

Kanonisk = ja vaddå, helgon eller ?? • Canonical; Basic, canonic, canonical: reduced to the simplest and most significant form possible without loss of generality. • Grundläggande, vilket på svenska är ett oböjligt adjektiv, närmaste översättning; ”mest grundläggande”

Parametrar att ta hänsyn till • Förväntad nytta • Verktygsstöd • Kompetens • Plattformsspecifika modeller • Branschstandard • Uthållighet • Teknisk höjd / Komplexitet • Acceptans / Support

Standardiserad integration • Genom EA • Genom få verktyg • Gemensam informationsmodell • Genom kanoniska meddelandeformat • Ger förutsägbarhet

Parallella processer i organisationer • Kvalitetscertifieringar • För att få förutsägbarhet i processer • Budget, ekonomisk uppföljning och balanserade styrkort • För att få förutsägbarhet och uppföljning rörande kostnader, nyttor och verksamhet.

Hur passar delarna ihop ?- Vad behöver man • Informationsmodell • Dataarkitekturmodell • Implementationsobjekt • Vilka sorters information och hur hänger dessa ihop • Vad blir den slutliga modellen när alla strategiska system lagts till informationsmodellen • Användbara utökningsbara meddelandescheman

Hur passar delarna ihop ?- Vad behöver man, forts • Arbetsmetod • Arbetsteam som utvecklar och underhåller • CM Resurs • Repository

Några meddelandemodeller • EDIFACT • ARTS (retail) • OAGIS • TMForum – SID (telecom) • GS1-eCom (retail) • Oracle AIA Foundation Pack

Vad finns i paketet ? • Informationsmodell • Domänmodell • Implementationsobjekt (.xsd, .dtd, .xdr) • Best practice

Vad saknas ? • Hur passar tänket i: • Informationsmodellen • Dataarkitekturmodellen • Alla datafält som du behöver som saknas • Underhållsmodell och metod

Tågordningen, teoretisk... • Affärsobjekt definieras utifrån verksamhetens process • Informationsmodellen avspeglas i affärsobjektet • Systemsambandet implementeras med hjälp av den kanoniska modellens implementationsobjekt (meddelandeschema) • Affärsobjektet cementeras i sin ögonblicksform i systemen…

Konsekvenser av standardnyttjande Krav på affärsobjekten annat än standardens Informationsmodellen inte enheltlig med standardens • Implementationsobjektet (grundform) utökas enligt någon metod

Konsekvenser av tiden / verksamheten / återanvändning Krav på affärsobjekten ändras Informationsmodellen utvecklas • Implementationsobjektet ändras • Flera versioner av samma objekt finns • CM / repository / releasekrav

Vad är komplext, svårt och dyrt att underhålla • Vad är taggad version och vad är deployat • Vad händer när standarden ändras • Vem vet varför och hur senaste utökningen gjordes • Träd med många döda grenar ger dålig återanvändbarhet • System som nyttjar formatet direkt snarare än via integrationskomponent blir dyra att ändra

Do’s and don’ts Nyttja standardobjekt men: • Abstrahera standarddelen från utökningen så standarddelen kan bytas ut /ändras • Använd standardtaggarna som de var tänkta, knöla inte in ett pris i en antalstagg..

Do’s and don’ts, forts. • Låt inte systemen normera objekten, process och informationsmodell består • Använd verktyg som är bra på att skapa implementationsobjekten göra det, inte de gamla systemen som är bra på flatfil etc.

Diskussion och frågor

Integrationsarkitektur Teori och erfarenhet... Kontakter: Johan Tuvstedt, 0733-347907, johan.tuvstedt@dynabyte.se Affärsområde integration Magnus Brodin, 0733-347908, magnus.brodin@dynabyte.se

Kanoniska meddelandeformat - hjälp eller stjälp ?