I den första delen av denna serie artiklar om Business Capabilities presenterade vi ett framväxande och delvis nytt sätt att betrakta och hantera en verksamhet. Ett synsätt där man vill se verksamheten som uppbyggd av ett antal autonoma komponenter som samverkar.
Varje komponent är ett komposit av processer, information, verksamhetsregler, kompetens, it-stöd med mera – en liten komplett verksamhet i sig. På så sätt får vi en komponentmodell för en verksamhet. Genom att betrakta och hantera komplexa system och miljöer som system av rekursivt nedbrytbara och samverkande komponenter kan vi förstå och hantera komplexa system av olika slag.
Det här är inget nytt påhitt egentligen utan helt enkelt det sätt vi människor hanterar komplexitet i alla möjliga sammanhang. Det är bara att vi av någon anledning inte har brukat göra så när det gäller verksamhetsarkitektur.
Synsättet är en utveckling inom verksamhetsarkitektur som vi tror på och gärna vill puffa för. En komponentmodell tjänar många syften, användningen av är så mångfaldig och rik.
Denna artikel försöker beskriva vad en verksamhetskomponent är i generella termer. De bakomliggande tankarna om vad en komponentarkitektur djupast innebär saknas i EA-litteraturen. Som så ofta får vi gå utanför EA-sfären för att hitta inspiration.
Vi har utgått från något av det bästa som skrivits om komponentarkitektur; Doktor Clemens Szyperskis bok ”Component Software – Beyond Object-Oriented Programming” (ISBN 978-0321753021). Boken handlar visserligen om komponenter i programvara, men vi ser de grundläggande principerna som generellt tillämpliga för alla slags ”system”. Vi har här anpassat beskrivningen till verksamhetskomponenter.
Vad är en verksamhetskomponent egentligen?
Man kan beskriva vad en verksamhetskomponent ”är” ur olika aspekter, närmare bestämt vilken roll verksamhetskomponenter fyller.
1. En verksamhetskomponent är en abstraktionsenhet (unit of abstraction)
Den mänskliga hjärnan abstraherar bort detaljer så att de föremål vi betraktar blir enklare att hantera för oss. Abstraherande är nödvändigt för all slags tänkande. Vi behöver goda abstraktioner för att hantera den nödvändiga komplexiteten och för att slippa onödig komplexitet.
En verksamhetskomponent håller samman vad som behöver hållas samman som en enhet i vår syn på en verksamhet och separerar vad som naturligt är separata företeelser.
2. En verksamhetskomponent är en analysenhet (unit of analysis)
En verksamhet är ett komplicerat ekosystem. Ett kraftfullt sätt att försöka förstå en verksamhet är att i tanken bryta ner verksamheten i mindre och mindre delar. Men inte hur som helst utan nedbrytningen bör ske på ett sådant sätt så att kopplingen mellan delarna blir så lös och explicit som möjligt.
Utan en bra gjord nerdelning blir det omöjligt att förstå (analysera) ett komplext system som en verksamhet. Än mindre kan vi planera och konstruera (syntetisera) en ny eller förändrad verksamhetsdel. Arten och graden av koppling mellan verksamhetskomponenterna bestämmer till vilken grad analysen av en komponent måste ta hänsyn till egenskaperna hos andra komponenter.
Om alla delar är intrasslade med alla andra delar blir separat analys av en del omöjlig och en global analys blir den enda möjligheten. Då får vi en mycket svårarbetat och oflexibel verksamhetsarkitektur.
3. En verksamhetskomponent är en enhet att utveckla, förvalta och styra (unit of development, maintenance and management)
Eftersom de inneboende aspekterna av en verksamhetskomponent är tätt sammanvävda är det inte görligt att utveckla en aspekt utan att röra de andra aspekterna. Vi kan inte utveckla it-stödet för en verksamhetskomponent utan att påverka information, verksamhetsregler och processer. Vanligen kan vi inte utveckla processerna utan att påverka it-lösningen eller informationen.
Det minsta objektet för verksamhetsutveckling är sålunda en hel verksamhetskomponent som en helhet. Varje leverans från ett utvecklingsarbete är en förändrad verksamhetskomponent. Ändringen kan vara liten men omfattar normalt fler än en och ofta alla aspekter av en verksamhetskomponent.
4. En verksamhetskomponent är en leveransenhet (unit of independent deployment)
En verksamhetskomponent kan vara föremål för ut- eller inkontraktering. Den är oberoende av andra komponenter så länge gränssnitten för dess verksamhetstjänster fungerar. Men den kan endast ut- eller inkontrakteras som en helhet.
De ingående processerna, informationen, verksamhetsregler, kompetens och it-funktionaliteten har rika och nära beroenden med varandra och kan inte separeras. Om du vill dela ner en verksamhetskomponent måste du hitta de mindre verksamhetskomponenter den består av och hantera var och en av dessa som en helhet.
5. En verksamhetskomponent är en distributionsenhet (unit of locality)
En verksamhetskomponent kan placeras ut geografiskt som en helhet, förutsatt att kompetens och andra resurser finns på plats och tjänsterna fortfarande kan levereras till dess kunder. Men om man försöker sprida människorna i en verksamhetskomponent på två eller flera lokaler kommer man att få betala ett mycket högt pris. Eftersom arbetet inom en komponent är tätt integrerat behöver människorna kommunicera effektivt. Och geografiskt avstånd är en stor hämsko för bandbredden i den mänskliga kommunikationen.
Även it-personal som arbetar med it-lösningen för en verksamhetskomponent behöver ses som verksamhetskompetens och behöver samlokeras med resten av verksamhetsfolket. Det gäller för all it-personal med applikations- och verksamhetsfokus, såväl applikationsutvecklare och applikationsförvaltare som användarstöd och applikationsdrift.
Teknisk drift däremot som server- och plattformsdrift, där specifik verksamhetskunskap inte behövs ser vi mera som infrastrukturtjänster och är inte del av verksamhetskomponenten. Detta levereras av en särskild verksamhetskomponent av infrastrukturtyp.
6. En verksamhetskomponent är en redovisningsenhet (unit of accounting)
Verksamhetskomponenter är naturliga och meningsfulla enheter för uppföljning av kostnader. På så sätt kan kostnader och vinster länkas till vad som verkligen levereras som helhet.
7. En verksamhetskomponent är en enhet att ifrågasätta (unit of dispute)
Förr eller senare fallerar en verksamhet på ett eller annat sätt. Det kan vara kvalitetsproblem, säkerhetsproblem, prestandaproblem eller annat. Med en komponentvy på verksamheten blir det lättare att lokalisera problemet eller delar av problemet till en specifik komponent eller några få samverkande komponenter. Detta underlättar problemanalys och åtgärder.
8. En verksamhetskomponent är en enhet för felisolering (unit of fault containment)
När något går fel ska inte felet propagera tvärs över gränsen till andra verksamhetskomponenter. Normalt ska verksamhetskomponenten upptäcka och åtgärda felet själv. Ingen annan del av verksamheten kan förväntas att ha detaljkunskapen att hantera felet
Mer på djupet
En person som lyft fram komponentperspektivet inom verksamhetsarkitektur är Roger Session med boken ”Simple Architectures for Complex Enterprises” (ISBN 978–0735625785). Det är en bok som går på djupet med att motivera de viktigaste påståendena om en verksamhetskomponent, nämligen 1, 2 och 3 ovan.
"Vi är glada för den rika respons vi har fått från läsarna under sommaren och hoppas att det är fler som vill diskutera och kommentera vad ett komponentperspektiv på en verksamhet betyder. I nästa avsnitt, det sista i serien, blir vi lite mer konkreta. Vi ger exempel på hur komponentperspektivet kan ge oss nya infallsvinklar för att lösa upp några av de kanske svåraste knutarna inom vårt yrkesområde".