Logisk Arkitektur & Systemkrav i 5 steg

"Walking on water and developing software from a specification are easy if both are frozen." - Edward V. Berard

Systemutvecklingens största utmaning? Gapet mellan affär och säkerhet. En klyfta som ständigt växer när utvecklarna tvingas gissa innan kraven är klara, och beställaren ändrar specifikationen när koden redan är skriven.

Verksamheten vill bygga funktioner som skapar värde. Säkerhetsavdelningen vill bygga skydd som förhindrar risker. För att bygga ett system som uppfyller kraven i Cybersäkerhetslagen (NIS2) utan att bromsa affärsmodellen, måste dessa två världar sammanfogas redan på ritbordet. I vår metodik sker detta genom att vi tar två parallella processer, verksamhetens krav och säkerhetens riskanalys, och väver ihop dem till en gemensam Funktionell och Logisk Arkitektur.

Funktionell arkitektur blir logisk

Nu börjar vi skönja ett system, den logiska arkitekturen är på nivån "ekonomisystemet" eller kanske "säljsystemet". Här ska jag visa hur du tar dig till denna logiska arkitektur utgående från funktionell arkitektur.

Pilotens kommentar: Funktion är säkerhet

Som pilot brukar jag tänka att logiskt består flygplanet av vingar, kropp, motor och en cockpit med en sittplats för piloten. Det är verksamhetskravet för att maskinen ska kunna flyga. Men när vi sammanfogar detta med säkerhetskraven, att piloten ska överleva ett haveri, förvandlas sittplatsen till ett räddningssystem med raketstol och fallskärm. Det är först när vi tvingar ihop funktion och säkerhet på ritbordet som systemet blir komplett.

Metod, hitta logisk systembeskrivning

Resan hit över funktion och säkerhet

Fram till denna fas har affärsutvecklingen och säkerhetsarbetet ofta bedrivits som två helt separata spår. Verksamheten har kartlagt sina värdeströmmar för sig, och säkerhetsexperterna har gjort sina riskanalyser för sig. Men det är nu de ovillkorligen måste sammanfogas. Om vi inte aktivt väver ihop affärsnyttan med riskhanteringen får vi ett system som antingen är säkert men obrukbart, eller funktionellt men sårbart – det blir med andra ord varken Safety by Design eller Function by Design.

Metoden i 5 steg, och hur vi följer ISO 15288

Enligt den internationella standarden för systemlivscykler, ISO/IEC 15288, är det helt avgörande att separera vad ett system ska göra (Architecture Definition) från hur det rent tekniskt ska byggas (Design Definition). Vår metodik följer detta rigoröst genom att bygga en komplett, teknikoberoende kravspecifikation i fem steg innan den tekniska lösningen väljs:

Sammanfoga Funktionell Arkitektur (Vad): Affärsbehov och säkerhetskrav vävs ihop till gemensamma systemfunktioner.
Skapa Logisk Arkitektur (Var): Funktionerna allokeras till abstrakta, logiska systemkomponenter.
Sätta Systemkrav (Hur bra): De logiska komponenterna kravställs med mätbara prestanda- och säkerhetskrav.
Informationsarkitektur (Vilken data): Systemets blodomlopp kartläggs i form av dataobjekt och informationsflöden.
Integrationsarkitektur (Hur de pratar): Logiska gränssnitt och API-kontrakt formaliseras mellan systemen.

Genom att arbeta enligt denna struktur säkerställer vi full spårbarhet från verksamhetens ursprungliga behov, hela vägen ner till de logiska gränssnitten. Vi bygger Safety & Security by Design på exakt det sätt som ISO-standarderna föreskriver.

1. Sammanfoga funktion & säkerhet

Det första vi gör är att ta verksamhetens funktionella krav (affärsvärdet) och säkerhetens funktionella krav (riskhanteringen) och slå ihop dem till en enda, gemensam modell. Istället för att ha säkerhet som ett externt dokument, bygger vi in det direkt i verksamhetsfunktionerna. Funktionen Transportledning ärver nu automatiskt säkerhetskraven på Skydd mot överbelastning. Vi fångar också upp strukturella säkerhetskrav här – till exempel att ett livskritiskt larm enligt ISO-standarderna kräver parallell larmhantering för att eliminera enskilda felkällor (Single Points of Failure). Det kritiska steget: Granskning och konflikthantering Innan vi går vidare måste denna kombinerade funktionella arkitektur granskas. Varför? För att affär och säkerhet ofta drar åt olika håll. Verksamheten kanske kräver "omedelbar tillgång", medan säkerhetsstandarden kräver "MFA vid varje inloggning". I granskningen identifierar och löser vi dessa krockar. Vi säkerställer att arkitekturen är komplett, spårbar och fri från logiska paradoxer – och att den uppfyller både affärsvärdet och kraven i NIS2.

Utgångspunketn är den funktionella arkitekturen med kraven mot desa funktioner. Det som ska hända nu är att denna funktionella arkiektur ska omvandlas till en logisk arkitektur.

2. Skapa den Logiska Arkitekturen

