Kanoniska meddelandeformat - hjälp eller stjälp ? OAGIS, ARTS eller nåt annat - Vilka är nyttorna och vilka är svå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 finns i paketet ? Informationsmodell Domänmodell Implementationsobjekt (.xsd, .dtd, .xdr) Best practice

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