Förmågekartor för informationsarkitektur – del 6: En verksamhetsförmåga, bit för bit

Hur hänger en verksamhetsförmåga ihop med verksamhetsprocesser, tjänster med mera? Låt oss resonera om det!

/Peter Tallungs, IRM 2023-01-12

Om en verksamhetsförmåga är en avgränsad del av en verksamhet som omfattar saker som processer, it-system, kompetenser, roller med mera, vad innebär det? Hur hänger dessa olika företeelser ihop med varandra och med verksamhetsförmågan som helhet? Vi behöver en metamodell för den sammansatta sak som vi kallar för verksamhetsförmåga, för att förklara hur allt detta hänger ihop. Vi kan skapa en sådan genom att bit för bit bygga upp ett tänkt exempel på en verksamhetsförmåga och resonera oss fram längs vägen.

I denna artikel använder jag ett tänkt exempel på en verksamhetsförmåga.

En förmåga och dess tjänster

Säg att vi har en bankverksamhet och en av de förmågor vi behöver är Lånehantering (Loan Management). Det vill säga en förmåga att hantera bankens utgående lån. För detta exempel kan vi rita förmågan som en ruta. Denna illustrerar att förmågan är något avgränsat, som har en utsida och en insida.

Hela meningen med en förmåga är att erbjuda nytta till sin omgivning, i detta fall till banken som helhet. För exemplets skull antar vi att förmågan kan erbjuda att behandla en låneansökan som har tagits emot av kundtjänst, (Apply for Loan) samt att man kan förnya ett lån när det efterfrågas (Renew Loan).

Vi kan se det som att förmågan tillhandahåller tjänster till sin omgivning. Jag brukar rita dessa tjänster som ”godisklubbor” som sticker ut från förmågan. Detta sätt att rita vill förmedla att en tjänst är något som förmågan exponerar för omvärlden att använda. (I verkligheten skulle förmågan säkert behöva ha fler tjänster, som till exempel att avsluta lån och rapportera vilka lån som finns.)

Definitionen av en tjänst är, både rent allmänt och specifikt för verksamheter, att en part erbjuder en eller flera tänkta eller verkliga parter någon form av nytta. Vi behöver också tänka att detta på något sätt är ett stående erbjudande. Den som tillhandahåller tjänsten är producent och ägare av tjänsten. Den eller de som använder tjänsten (tänkta eller verkliga parter) är konsumenter av tjänsten.

Om vi betraktar verksamhetsförmågor på det mycket konkreta sätt som jag propagerat för i tidigare artiklar i serien, det vill säga som parter med egen agens, så bör både producenter och konsumenter av tjänster alltid vara verksamhetsförmågor. Producent av en tjänst är den förmåga som tillhandahåller och utför tjänsten. Konsumenter kan vara en eller flera andra förmågor, liksom externa parter. Externa parter är andra verksamheter eller funktioner hos verksamheter, som också är förmågor, i betydelsen avgränsade autonoma verksamheter. Om vi uppfattar förmågeperspektivet som ett fraktalt perspektiv är ju också en hel verksamhet att betrakta som en förmåga, i det större sammanhanget.

Om tjänster

Varje integration mellan två parter bör ses som en tjänst menar jag, oavsett kommunikationsteknik och meddelandemönster. Det är en vidare användning av begreppet än gängse inom programvaruutveckling, men jag tycker att det är det enda rätta om vi ska lyfta oss från specifika tekniker och till de mera generella synsätt som vi behöver för att hantera verksamhetsarkitekturen i våra organisationer. En tjänst kan alltså vara implementerad på olika sätt, allt från ett API (att två programvaror kommunicerar via ett elektroniskt gränssnitt), en webbsida som en person går in på, en kund som ringer en handläggare, till en fil som skickas, eller till och med att ett it-system går in och skriver i en databas som tillhör en annan del av verksamheten.

Vi behöver ha en definition av begreppet ”tjänst” som står över både teknik och specifikt meddelandemönster. Inte för att teknik och meddelandemönster inte skulle vara viktigt, utan för att dessa hör till en mer teknisk nivå av analysen och designen av en verksamhet. Om jag anmäler något till ett företag via telefon, eller via app, eller via ett API från min egen programvara är det ändå samma tjänst jag använder, det är samma möjlighet att anmäla som företaget exponerar via olika kanaler.

