Tjänster – den saknade pusselbiten i verksamhetsarkitekturen

Vi behövde utveckla sätt att analysera och beskriva hur olika funktioner i en verksamhet samverkar. Vi började med systemintegrationer. Det ledde fram till att vi upptäckte tjänsternas betydelse.

En verksamhet samverkar via tjänster

En verksamhet är ett system – ett sociotekniskt system som är uppbyggt av ett antal avgränsade delar med olika uppgifter. Varje sådan del består av både människor (roller) och it-applikationer och kan i allt väsentligt ses som en egen liten verksamhet, med allt vad detta innebär. Vi kan kalla en sådan avgränsad del för en verksamhetsfunktion. Vi behöver skilja detta från en verksamhetsförmåga. En förmåga är något en verksamhet behöver kunna åstadkomma, vilket vanligen kräver samverkan mellan många olika funktioner.

Samverkan sker genom överenskomna tjänster, där en funktion tillhandahåller någon nytta som en eller flera andra funktioner eller externa parter behöver. Vi behöver lyfta fram, beskriva och hantera dessa tjänster som viktiga beståndsdelar i vår organisations verksamhetsarkitektur. På så sätt skiljer vi gränssnittet (vad en funktion levererar), från implementationen (hur funktionen fungerar internt). Detta är en grundläggande princip för att hantera komplexitet i alla typer av system, från ekologiska system till sociala och tekniska system.

I den här artikeln beskriver jag hur vi kan lyfta fram både interna och externa tjänster som de viktiga komponenter de utgör i verksamhetsarkitekturen och varför vi behöver göra det. Men jag tror det blir tydligast om jag först beskriver hela den resa jag och mina kollegor gjorde som ledde fram till hur vi kunde kartlägga tjänsterna i verksamhetens arkitektur. Den berättelsen börjar med bakgrunden.

Vad it-arkitekternas integrationskartor kunde avslöja om verksamhetens struktur

Vårt lärande tog avstamp i hur man som it-arkitekt brukar kartlägga systemintegrationer. It-system utbyter data med varandra, både inom och mellan organisationer. Det kan ske på flera olika sätt. Traditionellt har man med hjälp av särskilda kommandoskript tagit ut data ur ett källsystems databas, paketerat dem i en datafil som skickades till och lästes in i det mottagande systemets databas.

För kommunikation i realtid är så kallade API:er (Application Program Interface) vanliga. Det innebär att ett it-system tillhandahåller ett definierat gränssnitt som ett annat it-system kan anropa och få svar från direkt.

Att på detta sätt koppla samman it-system brukar kallas systemintegrationer. Antalet integrationer har vuxit explosionsartat i takt med att kommunikationsteknikerna utvecklats. Det har gjort att vi idag har spaghettiliknande it-miljöer som få eller inga har överblick över.

It-arkitekter brukar ta fram kartor som visar hur it-systemen är integrerade med varandra.

Förenklat ritar man ett centralt it-system i mitten och ser det som ett nav med andra it-system som satelliter runt omkring. Pilar mellan systemen visar hur data flödar.

En sådan karta beskriver it-miljön, inte hur verksamhetens funktioner samverkar. Men vi upptäckte något intressant. Med hjälp av det som kallas Conways lag kunde vi ur en sådan karta, tillsammans med verksamhetens sakkunniga, härleda hur verksamheten var strukturerad.

Conways lag säger att strukturen hos ett it-system tenderar att avspegla utvecklingsteamets organisation. Om man kan tillämpa detta på en hel it-miljö innebär det att struktur tenderar att spegla verksamhetens struktur. Vi upptäckte att detta faktiskt fungerade.

Det vi då fick fram var hur verksamheten var uppbyggd av funktioner och hur dessa samverkade. Kartläggningen gick snabbare och gav en bild som visade sig bättre stämde överens med verkligheten än vad vi kunde få fram genom organisationsschema, processmodeller och hörsägen.

It kunde nu ses som en integrerad del av verksamheten

Vi kunde alltså utgå från en integrationskarta och steg för steg utveckla den till en karta som visade inte bara it-arkitekturen utan hela verksamheten. It-systemen och deras integrationer framträdde därmed för första gången som en integrerad del av verksamheten.

