Meddelandeflödesvy

Syfte

Integrationer handlar månt och mycket om att förstå och svara upp mot informationsbehov i olika processer. Att visuellt åskådliggöra detta gentemot olika målgrupper under ett förvaltningsobjekts livscykel är dock en utmaning och kräver att man ser helheten samtidigt som man kan diskutera detaljer.
Idén till modellen kan kopplas till behovet av att visualisera de process <-> information och system <-> informationsmatriser.
Styrkan med modellen är främst dess enkelhet

Användningsområde

Främsta användningsområdet är att få olika intressenter inom verksamhet och IT att kommunicera kring en gemensam bild och med den som utgångspunkt:

  • Ha en övergripande bild över integrationsarbetet och hur de olika delarna ”hänger ihop”. Framförallt viktigt i ett startskede när man behöver skapa sig en gemensam bild och kommunicera med sin omgivning. Allt eftersom bilden växer fram och blir mer detaljerad så får den betydelse i utvecklings-, test- och förvaltningsarbetet.
  • Göra gemensamma prioriteringar och förstå/ resonera kring konsekvenser ur ett process, system och informationsperspektiv.
  • Relatera till annan, mer detaljerad, dokumentation så som lösningsdesign och mappningar.

Stegbeskrivning

Steg 1 - Processer och information

I de fall man har tillgång till system-information och process-informationsmatriser så är dessa en bra utgångspunkt. Meddelandeflödesbeskrivningen, liksom matrisen, bygger på att ta visa vilka processer och funktioner som skapar/ läser vilken information. Utifrån Process-informationsmatrisen använder man Visio och bifogade mallar för att rita processen och dess informationsbehov.
Eftersom det än så länge är sällsynt att arbeta med IRMs matriser så går det också bra att kartlägga processerna och dess informationsbehov på egen hand och genom dialog, kunskapen finns ju ofta lättillgänglig 

TIPS

  • Lägg inte tid på processernas storlek eller informationsbehovens exakta placering – dessa kommer du att behöva justera senare.
  • Visualisera även de processer/ funktioner som inte har direkt påverkan på meddelandeflödet.
  • Använd beskrivande namn på informationsbehovet. Ibland kan det vara nödvändigt/lämpligt att utifrån ett informationsobjekt skapa flera informationslinjer (ex vis ”skapad order” och ”stängd order” för det gemensamma objektet Order.

Steg 2 - System och integration

Använd system-informationsmatrisen för att placera in system och integrationspilar i Visiomallen för att visa på vilket meddelandeflöde som behövs för att svara upp mot respektive informationsbehov.
Meddelandeflödesbeskrivningen, liksom matrisen, bygger på att ta visa var data skapas/ändras och vilka system som är i behov av att läsa detta data.
I de fall matriser saknas så beskriv databehovet efter bästa förmåga, det är ju tämligen enkelt att förbättra bilden successivt. 

TIPS

  • Pilar kan göras på en mängd olika sätt (se nästa steg). I detta läge är det dock viktigt att utgå från det faktiska informationsbehovet och rita pilen från det system där data uppstår till det system som är i behov av data.
  • I de fall flera system är i behov av samma data så visualisera detta genom att lägga pilen bakom systemet. På så vis ser man vilket system datat kommer ifrån (se exempel till höger där system C får data från system A. Detta kommer tydliggöras än mer om/ när gränssnitt ritas in.

Steg 3 - Data och gränssnitt

Utifrån vad som är känt kring eventuella gränssnitt så lägg till information om gränssnittsnamn (ofta säger ett frågetecken mer än att lämna det blankt), meddelandeformat och integrationstyp.
I detta läge kan det också vara bra att fundera på om man vill visualisera/ tydliggöra olika ansvarsdragningar i utvecklingen, ex vis om flera olika leverantörer är inblandade (ej med i bilden till nedan).

TIPS

  • Benämning av meddelandetyp har visat sig viktigt i detta läge då en bra namnstandard, ex vis IM för kanoniskt format, underlättar förståelsen. Utifrån ditt företags standardnamnsättning kan det också vara lämpligt att inkludera integrationsnamnet, ex vis INTxxxx, för att peka till rätt mappningsspecifikation och lösningsdokument.

Steg 4 - Status och prioritet

Särskilt i ett utvecklingsskede så är det viktigt att ha en uppdaterad status för gränssnitt och integrationer. För att göra detta rekommenderas enklast möjliga färgläggning i grönt, gult och rött.
Prioritering anges lämpligen genom att vikta strecken/ pilarna

TIPS
Likt bilden till höger så bör du lägga till en förklarande ruta för status och prioritet.

Steg 5 - Färdigställande

Rensa upp, tydliggör delar som återstår (hamnar i förvaltning)  eller inte fungerar tillfredsställande. Tänk också på att hålla bilden levande under informationsbehovets livscykel.

Avslutningsvis

Den modell jag har tagit fram används i dagsläget på två företag inom olika branscher och har presenterats och diskuterats i olika nätverk, bl.a. Enterprise Architect-forum.

Lycka till och hör gärna av dig om du har tips/ förslag på hur modellen kan vidareutvecklas.
- Daniel Krantz, Wi-Five AB

Kommentera gärna: