I denna artikelserie i sju delar får du lära mer om varför organisationer som vill överleva behöver sträva mot Business Agility, och vilka delar (kärnförmågor) som ingår. Del 7, denna del, fokuserar på arkitektur och teknik.

Arkitektur och teknik i förhållande till Business agility

Verksamhet och IT är idag två sidor av samma mynt. Både affärsutveckling och IT-utveckling handlar om att lösa affärs- och verksamhetsbehov, vilket åstadkoms genom teknik och förändringar av beteenden och processer (ofta i kombination). I utvecklingsarbetet uppstår en arkitektur, oavsett om den är medveten eller inte. Arkitekturens uppbyggnad är avgörande för företagets möjligheter att på ett agilt sätt möta de affärs- och verksamhetsbehov som uppstår löpande.

En verksamhet som vill bli mer agil strävar efter att kunna realisera förändringar mer frekvent och i mindre portioner. Varje realisering blir då mindre riskabel och värde kan levereras oftare och närmare i tid till att det faktiska behovet uppstod. Om arkitekturen sätter alltför stora begränsningar för korta utvecklingscykler så kan övergången till en mer agil leveransform bli svår att genomföra.

Arkitektur och teknik som möjliggörare för Business Agility

En arkitektur som stödjer agilt arbete är uppbyggd på ett sätt som gör det enkelt att kontinuerligt införa förändringar inom ramen för sin systemmiljö för att snabbt kunna möta affärsbehoven. Det är en förutsättning för korta, agila utvecklingscykler där affärsvärde levereras löpande. Med dagens föränderliga teknik finns det dessutom ingen arkitektur som håller måtten i evig tid. Nya behov och teknikdrivna möjligheter kräver ständigt underhåll och förändring av arkitekturen.

Slutsatsen av detta är att en modern arkitektur, som stödjer en agil verksamhet, ska vara byggd för förändring. Ett sätt att göra detta är att bygga modulärt. En modulär arkitektur består av olika komponenter som kan operera relativt oberoende av varandra. Beroenden mellan olika IT-komponenter kommer alltid att finnas, eftersom det är större affärsbehov som ska lösas. Konsten är att minimera beroenden till den grad att de olika komponenterna kan ändras, testas och sättas i produktion separat, utan att lösningen kollapsar.

För att åstadkomma detta krävs mer än att bara dela upp funktionalitet mellan olika komponenter. Det handlar därtill om att renodla komponenterna avseende vilken information och logik de rymmer. Ett vanligt exempel är pris. I en modern arkitektur undviks vanligtvis att sprida ut information och logik kring prishantering och prisberäkningar i olika komponenter. Detta möjliggör att implementera ändringar avseende prishantering utan att det slår mot alltför många komponenter och därmed blir processen för att införa en ändring betydligt mindre komplicerad.

Modern teknik möjliggör automatisering av test och deployment i olika miljöer. En modulär arkitektur gör att sådana verktyg blir enklare att använda. Processer för test och deployment, som annars kan vara oerhört tidskrävande, kan nu genomföras i några få knapptryckningar. Den minskade tidsåtgången gör att testerna kan utföras ofta (i takt med de kontinuerliga förändringar som verksamheten vill göra) och med en mer jämn kvalitet eftersom den mänskliga faktorn spelar en mindre roll.

Arkitekturarbete i agil kontext

Att ta fram en arkitektur som formuleras av ett avskilt team eller anställd med kravet att fungera för hela företaget över en längre tid är idag allt svårare. Ett företag består ofta av många olika delar som kräver specifikt anpassade lösningar, för vilka behoven är föränderliga. De utvecklingsteam som arbetar i de olika delarna av organisationen bör besitta den kompetens som krävs för att beskriva och realisera bra lösningar. Det är viktigt att våga lita på teamens kompetens och förmåga när det kommer till teknikval och låta delar av arkitekturen växa fram.

De lösningar som är specifikt anpassade för en del av verksamheten behöver dock kunna samverka med resten av systemmiljön och eventuellt även i ekosystem av externa aktörer. I en verksamhet som, exempelvis, vill bli mer snabbrörlig är det dessutom viktigt att vara överens om vad det innebär att ”bygga för förändring” (enligt föregående avsnitt). Följaktligen finns det ett värde i att följa vissa grundläggande strategier och principer som säkerställer att arkitekturen inte blir alltför vildvuxen. I arbetet med att sätta gemensamma ramar för arkitekturen är det viktigt att ta input från och förankra med personer med arkitekturkompetens som är aktiva i utvecklingsarbetet som sker runtom i verksamheten.

Det är viktigt att lägga tid på rätt saker. I en komplex verksamhet är det svårt att hitta alla svar och lösningar på förhand. Därför bör förstudier, med försök till att beskriva den önskade arkitekturen, hålla sig till en relativt övergripande nivå. Det som ska utredas är vilka komponenter som är lämpliga att ha med i lösningen, inte exakt hur varje detalj ska lösas. De flesta detaljer är svåra att identifiera på förhand. Detaljer i lösningen fastställs bäst av utvecklingsteamet under utvecklingscyklerna i genomförandet. Det är viktigt att våga testa olika lösningshypoteser för att se vad som fungerar och upptäcka de detaljer som behöver lösas. Annars är det lätt hänt att bli fastlåst i ett specifikt lösningsförslag.

Det är lätt att underskatta arkitekturens och teknikens betydelse för att kunna blir mer agil i sitt utvecklingsarbete. För en organisation som vill bli mer snabbrörlig är det viktigt att inte bara lägga resurser på sådant som ger ett direkt affärsvärde, utan även på så kallade ”möjliggörare”. ”Möjliggörare” är sådant som förbättrar underliggande arkitektur och teknik, vilket gör att ännu större affärsvärde kan levereras ännu snabbare i framtiden.

Sammanfattningsvis utgör sättet en verksamhet arbetar med arkitektur och teknik en grundförutsättning för Business Agility. Utan arkitektur och teknik som möjliggör korta utvecklingscykler så är det svårt för en modern verksamhet att göra förflyttningar mot att bli mer agil. Att arbeta med arkitektur och teknik i en agil kontext kräver ett förhållningssätt som kan skilja sig lite från vissa traditionella synsätt på arkitekturarbete.

Vill du veta mer om Business Agility?

Vill du veta mer om de 6 kärnkompetenser som krävs för att bli Business Agile och hur Forefront hjälper företag med detta?