Att verkligen se och hantera it som en integrerad del av verksamheten är viktigt menar vi. Detta sägs visserligen ofta som en självklarhet, men så länge vi ritar våra it-landskap som något fristående från den verksamhet de ska stödja blir det tomma ord.

Det är fortfarande alltför vanligt att verksamhetsarkitekter har sin bild av verksamheten och it-arkitekter en helt annan. När vi i stället kan samlas runt vad som i grunden är en och samma övergripande karta, där verksamheten och dess it visas tillsammans i samma vy, så uppstår en gemensam begreppsvärld, förståelse, och samarbete.

Tvärfackligt samarbete är inte att man samlas och framför sina respektive synpunkter. Det kräver att man har en gemensam grundläggande mental bild, gemensamma begrepp och språk. Kort sagt att man jobbar runt en gemensam karta som kan sammanföra de olika perspektiven.

Att utgå från it-miljön för att kartlägga hur en verksamhet är uppbyggd kan jämföras med den roll arkeologin spelar inom historievetenskapen. Det är en metod som ger oss konkreta fakta, en fast grund att utgå från när vi vill förstå hur något faktiskt ser ut.

Men precis som inom arkeologin krävs omdöme och tolkning för att förstå sammanhangen. Fakta räcker inte. Vi behöver tolka vad vi finner tillsammans med verksamhetens sakkunniga.

Hur vi behövde lyfta fram it-applikationerna i stället för it-systemen

Men för att Conways lag skulle kunna användas behövde vi först se över våra egna begrepp. Begreppet it-system kändes för grovt för att kunna kopplas direkt till verksamhetsfunktioner. It-system beskriver främst en teknisk paketering, alltså vad som råkar vara paketerat tillsammans. Vi behövde i stället ett begrepp som kunde kopplas till specifika verksamhetsfunktioner: ”it-applikationer” eller ”it-tillämpningar”.

En it-applikation är per definition ett it-system, eller avgränsad del av ett it-system, som hanterar något i en viss verksamhetsfunktion. Det vill säga innehåller verksamhetslogik kopplad till en specifik verksamhetsfunktion. Låt mig ge ett exempel.

Ett affärssystem består nästan alltid av flera olika it-applikationer. Det kan vara applikationer som kundregister, produktkatalog, beställningsregister, kundreskontra med mera, där var och en utför något som är en del av någon enskild verksamhetsfunktion. De bör därför betraktas som egna it-applikationer – avgränsade och självständiga, men integrerade med varandra genom datautbyten. En it-applikation kan också vara en Excelsnurra som tar fram månadsrapporten.

Med detta synsätt blir en it-applikation per definition alltid en integrerad del av en verksamhetsfunktion. Många av de verksamhetsfunktioner som på detta sätt identifieras återfinns som enheter i organisationsschemat, men sällan alla. En del är outtalade och föga formaliserade, men finns där likafullt och bör lyftas fram som egna verksamhetsfunktioner, viktiga pusselbitar i verksamhetsarkitekturen. Det gäller särskilt gemensamma stödfunktioner, till exempel funktioner för olika typer av masterdata.

Med det här sättet att rita kan vi inte bara visa hur data strömmar mellan it-applikationer, utan samtidigt också mellan verksamhetsfunktioner. Vi har därmed fått en karta som visar it-miljön som en integrerad del av verksamheten.

De som ser en sådan karta brukar reagera som om det är första gången de ser en riktig ritning över verksamheten – en bild som visar vilka delar den faktiskt består av och hur dessa kommunicerar med varandra genom dataflöden.

Men vi kunde ta ytterligare ett steg i hur vi avbildade och hanterade verksamheter. Ett viktigt steg: att lyfta fram de verksamhetstjänster som ligger bakom dataflödena.
Detta är denna artikels egentliga budskap. Det du hittills läst är bara bakgrunden.

Hur vi kunde lyfta fram tjänsterna bakom dataflödena

Vi märkte att det som hände mellan verksamhetsfunktioner behövde beskrivas som något mer än bara dataströmmar.

Allmänt gäller att när parter samarbetar så sker det genom någon form av transaktion. Då måste det också finnas en överenskommelse, ett slags kontrakt, som beskriver vad parterna kan förvänta sig av varandra samt när och hur en transaktion kan ske. Det är alltid en part som erbjuder någon form av nytta till en eller flera andra parter. Själva erbjudandet kan vi se som en tjänst.

