Composable architectuur: hoe wendbaar is haalbaar?

De overstap naar een composable architectuur is alleen te realiseren als de hele organisatie zich bewust is van de 'drie schillen' in IT-systemen. Deze schillen kun je bijna altijd herkennen in volwassen organisaties:

1. De buitenste schil is waar je de customer journey tot leven brengt. De verandersnelheid is hier twee maanden, voor bijvoorbeeld een nieuw scherm in je app of een nieuwe koppeling met je advertentienetwerk.

2. De middelste schil omvat de API’s en middleware waarmee processen binnen en buiten het bedrijf gekoppeld worden. De doorlooptijd voor verandering is hier tien maanden, een effectief werkjaar.

3. Kernsystemen zoals een ERP of een legacy applicatie zitten in de binnenste schil, waar echte verandering eerder vijftig maanden duurt.

Deze 2-10-50-regel staat ook bekend als Core vs. Edge, en die duidt hoe snel je daadwerkelijk kunt overstappen naar een composable architectuur.

Wil je volgend jaar je ERP- of CRM-systeem composable maken? Zorg dan wel dat ambitie en realiteit met elkaar in verhouding staan. Als organisatie bepalen je kernsystemen hoe je businessprocessen opgezet worden. Alleen wanneer je een hoge marktdynamiek bedient – zoals een logistieke provider voor webshops bijvoorbeeld – loont het om deze kernprocessen composable te maken. Bedrijven in een stabiele markt zoals levensverzekeringen halen meer profijt met composable in de middelste of buitenste schil, bijvoorbeeld voor het koppelen van een nieuw verkoopkanaal of het bieden van extra betaalmogelijkheden. Zet je de tijdsverwachting echter van de ene schil op de andere schil, dan is composable gedoemd te mislukken.

De drie processen die tech teams nodig hebben

Heb je helder welke verwachtingen passen bij welk onderdeel van je IT-landschap? Kijk dan vervolgens naar de manier waarop de IT-organisatie werkt. Er zijn drie processen vereist voor tech teams om effectief composable te kunnen toepassen:

• True Iterative Development als default: MVP’s ontwikkelen en snel kunnen releasen moeten een tweede natuur zijn. Dat kan alleen middels Kanban of agile werken, (merciless) automation en rapid deployment: met een druk op de knop kunnen migreren naar productie. Deze skills horen bij de buitenste schil waar je snel en snappy veranderingen wilt kunnen aanbrengen. Dit speelt minder bij de middelste schil, want hier heb je een informatieplicht naar externe partijen. Je bent hier ook afhankelijk van de schakelsnelheid van anderen: afhankelijke bedrijfsonderdelen die je API's gebruiken maar een eigen roadmap voeren.

• Gebruik collaboration tools: zorg ervoor dat teams elkaars werkwijzen en releases begrijpen zodat ze optimaal kunnen samenwerken. Door open standaarden en tooling te gebruiken voor workflows, wallboards en API’s, houd je overzicht en blijft de communicatie soepel verlopen. Belangrijk is dat er ook owners zijn die het gebruik faciliteren en bewaken.

• Ontwikkel je integration capabilities: als organisatie moet je niet alleen weten hoe je systemen integreert, maar ook hoe je de data uit die systemen samenbrengt. Knip je een systeem op in meerdere componenten – zogeheten packaged business capabilities (PBC’s) – dan heeft dat directe gevolgen voor je 360-graden-klantbeeld en de analytics van de customer journey. Kennis hebben en het toepassen van data mesh-achtige architecturen worden dan super belangrijk.

Deze drie processen hebben het agile werken met duidelijke teamverantwoordelijkheden per 'component' als basis. Ben je als organisatie nog niet zover met agile, dan kun je geen goede invulling geven aan composable. Agile en composable vormen de hoofdingrediënten om als grote organisatie met complexe processen flexibel te kunnen bewegen.

De vier echte voordelen van composable
Voldoe je aan bovenstaande voorwaarden, dan kun je de echte voordelen van composable plukken zoals Monika Sinha, VP Analyst bij Gartner, die uit de doeken doet in het rapport 2023 CIO Agenda:

1. Meer flexibiliteit omdat je een systeem opsplitst in of samenstelt uit componenten. Die kun je vervolgens gemakkelijker onderhouden en vervangen.

2. Betere 'discoverability’ van wat er allemaal kan doordat de business capabilities niet meer verstopt zitten in een groot systeem. Iedereen kan de componenten doorgronden en vervolgens toepassen. Dat helpt shadow IT te voorkomen, bijvoorbeeld in de vorm van hetzelfde soort maatwerk voor verschillende systemen, zoals een eigen notificatiesysteem voor een ERP-pakket en voor een HRM-pakket.

3. Betere ‘adaptability’ door ‘orchestration’ omdat je op verschillende manieren hetzelfde kunt bereiken. Door je processen anders te linken kun je onderscheidende diensten en klantervaringen creëren.

4. Meer autonomie op je platform voor teams die in een ander tempo zitten. Developers beheren hun eigen componenten waardoor ze onafhankelijk en dus sneller kunnen werken.

Evolutie, geen revolutie
Overstappen naar composable zorgt voor meer snelheid en wendbaarheid, maar niet overal in gelijke mate. Breng je de verandersnelheid van je kernprocessen terug van vijftig naar bijvoorbeeld vierentwintig maanden, dan is dat al een flinke versnelling. Het gaat alleen niet zo supersnel als bij de processen waarmee je de customer journey vormt. De vaste heartbeats die de verschillende verandersnelheden aangeven zullen versnellen en geleidelijk aan verdwijnen. Standaard release momenten, afstemmomenten en boekjaren bepalen dan minder het ritme. Dat maakt de weg vrij voor een adaptive strategy: gedurende het jaar je strategie als C-level kunnen bijstellen. Daarmee verandert ook de traditionele visie op IT als kostenpost naar IT als business driver. Zo ontstaat er een high trust culture waarbij teams meer verantwoordelijkheid krijgen over hun componenten. De focus verschuift van een release kalender naar samen mooie dingen doen.