På 00-talet blev tjänsteorienterad arkitektur (Service-Oriented architecture, SOA) en hajp bland oss it-arkitekter. Man lyfte fram tjänster som något centralt i en it-arkitektur. Men SOA levererade aldrig som det var tänkt och hajpkurvan föll brant nedåt efter något år. Man kan säga att SOA direkt återuppstod i form av det som kallas mikrotjänster, som fortfarande lever. Men där handlar det fortfarande bara om it-arkitektur, det vill säga hur man ska strukturera och modularisera programvaror. Och inte alls om det som vi här pratar om, verksamhetsarkitektur, det vill säga hur vi ska förstå och hantera våra verksamheters strukturer.

Det jag uppfattade som den viktiga tanken i SOA var att man ville lyfta tjänster till fullvärdiga medlemmar i en arkitektur. Jag tror att man hade behövt se SOA som något som inte var isolerat till it-arkitekturen utan i stället hade setts som en fullvärdig komponent i verksamhetsarkitekturen.

Felet man gjorde var att man inte hade något sätt att förankra och hantera tjänsterna i verksamhetsarkitekturen. Det fanns tjocka böcker om SOA, som handlade om hur man skulle designa de programvarukomponenter man kallade för tjänster, och hur man skulle designa hela sin it-miljö som hela bibliotek av tjänster. Man skrev ibland om att det var oerhört viktigt att detta system av tjänster var tydligt förankrat i en gemensam och genomtänkt verksamhetsarkitektur. Men ingen visste hur en sådan skulle se ut, och verksamhetarkitekterna var knappast med i matchen.

Resultatet blev att de tjänster man byggde svävade fritt i verksamheten utan hemvist och ägarskap. En annan svaghet var att det man såg som tjänster endast var sådant som var implementerat som elektroniska tjänster och endast efter de särskilda regler man hade tagit fram.

Jag tycker att tjänster är viktiga komponenter i en verksamhetsarkitektur. Men då behöver varje tjänst vara förankrad någonstans i verksamheten. Det finns alltid någon som producerar tjänsten och förhoppningsvis en eller flera som konsumerar tjänsten. Och både konsumenter och producent bör alltid identifieras som verksamhetsförmågor. Och att begreppet ”tjänst” då bör inbegripa allt som handlar om att en part tillhandahåller en nytta för en annan part, oavsett med vilken teknik den är implementerad. Vi kan inte ha en verksamhetsarkitektur som är begränsad till en viss teknik.

Alltså, en verksamhet kan ses som ett antal avgränsade autonoma delar (verksamhetsförmågor) som samverkar dynamiskt i nätverk. Sättet de samverkar på är att en verksamhetsförmåga tillhandahåller en eller flera nyttor (tjänster) som andra verksamhetsförmågor konsumerar.

Då får vi, med hjälp av förmågekartan, den verksamhetsarkitektur vi behöver, där tjänster har sin självklara plats. Inte minst får vi då något som är mycket viktigt i en arkitektur, en tydlig gemensam bild av vad som är beroende av vad. Ty det är alltid en konsument av en tjänst som är beroende av tjänsten, och därmed av den verksamhetsförmåga som äger och producerar tjänsten. Aldrig tvärtom.

Vad som bör ses som en och samma förmåga

Men varför är då inte ”Ta emot och hantera låneansökan” samt ”Förnya lån” egna förmågor? Det är en relevant fråga. En förmåga ska ju vara en del av en verksamhet som vi vill se och hantera som en helhet. Vad vi vill se och hantera som en helhet, hur vi önskar att dela ner en verksamhet i hanterbara bitar beror av många faktorer och är till syvende och sist en subjektiv bedömning. Men det finns några grundregler:

1. En förmåga ska vara något som har relativt stora inre samband i jämförelse med kopplingar till omvärlden. Det vill säga att vi strävar efter att modularisera verksamheten genom att dela in den i moduler som är så oberoende av varandra som möjligt. Det är samma som att kopplingarna till och från omvärlden blir så få, enkla och enkelriktade som möjligt. Om två processer eller it-system har ett ömsesidigt och tätt beroende av varandra bör de ligga i samma förmåga.
2. Det är egentligen inte så viktigt exakt hur vi delar ner verksamheten i förmågor. Det finns förstås indelningar som är bättre än andra, men två alternativ kan vara ungefär lika bra.
3. Det är däremot viktigt att vi är överens om indelningen och att den har mening för oss, vilket märks om det är lätt att sätta namn och beskrivning på förmågan.
4. Förmågan måste ha en tydlig identitet och avgränsning. Det ska vara lätt att förstå vad som är utsida och insida.