Detta gäller också för de parter som en verksamhet består av, det vill säga verksamhetsfunktionerna.

Vi såg mycket att vinna på att låta kartan lyfta fram verksamhetstjänsterna i sig. Kopplingar mellan it-applikationer respektive verksamhetsfunktioner handlar nämligen inte i första hand om att data strömmar. De handlar först och främst om att en verksamhetsfunktion erbjuder någon form av nytta till en eller flera andra verksamhetsfunktioner.

Den nyttan kan förstås bestå enbart i att utbyta data, till exempel rapportering eller fråga/svar. Men ofta är nyttan mer grundläggande. En verksamhetsfunktion kan till exempel erbjuda möjligheten att beställa eller leverera något. Detta medför visserligen nästan alltid någon form av dataöverföring, men den primära nyttan, själva tjänsten, är något mer grundläggande för verksamheten. Datautbytet blir då snarare en konsekvens av tjänsten än tjänsten i sig.

På så sätt kunde vi börja se all integration mellan verksamhetsfunktioner som tjänster. Det vill säga som erbjudanden där en verksamhetsfunktion erbjuder någon form av nytta till en eller flera andra parter, interna eller externa.

Vi valde att rita en tjänst som cirkel på ett skaft som sticker ut från verksamhetsfunktionen. Det symboliserar att tjänsten är synlig från omgivningen och går att interagera med. Vi ritade sedan själva konsumtionen av tjänsten som ett streck från den konsumerande parten med en halvcirkel som omsluter cirkeln.

Den verksamhetsfunktion som erbjuder tjänsten kallade vi för producent och ägare av tjänsten medan den eller de verksamhetsfunktioner som använder tjänsten kallades konsumenter.
(Symbolerna har vi lånat från UML där de på motsvarande sätt betecknar ett gränssnitt och konsumtion av detta.)

På detta sätt kunde vi se en verksamhet, tillsammans med dess it-miljö, som ett nätverk eller ekosystem av parter och verksamhetsfunktioner som samverkar operativt genom de tjänster de erbjuder varandra. Vi fick på detta sätt en mer heltäckande och tydlig karta över verksamheten. Vi kunde se inte bara vilka delar verksamheten bestod av, utan också vilka beroenden som fanns mellan delarna och vad dessa beroenden handlade om.

Det var först då det kändes som att vi verkligen kunde se och hantera verksamhetens hela struktur, det vill säga verksamhetsarkitekturen på riktigt.

Förklaring: Vad menar vi med tjänst? I denna artikel använder vi termen tjänst (service) i dess allmänna och ursprungliga betydelse: ett erbjudande från en part till en eller flera andra.I tekniska sammanhang, som SOA (Service Oriented Architecture) har termen en delvis annan och snävare betydelse och betecknar då en programvara bakom som åstadkommer nyttan. Den betydelse vi avser här motsvarar närmast det som inom SOA kallas Service Endpoint, och representeras i UML av just den symbol vi använder.

Hur vi kunde få med även manuella tjänster

Vi insåg snart att det inte bara var it-applikationer i verksamhetsfunktionerna som tillhandahöll och konsumerade tjänster. Det fanns också andra aktörer, i form av mänskliga roller. Även dessa är viktiga element i verksamhetsarkitekturen.

En roll kan tillhandahålla en tjänst. Det är precis det som sker när någon kan mejla, ringa eller besöka en viss funktion för att få något utfört. På motsvarande sätt kan en roll konsumera en tjänst, antingen en manuell tjänst eller en digital tjänst, till exempel genom en rapport eller annat gränssnitt.

Nu kunde vi alltså beskriva samspelet mellan människor, mellan it-applikationer och mellan människor och it-applikationer med samma språk och i samma modell. Tillsammans med det vi redan kunde beskriva mellan verksamhetsfunktioner och externa parter omfattade modellen nu hela verksamhetens samspel.

Detta är egentligen slutet på berättelsen, men jag tror att det är värdefullt att reflektera vad allt detta innebär för arbetet med verksamhetsarkitekturen. Resten av artikeln handlar om detta.

Vad vann vi?

