Den komponentbaserade systemmiljön

En central trend inom digitaliseringen har under många år varit övergången från stora monolitiska system till mindre komponenter. En av de mest drivande faktorerna är att få till den flexibilitet som krävs i en alltmer snabbföränderlig värld. Det innebär även fördelar som t.ex.

• bättre möjlighet att anpassa lösning efter behov
• snabbare implementationstakt
• lägre inlåsning och risk

Gartner rapporterade 2020 om en framtid där företag som lyckas bli mer komponentbaserade (Composable Enterprise) kommer vinna fördelar på marknaden. Det handlar om att återta kontrollen över att kunna förändra de applikationer man har i sin verksamhet. Man behöver skaffa sig handlingsfrihet och det kräver flexibilitet i systemmiljön. Vägen dit börjar med skiftet från monolitiska applikationer till förmån för en systemmiljö som är mer modulär och anpassningsbar efter verksamhetens ständiga förändringar.

I den här artikeln ska vi reda ut de viktigaste begreppen att behärska för att ta kontroll över sin systemmiljö.

Vad är Best of Breed?

Best of Breed innebär att välja olika system för olika områden och funktioner i verksamheten, för att på så sätt få bästa möjliga effekt av respektive system. Detta i kontrast till det traditionella monolitiska affärssystemet vars målsättning är att lösa alla funktioner på ett helintegrerat sätt.

Vad är Microservices?

Microservices är ett buzzword som använts flitigt senaste åren. Det har också fått vara med på flera listor över de mest felanvända begreppen inom IT. Så vad är det egentligen?

Microservices är en arkitektur där lösningen byggs upp av flera små och löst kopplade tjänster. Varje microservice har ett tydligt gränssnitt (API) som möjliggör för andra microservices eller applikationer att kommunicera med den. Det finns likheter med Service Oriented Architecture (SOA) och microservices beskrivs ibland som “SOA done right”.

Det finns inte en enhetlig definition av vad en microservice är, men oftast pratar man om att de ska vara:

• Små
• Autonoma
• Organiserade utifrån verksamheten
• Teknikoberoende
• Oberoende uppdateringar (deployment)

Vad är Packaged Business Capabilities (PBC:s)?

Medan Best of Breed-konceptet bygger på relativt stora komponenter och microservices bygger på väldigt små erbjuder Packaged Business Capabilities (PBC:s) en medelväg.

Gartner definierar en PBC som en mjukvarukomponent med en väl avgränsad affärsfunktionalitet (business capability). Denna kan både vara egenutvecklad eller inköpt av en leverantör. En PBC är alltså större än en microservice, och kan i praktiken vara uppbyggd av flera olika microservices.

Genom att kombinera olika PBC:er kan man skapa det som Gartner kallar för Composable Applications. Alltså en applikation som kombinerar förmågor från olika PBC:er till en applikation som användaren kan konsumera.

Hur ska man tänka?

Att tiden för den monolitiska arkitekturen är över är de flesta överens om. Däremot sitter många företag kvar med ett eller flera monolitiska legacy-system, och vägen därifrån kan kännas lång.

Att direkt överge befintliga system för sakens skull är sannolikt en dyr och dålig väg att gå. Det viktiga är att göra medvetna val med en avvägd långsiktighet. Att investera i ett nytt monolitiskt system bör exempelvis ske med en stark tro att just den delen av verksamheten ser likadan ut i överskådlig framtid (och är det någonsin så?). Sannolikt gör man klokt i att kontinuerligt göra val mot en mer komponentbaserad systemmiljö.

Vilken storlek på komponenter är rätt?

Vilken storlek på komponenterna som är rätt beror på hur behovet ser ut. Att välja en renodlad strategi enligt Best of Breed, PBC:s eller microservices är i de flesta fall varken önskvärt eller praktiskt möjligt.

• En renodlad Best of Breed-strategi kan fungera i de flesta fall, men enligt Gartner m.fl. kommer det traditionella SaaS-bolaget i framtiden bli omsprunget av produktbolag som paketerar sina tjänster som PBC:s. 
• En renodlad PBC-strategi är för det första inte möjlig i dagsläget, eftersom utbudet är för litet. Därför skulle alltför stor egen utvecklingskostnad krävas för att åstadkomma det önskvärda resultatet. För det andra finns det ofta fall där ett klassiskt, lite större, system uppfyller behovet på bästa sätt.
• En renodlad Microservices-arkitektur är bara aktuell när man själv utvecklar mjukvaran. Detta bör endast göras för områden där tillräckligt bra system saknas eller där man ser möjligheter att skapa konkurrensfördelar genom ett egenutvecklat system.

En annan faktor att ha med i beräkningarna är licenskostnaden för de system/komponenter man köper. Generellt sett medför flera och mindre komponenter en högre kostnad än ett monolitiskt system.

Istället för en renodlad strategi gör man därför klokt i att fokusera på vart en hög grad av flexibilitet behövs, och vart den inte gör det. Därefter välja en strategi där det finns komponenter av olika storlek som samverkar med varandra.

Organisation och system påverkar varandra

Det centrala i en komponent-baserad strategi är att skapa en systemmiljö som speglar hur verksamheten ser ut, samtidigt som den möjliggör snabba förändringar i densamma. 

Conway’s Law säger också att en organisation kommer att designa system som speglar organisationsstrukturen. På så sätt byggs också organisationsstrukturen in i systemet. Ett monolitiskt system, med många interna beroenden mellan funktionerna, kommer bidra till en mer monolitisk organisation.

Bara om man känner sig helt trygg med att inte behöva ändra så mycket alls i verksamheten kan man helt bortse från en komponentbaserad strategi. För oss andra som vill både växa vår verksamhet och vara redo att möta förändrade kundbehov handlar det istället om att välja takten med vilken vi ger oss i kast med att skapa flexibilitet genom mindre komponenter.