Det här är precis samma principer för hur vi betraktar och hanterar omvärlden i alla sammanhang, såväl det gäller materiella som immateriella företeelser, samt både sådant vi konstruerar själva och saker som vi bara betraktar. Vi söker hålla ihop det som har ömsesidiga inre beroenden och separera det som inte har mer enkla och raka beroenden.

I detta fall är min spontana och preliminära bedömning att hantera låneansökan och att hantera förnyelser är två tjänster som kräver ungefär samma kompetenser, resurser, it-stöd med mera. Och därför placerar jag dessa som två tjänster som ägs av en och samma förmåga.

Processer i förmågor

En verksamhetsförmåga måste ju på något sätt göra det jobb som krävs för att leverera en tjänst. Då behöver varje tjänst som förmågan producerar vara kopplad till en process som löper inuti förmågan. Processen är själva logiken för vilka arbets-steg som behöver ske för att leverera tjänsten i fråga.

Om man ser det på detta sätt får vi en tydlig uppdelning. En verksamhetsförmåga är en autonom avgränsad del av en verksamhet (eller en hel verksamhet, när vi vill se den som en komponent i ett större sammanhang). En tjänst är en nytta som en verksamhetsförmåga tillhandahåller till sin omgivning. Och en verksamhetsprocess är arbetet som behöver utföras för att leverera den nytta som erbjuds via en tjänst. Det är inte alltid så dessa termer brukar användas. De kan ofta betyda lite vad som helst, med svampiga och otydliga definitioner. Men jag tycker att på detta sätt får vi ordning och reda och den begreppsapparat vi behöver för att bygga en verksamhetsarkitektur.

Förmågor i förmågor

En verksamhetsförmåga kan alltid, när så behövs, delas ner i verksamhetsförmågor på lägre nivå. Kanske vill man se kreditbedömningen (Credit Scoring) som en egen förmåga inom lånehanteringen. Och låneadministrationen (Loan Operation) som en annan.

Eftersom dessa förmågor ingår som delar av lånehanteringen och inte används någon annanstans så finns de helt och hållet inom förmågan Loan Management.

De exponerar tjänster som används av lånehanteringsprocesserna. Samtidigt har de själva sina egna processer för att leverera sina tjänster.

Huvudförmågor och stödförmågor

När vi betraktar förmågorna inom en större förmåga kan vi dela in dem i huvud- och stödförmågor. Det som bestämmer om det är en huvud- eller stödförmåga är vilken räckvidd förmågans tjänster har i förhållande till den förmåga den ingår i. Credit Scoring och Loan Operation är förmågor vars tjänster endast används och har mening inom Loan Management. De är stöd till processerna inom Loan Management och exponerar inte sina tjänster utanför Loan Management.

Processerna Loan Appliance och Loan Renewal borde kanske också finnas inom sina egna förmågor, vilka också är komponenter av den större förmågan. Jag väljer här att inte rita ut dessa. Dessa är då huvudförmågor inom Loan Management. Skillnaden är att huvudförmågorna exponerar sina tjänster externt från den förmågan de ingår i och stödförmågor endast internt.

Externa förmågor

Kreditbedömningen tar hjälp av en extern part för att bedöma en låneansökares kreditvärdighet, det vill säga en kreditbyrå som tillhandahåller personers kredithistoria. På detta sätt är även förmågor som är externa till verksamheten leverantörer av tjänster som våra förmågor använder i sina egna processer.

Informationssystem och verksamhetsförmågor

Jag tycker att det är viktigt att se informationsteknikens användning som en integrerad del av verksamheten och inte som något eget. Det är fel att säga att informationssystemen stödjer verksamheten. För då ser man informationssystemen som något eget. I själva verket är informationssystemen en fullvärdig komponent av verksamheten. En verksamhetsförmåga omfattar alltid de applikationer som används i den verksamhetsförmågans processer. När man utvecklar en applikation utveckla man egentligen verksamheten i en viss verksamhetsförmåga. När man handhar driften av en applikation opererar man egentligen verksamhetsförmågan. (Vi pratar inte här om serverdrift utan applikationsdrift, det vill säga allt det man behöver göra för att hålla applikationen igång och därmed verksamheten.) Likaså, när man ger användarstöd så ger man egentligen stöd åt processen i verksamhetsförmågan.