Vad vann vi då på att gå från att enbart se dataflöden till att i stället lyfta fram tjänsterna – de överenskomna erbjudandena bakom dataflödena – som fullvärdiga element i verksamhetsarkitekturen? Idag kan vi se de här vinsterna.

1. Hantering av komplexitet genom komponentisering och inkapsling

De tjänster en verksamhetsfunktion producerar utgör funktionens gränssnitt mot omvärlden. I många sammanhang behöver vi bara bry oss om vad en funktion erbjuder, inte hur den åstadkommer det.

Komponentisering och inkapsling är grundläggande principer för att hantera komplexitet. Genom att tydligt skilja utsida från insida kan vi lyfta fram verkliga beroenden och samtidigt reducera onödiga beroenden. På det sättet kan vi utveckla olika delar av verksamheten mer självständigt.

Det är en princip vi använder i alla sammanhang, både inom teknik, vetenskap och samhälle där vi behöver hantera komplexitet. Det är viktigt även inom verksamhetsarkitektur. Att hantera komplexitet är djupast sett det som hela vår uppgift som arkitekter går ut på.

2. Hantering av beroenden

Att förstå, kommunicera och hantera beroenden mellan komponenter – verksamhetsfunktioner, roller, it-applikationer och externa parter – är grundläggande vid all utveckling, och därmed ett viktigt syfte för verksamhetskartan.

När vi lyfter fram tjänsterna blir dessa beroenden synliga. Både vad ett beroende handlar om och dess riktning.  Genom att synliggöra beroendena som sträcker sig över både verksamhet och it får vi den gemensamma spelplan vi behöver.

3. Hantering av olika kontext för informationsmodeller

En informationsmodell är giltig för ett visst sammanhang, den har alltid en viss kontext. Den centrala aspekten av en kontext är för vilken geografi i verksamheten modellen gäller. En modell kan om den är mycket allmän, gälla för hela verksamheten. Men ofta kan den gälla endast för en viss verksamhetsfunktion, en viss it-applikation eller tjänst. Verksamhetskartan fungerar som en kontextkarta, den ger oss en geografi för att orientera våra modeller.

Detta gäller egentligen alla slags modeller, men i synnerhet är det viktigt för våra informationsmodeller.

4. Hantering av it som en integrerad del av verksamheten

Verksamhetskartan ger en gemensam mental bild där it-applikationer och systemintegrationer är integrerade i verksamheten. Det är en förutsättning för att vi ska få bort den klyfta vi har idag mellan verksamhet och it.

5. Hantering av tjänstekontrakt

Alla tjänster bygger på överenskommelser mellan producent och konsument. De handlar om allt från kommunikationsteknik och meddelandemönster till syntax, semantik, säkerhet med mera.

Dessa överenskommelser är sällan genomtänkta och dokumenterade, i synnerhet inte då det gäller interna tjänster. De är helt centrala delar av verksamhetsarkitekturen som vi behöver ta kontroll över.

När tjänsterna blir synliga i verksamhetsarkitekturen blir dessa kontrakt möjliga att synliggöra och hantera.

6. Geografi åt processmodellerna

En process visar i vilka steg något sker. Detta sker någonstans och på något sätt, som en resa genom en verksamhets olika funktioner, it-applikationer, roller och tjänster. Om verksamhetskartan är kartan över landskapet så är processbeskrivningen en beskrivning av en specifik resa genom detta landskap. Tjänsterna är som vägarna och funktionerna är som orterna som besöks under resan. På så sätt kan vi koppla en process till hela ekosystemet.

På en annan nivå, om vi tänker oss att vi zoomar in i verksamhetskartan finns det en process bakom varje tjänst. En tjänst producerar ju något. Därmed finns det någon form av process bakom tjänsten som åstadkommer det tjänsten erbjuder.

Verksamhetskartan bygger på systemteori och är därmed är fraktal. Det betyder att om vi zoomar in får vi i grunden samma principiella struktur.

7. Koppling av kundresor mot verksamhet- och it-arkitektur

En kundresa visar vad en kund upplever i succesiva möten med vår verksamhet. Affärsutvecklare beskriver och analyserar kundresor för att förstå och förbättra kundupplevelser som helhet.
Problem i kundresor upplevs i själva kundmötet men beror ofta på brister längre bak i verksamhetens maskineri. Om vi vill fixa problem i kundresor behöver vi kunna gå på djupet. Verksamhetskartan ger oss möjligheten att spåra orsaken till problem i alla led och utforma möjliga lösningar.