När den funktionella arkitekturen är granskad och godkänd vet vi exakt vad systemet ska göra. Andra steget är att ta hand om dessa funktioner genom att skapa en Logisk Arkitektur. Det är nu vi fördelar de säkrade funktionerna på logiska systemkomponenter. Vi bestämmer till exempel att funktionen Larmhantering ska exekveras inuti komponenten Gipsats Förmedlarserver, medan funktionen Platsbestämning ska hanteras av en app på den Skadads telefon. Säkerhetsfunktionerna blir tvingande krav på logiken Här måste vi också hantera de strukturella säkerhetsfunktioner vi slog fast i Steg 1. Om den funktionella arkitekturen kräver parallell larmhantering, blir detta nu ett tvingande krav på hur vi ritar logiken. Vi kan inte rita upp en logisk larmmottagare; säkerhetskravet tvingar oss att rita upp isolerade, parallella logiska komponenter (till exempel Kanal A, Kanal B och Kanal C) samt en logisk röstningsfunktion (Voter). Säkerhetsfunktionerna formar alltså rent konkret hur den logiska arkitekturen byggs upp.

3. Sätta krav mot Logiska Arkitektur

När vi har ritat upp den logiska arkitekturen har vi en karta över systemets komponenter. Men vi kan inte kasta över denna skiss till driftteknikerna ännu. En logisk komponent är bara ett tomt skal tills vi har ställt stenhårda krav mot den. Det är i detta tredje steg som vi bryter ner de övergripande funktionella kraven till mätbara systemkrav och icke-funktionella krav (prestanda, tillgänglighet, säkerhet) och allokerar dem till specifika logiska byggstenar. Om vi i Steg 1 hade ett övergripande funktionellt säkerhetskrav som sa "Systemet måste tåla överbelastningsattacker", måste detta nu översättas till ett systemkrav riktat mot en specifik plats i logiken. Kravet mot komponenten Gipsats Förmedlarserver blir då: "Servern MÅSTE ha en kapacitet som klarar 10 000 samtidiga larm per sekund och ha ett aktivt DDoS-skydd". Genom att kravställa den logiska arkitekturen skapar vi ett vattentätt "kontrakt" inför nästa fas.

4: Dataobjekt och Informationsbehov

Vi har nu definierat systemets funktioner (Steg 1), dess logiska komponenter (Steg 2) och ställt stenhårda krav mot dem (Steg 3). Men vi saknar en avgörande pusselbit: systemets blodomlopp. Vi måste veta exakt vilken information som rör sig i systemet. I den logiska arkitekturen drog vi informationsflöden (pilar) mellan komponenterna. I detta fjärde steg genomför vi en dataanalys och definierar exakt vad dessa pilar innehåller genom att rita in Data- och Informationsobjekt i ArchiMate. Mellan den skadades app och förmedlarservern definierar vi till exempel objekten Larmdata och Transportstatus. Mellan förmedlarservern och sjukhusets system definierar vi Inskrivningsdata och Journalunderlag. Genom att visuellt mappa vår data mot våra logiska komponenter ser vi direkt var känslig data vilar (Data at Rest) och var den transporteras (Data in Transit). Det är denna analys som dikterar var vi måste sätta in tunga tekniska säkerhetsåtgärder.

5. Integration i applikationslagret

Vi vet nu vilka komponenter vi har och vilken data som flödar mellan dem. Enligt systemutvecklingsstandarden ISO 15288 är det i detta skede avgörande att formellt definiera systemets gränssnitt (Architecture Definition) innan man låser sig vid en teknisk implementation (Design Definition). Det sista steget i den logiska arkitekturen är därför att formalisera exakt hur systemen pratar med varandra. Här skapar vi Integrationsarkitekturen i applikationslagret. Genom att rita in logiska gränssnitt (Application Interfaces) mellan våra komponenter och de externa systemen (som Sjukhusets journalsystem eller Ekonomisystemet), slår vi fast arkitekturens API-kontrakt. Vi knyter samman kraven från Steg 3 (t.ex. "Svarstid under 50ms") med dataobjekten från Steg 4 ("Journalunderlag"). Separation mellan kontrakt och lösning (Compliance med ISO 15288) Det är extremt viktigt – och kärnan i ISO 15288:s metodik för systemarkitektur – att vi på den här nivån strikt separerar arkitektur från fysisk design. Vi bygger enbart den logiska kravspecifikationen för integrationen. Vi bestämmer att systemen ska integreras, vilken data som utbyts och vilka prestandakrav som gäller. Men vi bestämmer absolut inte om utvecklarna sedan ska bygga det som ett REST-API, via GraphQL eller som en asynkron händelseström i Kafka. Genom att arbeta exakt så här uppfyller vi kraven på spårbarhet i ISO 15288, vilket håller arkitekturen ren, flexibel och helt oberoende av framtida teknikskiften. Bryggan till Teknisk Arkitektur: OSI-modellens 7:e lager När vi i det här steget fastställer de logiska gränssnitten (Application Interfaces) och API-kontrakten, befinner vi oss de facto i toppen av OSI-modellen – Lager 7 (Applikationslagret). Här överlämnar verksamheten stafettpinnen till tekniken. Vi vet exakt vad applikationerna ska prata om. Nästa steg blir att designa hur detta datakontrakt ska hanteras tekniskt; hur det krypteras (Lager 6), hur sessionen hålls öppen (Lager 5) och hur det transporteras redundant och säkert hela vägen ner till de fysiska kablarna (Lager 1).