Det finns således inga it-projekt i våra verksamheter, bara verksamhetsprojekt. Många gånger hör man detta upprepas som ett mantra, men det är sällan mer än en tom fras. Man har inte förstått innebörden.

Verksamhet och applikationer sitter ihop med korsvisa beroenden. Verksamheten formar applikationerna och applikationerna formar verksamheten. Därför måste vi se it som en fullvärdig integrerad del av en verksamhet. Det vi utvecklar är alltid en verksamhetsförmåga som en helhet. Vi kan heller inte outsourca informationssystemen för en viss verksamhetsförmåga. Om vi outsourcar något så måste det alltid vara en verksamhetsförmåga som en helhet. Men om vi gör det så är det fortfarande vår egen verksamhetsfunktion. Det är fortfarande vi som har ansvaret mot kunden. Om vi väljer att se det som någon annans förmåga så är det en förändring av vår identitet, vilka vi är. Och alltså inte en outsourcing utan en transformation till en ny roll i den större verksamheten. Det här är sällan förstått. Det är i min mening den djupa orsaken till den övertro och förenklade syn på outsourcing och därmed följande våg av misslyckade outsourcing-satsningar som vi har sett under de senaste två decennierna.

Roller och personal

Alla verksamhetsförmågor har någon form av bemanning och några former av personroller. Även funktioner som utförs automatiskt och elektroniskt har någon form av bemanning. Det finns ju alltid någon som är ansvarig för att ställa in parametrar och att övervaka utfallet. Det är inte så att en verksamhet försvinner bara för att den automatiseras.

It-applikationer

Nästan alla verksamhetsförmågor har någon form av informationssystem. Idag räcker det som sagt inte att se det som att applikationerna stödjer verksamheten. Vanligen har applikationerna verksamhetslogik inbyggda i sig som gör att vi måste se dessa som integrerade delar av verksamheten, precis som processerna, rollerna och annat.

En it-applikation är inte samma sak som ett it-system.

En it-applikation (it-tillämpning) är per definition ett it-system (eller del därav) som finns till för att stödja en viss verksamhetsfunktion, alltså, som vi vill se den vara en integrerad del av en viss verksamhetsförmåga. Det betyder att för att vara en applikation ska den ha någon form av verksamhetslogik som är specifik för just den förmågan.

Data/information

Data/information hanteras på olika sätt i verksamhetsförmågor. En viss datapunkt kanske uppstår i en viss förmåga, förvaras i en annan, förädlas i en tredje och används i en fjärde. Allt detta behöver vi som informationsarkitekter hålla reda på. Vi kan kalla det datalogistik. Flera artiklar längre fram kommer att handla om hur vi med hjälp av en förmågekarta kan analysera och hantera datalogistiken i vår verksamhet.

Metamodell

Nu har vi i text steg för steg, med hjälp av ett enkelt illustrerat exempel, byggt upp en metamodell av hur allt detta hänger ihop. Om vi vill kan vi presentera denna metamodell i ett ER-diagram enligt nedan. Färgerna i ER-diagrammet överensstämmer med färgerna i exemplet i artikeln.

Vad tror du?

Tycker du som jag, att det synsätt jag här presenterar kan vara en grund för hur vi kan analysera och strukturera våra verksamheter? Vad kan du använda? Vad har jag missat?

Hur jag tar detta vidare?

Hur kan en förmågekarta som är användbar för att analysera, beskriva och hantera datalogistiken, i en verksamhet se ut? Och hur tar man fram en sådan? Detta blir ämnen för fem kommande artiklar.

/Peter Tallungs

Välkommen att maila mig på peter.tallungs(at)irm.se eller kommentera artikelns post på IRM:s linkedin.

Vill du prenumerera på denna artikelserie? Det innebär att du får ett nyhetsbrev, samtidigt som vi publicerar en ny artikel i ämnet informationsarkitektur, med länk till den senaste artikeln. Skriv ett mail till info@irm.se med namn och e-postadress. Skriv IA-artikelserie i ämnesraden.