8. Bild av verksamhetens storskaliga struktur

När tjänster och beroenden blir synliga framträder också verksamhetens större mönster. Vissa verksamhetsfunktioner vänder sig mot kunder, andra är kärnfunktioner och stödfunktioner.
Det handlar om den horisontella skiktning (och ofta även vertikala sektorisering) som alltid finns i en verksamhet men som inte alltid är förstådd och kommunicerad.
Det finns några typer av storskaliga mönster som vi som arkitekter behöver förstå, kommunicera och ta hänsyn till.

Om SOA – och den saknade verksamhetensarkitekturen

När kostnaden för integrationer sjönk på 2000-talet växte det fram ett nytt ideal för it-lösningar: tjänsteorienterad it-arkitektur, SOA, Service Oriented Architecture.

Tanken var att ersätta stora monolitiska system med ett stort antal små självständiga moduler. En sådan modul, som kallades service eller tjänst, gjorde en sak bara. Dessa moduler skulle kunna kombineras flexibelt, likt legobitar, till större samverkande system.

Målet var ökad flexibilitet och återanvändning. Men visionen fick inte riktigt lyftkraft. Det blev ett myller av sådana moduler. Bördan att hantera all interaktion mellan dessa blev för stor för de flesta organisationer.

Men erfarenheterna var värdefulla. Vi lärde oss mycket av det som idag ligger till grund för hur vi dimensionerar, bygger och integrerar it-system för bättre flexibilitet och hållbarhet. SOA-epoken gav oss ett bredare register av möjliga it-lösningar och bättre förståelse för hur vi ska designa och hantera hela it-miljöer och integrationer rent tekniskt.

En effekt har blivit att it-system idag exponerar funktionalitet i form av API:er vilkas design bygger mycket på SOA-principer.

Men en brist med tänkandet runt SOA var att kopplingen till själva verksamhetens var svag, för att inte säga obefintlig. Hela tänkandet tog stopp då det kom in på frågor som handlade om annat än själva it-arkitekturen.

Jag minns de tjocka böcker som skrevs om hur tjänster skulle utformas rent tekniskt. Någonstans nämndes att hela den svärm av tjänster man skulle ta fram naturligtvis skulle baseras på en genomtänkt verksamhetsarkitektur. Men hur en sådan skulle se ut, och hur man skulle ta fram den, var helt och hållet utlämnat till läsaren.

En annan begränsning var att SOA var helt fokuserat på att bygga små modulära it-komponenter, och tog därmed inte hänsyn till dels existerande it-system och integrationer, dels nya it-system som av olika anledningar var mer monolitiska, dels alla tjänster i en verksamhet som inte var digitala.

Genom att i stället utgå från verksamhetens tjänster, både digitala och manuella, kan vi realisera mycket av det SOA eftersträvade, men med verksamheten som utgångspunkt i stället för tekniken. Resultatet blir inte bara en tjänsteorienterad it-arkitektur, utan en tjänsteorienterad verksamhetsarkitektur.

Hur hanterar ni tjänsterna i er verksamhet?

Det är hit vi kommit idag i vårt arbete med att utveckla hur vi kan kartlägga och avbilda verksamhetens arkitektur.

Vi har gått från att se dataflöden mellan it-system till att beskriva hur verksamheten faktiskt fungerar – som ett nätverk av verksamhetsfunktioner som samverkar genom tjänster. Därmed kan vi nu beskriva hur verksamheten fungerar på riktigt, det som annars är dolt långt ner i it-miljön bland alla integrationer.

Organisationsscheman, processmodeller och förmågekartor har sina roller, men räcker inte. Vi behöver också kunna beskriva tjänsterna och de beroenden som binder samman verksamhetens olika delar.

Jag hoppas att den här artikeln kan inspirera till att börja se och hantera tjänster på ett mer medvetet sätt.

Men utvecklingen kan väl inte stanna här? Hur kan vi ta detta vidare?
Det finns till exempel mycket kvar att utforska kring hur vi kan skriva tjänstekontrakt.

Hur arbetar ni med tjänster i er verksamhet? Vi tar gärna del av era erfarenheter, synpunkter och invändningar. Låt dialogen fortsätta!