Summering

Syftet med ett Systemnedbrytningsdiagram är att visa vilka olika byggblock som ett system består av. Med system menas här ett tekniskt system som består av applikationer, datalager och fysiska resurser etc. Det gäller alltså inte verksamhetssystem eller organisatoriska resurser vilket ibland kan omfattas av systembegreppet.

På denna sida redovisas vilka olika intressenter och intressen som denna typ av modell riktar sig till, vilka ingående element och deras relationer samt vilken notation som används. Modelltypen använder sig av delar ifrån Metamodell för Teknisk arkitektur.

Exempel

Följande exempel av Systemnedbrytningsdiagramet visar hur man kan beskriva en applikation och dess komponenter. 

Syftet är att beskriva ett systems ingående komponenter. Här har bara objekten Applikation och Applikationsgränssnitt använts.

Systemnedbrytningsdiagram v 1.1

Systemnedbrytningsdiagram v1.1 med Journalsystemet TakeCare som exempel.

Relevanta intressen

Intressen:

• Vilka delar består systemet av?

• Vilka system använder en viss komponent?

• Vilka systemprogramvaror används?

• Underlag för teknisk design.

• Vilka gränssnitt erbjuder systemet till konsumenter.

• Förändringshantering av verksamhetssystemet och/eller dess miljö.

Intressenter:

• Förvaltningsledare

• Drift och Support

• Projektledare

• Lösnings- och IT-arkitekt

• Interna och externa leverantörer

Ingående element och relationer

Här beskrivs de element och relationer från metamodellen som används för att skapa modeller av denna typ. Dessa sammanfattas i följande bild:

Applikation är den mest centrala elementtypen i diagrammet då den definierar självständiga komponenter som levererar funktionalitet. Dessa kan uttryckas som logiska applikationer som exempelvis Journalsystem eller mer specifika/fysiska som exempelvis Cosmic. Logiska applikationer används ofta i referensarkitekturer som visar mönster medan de fysiska används i lösningsarkitekturer. En applikation bryts ofta ner i delar/komponenter genom relationen del av. 

En applikation realiserar applikationstjänster som har applikationsgränssnitt som beskriver hur applikationer interagerar med varandra. Samma tjänst kopplas till flera applikationer och sedan används gränssnitt för att detaljera respektive applikations roll i tjänsten. Exempelvis kan en applikation tillhandahålla ett producentgränssnitt som skickar ut information medan en annan har ett konsumentgränssnitt som tar emot informationen. Se även modelltypen Modelltyp - Applikationskommunikationsdiagram (Utkast) som kan användas i detta syfte.

För att beskriva den tekniska infrastruktur som applikationen exekverar på används elementet nod. Noder kan, precis som applikationer, uttryckas som logiska eller fysiska. Exempel på logiska noder är applikationsserver, filserver etc. medan fysiska talar om vilken specifik applikation det handlar om och ibland även version eller servernamn, exempelvis Apache Tomcat eller HAN-ADM-12.

Förutom nedbrytning i delapplikationer är det också möjligt att visa detaljer runt funktionalitet och data i ett systemnedbrytningsdiagram. Det finns risk för att diagram med denna information blir komplexa, så det är rekommenderat att göra två olika diagram som kan användas i olika syften. Ett rent nedbrytningsdiagram utan funktioner och datalager som visar vilka komponenter som systemet består av och vilken infrastruktur de är beroende av och ett mer detaljerat nedbrytningsdiagram som används för att definiera vilka applikationsfunktioner de olika applikationerna har och vilka datalager som används.

Form och notation

Modellen använder sig av element mestadels ifrån Metamodell för Teknisk Arkitektur samt Metamodell för Informationsarkitektur (Dataelement). Denna baseras till största del på Archimate från Open Group vilket gör detta till en lämplig notation.

Metoder och modelleringstekniker

Här beskrivs de metoder som kan användas för att skapa modeller av denna typ. Referera gärna till befintliga metoder i ramverket.

"Systemnedbrytningsdigrammet" visar vilka applikationskomponenter som bygger den aktuella applikationen och dess relationer, enklare desto bättre.

Syftet med Applikationskomponenten Applikation <NAMN> är det man i daglig tal hänvisar till t.ex TakeCare, Orbit, EK, Heroma etc medans de övriga Applikationskomponenterna som benämns Applikation <modulnamn> är de olika modulerna som bygger upp den aktuella Applikationen och/eller systemet.

Applikationskomponenterna som är moduler nämns ibland som "fysiska" för att de baseras på specifika programmoduler/paket som är autonomt installerbara och/eller levererade enskilt Jämfört med Applikation som benämns "Logisk"
Jämför t.ex med den logiska Applikationen Microsoft Office som består av autonoma och fysiska installerbara moduler såsom Word, Excel etc

Modelleringsanvisning:

• Modellen ska vara ENKEL och logisk.

• Modellen ska tydligt visualisera vilken komponent som är den logiska applikationen samt de ingående applikationskomponenter som är en del av systemet.

• Gränssnitt för t.ex klient och andra system bör ingå i modellen.

• Applikationsfunktioner kan används om ett system bara består av en applikation men man vill påvisa flera autonoma funktioner i applikationskatalogen T.ex ??? Exempel saknas

• Vissa system kanske bara beskrivs med en applikationstjänst, t.ex externa tjänster såsom Skatteverkets PU-tjänst, där det är ointressant att veta vilka applikationer/komponenter som bygger denna tjänst.

• Applikationsgränssnitt används för att påvisa att gränssnittet är en viktig komponent för helheten av den aktuella applikationen

• Ett fullständig Systemnedbrytningsdiagram bör skapas och underhållas av respektive ApplikationsFörvaltning

Granskningsstatus

Nedan dokumenteras olika organisationers granskningar och beslut angående denna sida. Se även Instruktion för att fylla i granskningsstatus.