Kanoniska meddelandeformat - hjälp eller stjälp ?

En presentation över ämnet: "Kanoniska meddelandeformat - hjälp eller stjälp ?"— Presentationens avskrift:

1 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

2 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

3 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”

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

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

6 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.

7 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

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

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

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

11

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

13

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

15

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

17 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…

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

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

20 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

21 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..

22 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.

23 Diskussion och frågor

24 Integrationsarkitektur
Teori och erfarenhet... Kontakter: Johan Tuvstedt, , Affärsområde integration Magnus Brodin, ,