Ladda ner presentationen
Presentation laddar. Vänta.
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
12
Vad finns i paketet ? Informationsmodell Domänmodell
Implementationsobjekt (.xsd, .dtd, .xdr) Best practice
14
Vad finns i paketet ? Informationsmodell Domänmodell
Implementationsobjekt (.xsd, .dtd, .xdr) Best practice
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, ,
Liknande presentationer
© 2024 SlidePlayer.se Inc.
All rights reserved.