Gedurende een groot deel van de afgelopen twee decennia werd enterprise-architectuur beoefend van de technologie omhoog. Teams inventariseerden applicaties, brachten integraties in kaart, rationaliseerden infrastructuur en produceerden roadmaps waarvan de logica intern aan de IT was. Dit werkte zolang de voornaamste beperking van een onderneming de kosten en complexiteit van haar systemen was. Voor de meeste organisaties is dat niet langer de bindende beperking. De beperking is nu de snelheid en samenhang waarmee een onderneming kan herconfigureren wat zij doet: een aangrenzende markt betreden, een overname absorberen, aan een nieuwe regelgeving voldoen, of een machine-learningcapability inpassen in een bestaande dienst zonder de drie andere te breken die daaraan raken.

Dit zijn in eerste instantie geen technologievragen. Het zijn vragen over capabilities: welke de organisatie heeft, welke zij mist, welke gedupliceerd zijn over divisies die elk menen uniek te zijn, en welke stilzwijgend dragend zijn voor veel meer van de onderneming dan iemand beseft. Een organisatie die haar capabilities niet kan benoemen, kan over niets hiervan redeneren. Zij valt terug op het organigram, dat beschrijft wie aan wie rapporteert maar niets zegt over wat de onderneming kan, en op de projectportefeuille, die beschrijft wat er wordt veranderd maar niet datgene wat wordt veranderd.

De reden dat business-architectuur er nu, specifiek, toe doet, is dat het tempo van de gevraagde verandering het stilzwijgende begrip is voorbijgestreefd dat een organisatie vroeger bijeenhield. Toen een onderneming langzaam veranderde, leefde de kaart afdoende in de hoofden van enkele mensen met een lang dienstverband. Wanneer zij voortdurend verandert, wordt die stilzwijgende kaart een last: zij is inconsistent tussen afdelingen, zij is onzichtbaar voor nieuwkomers, en zij kan niet worden geïnspecteerd voordat een besluit wordt genomen. Business-architectuur externaliseert die kaart en maakt haar tot een gedeeld, duurzaam bezit. Het is het verschil tussen een onderneming die zichzelf kan zien en een die slechts in het donker kan rondtasten.

Het fundamentele construct van business-architectuur is de capability: een stabiele beschrijving van iets wat de organisatie kan, uitgedrukt als een zelfstandig naamwoord in plaats van een werkwoord. Acceptatie, prijsstelling, orderafhandeling, klant-onboarding, vraagvoorspelling. Een capability abstraheert bewust van hoe zij wordt uitgevoerd, wie haar uitvoert, of welk systeem haar ondersteunt. Die abstractie is precies het punt. Processen veranderen voortdurend, organisatiestructuren worden om de paar jaar herschikt, applicaties worden vervangen, maar het feit dat een verzekeraar risico moet kunnen accepteren, blijft door dit alles heen bestaan. Omdat capabilities stabiel zijn, vormen zij een coördinatenstelsel waartegen alles wat vluchtig is, kan worden geplaatst.

Capabilities worden georganiseerd in een capability map: een gestructureerde, doorgaans twee- of drielaagse decompositie van alles wat de onderneming kan, geordend naar wat de capability is in plaats van naar wie haar bezit. Een goede kaart is op elk niveau wederzijds uitsluitend en gezamenlijk uitputtend, en spiegelt nadrukkelijk niet het organigram. Als twee divisies beide klanten onboarden, dan is dat één capability die op twee plaatsen wordt uitgeoefend, niet twee capabilities. Dat ene feit aan het licht brengen is vaak de gehele in-kaart-brengoefening waard.

Waar capabilities een statisch vermogen beschrijven, beschrijven waardestromen hoe waarde daadwerkelijk end-to-end aan een belanghebbende wordt geleverd, van een aanleidende gebeurtenis tot een gerealiseerd resultaat. Een waardestroom loopt horizontaal dwars door de organisatie en doet in volgorde een beroep op vele capabilities. De twee constructen zijn complementair en samen dragend: de waardestroom vertelt u de reis en de belanghebbendewaarde die op het spel staat, de capability map vertelt u wat goed moet zijn opdat die reis slaagt. Onder waardestromen liggen bedrijfsprocessen, de concrete, geordende, meetbare reeksen van activiteit die een capability in een bepaalde context realiseren. Business-architectuur werkt op de hoogte van capability en waardestroom en verbindt zich weloverwogen omlaag naar het proces, in plaats van van meet af aan in procesdetail te verdrinken.

Het laatste grondbeginsel is verankering. Elk ander architectuurdomein hecht zich aan het capability-model. Applicaties worden gekoppeld aan de capabilities die zij ondersteunen, data-entiteiten aan de capabilities die ze bezitten, initiatieven en kosten aan de capabilities die zij veranderen. Dit is wat een verzameling losstaande modellen tot een enterprise-architectuur maakt: een gemeenschappelijke ruggengraat waaraan al het andere refereert.

Drie ontwikkelingen hervormen de manier waarop business-architectuur wordt beoefend. De eerste is de verschuiving van documentatie naar besluitondersteuning. Jarenlang was de zichtbare output van het vakgebied een reeks diagrammen die weinigen raadpleegden na de workshop die ze had voortgebracht. De huidige verwachting is dat het capability-model een levend instrument is dat wordt gebruikt om terugkerende vragen te beantwoorden: waarin moeten wij investeren, wat dupliceert deze overname, welke capabilities dragen het meeste risico. Het model verdient zijn plaats door bevraagd te worden, niet door bewonderd te worden.

De tweede ontwikkeling is de opkomst van de capability-gebaseerde investeringslens. In plaats van projecten te financieren en te hopen dat de portefeuille optelt tot de strategie, wijst een groeiend aantal organisaties uitgaven toe aan capabilities en volgt deze. Dit maakt een ongemakkelijke maar nuttige vraag beantwoordbaar: investeren wij daadwerkelijk in de capabilities waarvan de strategie zegt dat zij onderscheidend zijn, of pompen wij uit gewoonte en organisatorische zwaartekracht geld in commodity-capabilities. De capability heat map, waarop wij hieronder terugkomen, is het primaire artefact van deze lens.

De derde ontwikkeling is de druk die kunstmatige intelligentie en alomtegenwoordige automatisering op de businesslaag leggen. Wanneer een capability opeens door een model in plaats van een team kan worden uitgevoerd, heeft de organisatie een stabiel kader nodig om over de verandering te redeneren: welke capability wordt geraakt, in welke waardestroom zij zit, van welke informatie zij afhankelijk is, welke stroomafwaartse capabilities haar huidige gedrag veronderstellen. Ondernemingen die een capability-model missen, adopteren deze technologieën doorgaans proces voor proces, waarbij zij lokale optimalisaties opstapelen die niet samenkomen. Wie een model heeft, kan de capabilities richten waar automatisering de strategie werkelijk vooruithelpt en de reikwijdte van de impact begrijpen voordat er wordt gecommitteerd.

Onder alle drie ligt een stillere rijping: van business-architectuur wordt steeds meer verwacht dat zij zich verbindt met strategievorming aan de ene kant en met portefeuille-uitvoering aan de andere, in plaats van als een op zichzelf staande modelleerpraktijk te blijven bestaan. De waarde zit in de koppeling, en het vakgebied wordt beoordeeld op hoe goed die koppeling standhoudt.

Een capability map is eenvoudig te tekenen en moeilijk goed te tekenen, en het verschil is vrijwel geheel een kwestie van discipline in het toepassen van enkele principes. Het eerste is stabiliteit. Capabilities moeten zo worden gedefinieerd dat zij een reorganisatie en een herplatforming overleven. Als een capability-naam een afdeling, een systeem, een kanaal of een werkwoordsvorm bevat, is zij op de verkeerde hoogte getekend en zal zij binnen een jaar vervallen. De toets is eenvoudig: kan deze uitspraak waar blijven na de volgende reorganisatie. Zo niet, herschrijf haar.

Het tweede principe is een zuivere scheiding van wat en hoe. De capability map stelt vast wat de onderneming kan. Waardestromen en processen stellen vast hoe het wordt gedaan. Het vervagen van beide levert een kaart op die in werkelijkheid een vermomde procesinventaris is, die instabiel, enorm en nutteloos is voor investeringsgesprekken. De lijn hier vasthouden is de meest voorkomende bepalende factor voor de vraag of een model standhoudt.

Het derde principe is dat de kaart niet de organisatie mag spiegelen. Capabilities structureren naar divisie garandeert dat duplicatie verborgen blijft en dat capabilities die overal doorheen snijden, gefragmenteerd raken. Een capability-model dat is georganiseerd naar intrinsieke aard plaatst een capability eenmaal en onthult vervolgens, via het in kaart brengen, overal waar zij wordt uitgeoefend. Het ongemak dat dit teweegbrengt, is diagnostisch, geen gebrek.

Het vierde principe is gelaagd detail met weloverwogen stoppunten. Decomponeer slechts zover als de besluiten vereisen. De meeste redenering op ondernemingsniveau is gebaat bij twee of drie niveaus; verder afdalen is alleen passend waar een specifiek besluit dat verlangt. Een model dat overal uniform tot het vijfde niveau decomponeert, is een model dat nooit zal worden onderhouden.

Het vijfde principe is dat het model bestaat om oordeel te dragen, niet slechts structuur. Een capability map wordt een heat map wanneer elke capability wordt beoordeeld op dimensies die er voor de strategie toe doen: huidige volwassenheid tegenover vereiste volwassenheid, strategisch belang, kosten, risico en de mate van gevraagde verandering. Het is het overlaggen van oordeel op stabiele structuur dat een taxonomie in een besluitinstrument verandert. Dit is ook waar het target operating model aansluit: het target operating model is in feite een verklaring van de toekomstige configuratie van capabilities, waardestromen, organisatie en informatie, en de heat map is de gap-analyse die het bewegen daarnaartoe rechtvaardigt.

De faalvormen van dit vakgebied zijn welbekend en grotendeels vermijdbaar zodra zij zijn benoemd. Het behangmodel is de meest voorkomende: een uitgebreide, prachtig weergegeven capability map wordt in een project geproduceerd, eenmaal gepresenteerd, en nooit gebruikt om een besluit te nemen. Zij faalt niet omdat zij verkeerd is maar omdat zij is gebouwd als een deliverable in plaats van een instrument. Als geen terugkerend besluit van het model afhangt, zal het niet worden onderhouden, en een niet-onderhouden model is erger dan geen, omdat mensen erop vertrouwen terwijl het stilletjes wegrot.

Het vermomde organigram is de tweede: de kaart is gestructureerd rond afdelingen, dus zij bevestigt de bestaande structuur, verbergt elke duplicatie, en leert de organisatie niets wat zij niet al geloofde. Zij voelt comfortabel in de workshop en is voor altijd daarna inert.

De oceaan willen koken is de derde: het team probeert elke capability tot een uniforme diepte te decomponeren en elke applicatie, elk proces en elke data-entiteit in kaart te brengen voordat er enige waarde wordt geleverd. De inspanning bezwijkt onder haar eigen gewicht, meestal net voordat zij nuttig zou zijn geworden. Business-architectuur moet van buiten naar binnen worden gebouwd vanuit de besluiten die om beantwoording vragen, niet van onderop vanuit een drang naar volledigheid.

Proces dat zich voordoet als capability is de vierde en meest technische: werkwoorden sluipen de kaart binnen, de hoogte glijdt weg, en het capability-model wordt een instabiele procesinventaris die bij de volgende reorganisatie breekt. Dit is de faalvorm die stilletjes de kernbelofte van stabiliteit van het model ondermijnt.

Eigenaarloze artefacten is de vijfde: het model heeft geen verantwoordelijke business-eigenaar, dus zijn beoordelingen worden nooit ververst, zijn koppelingen met de applicatie- en initiatiefportefeuilles raken achterhaald, en binnen achttien maanden beschrijft het een onderneming die niet meer bestaat. De gemeenschappelijke draad door alle vijf heen is dezelfde: een business-architectuur die wordt behandeld als een document in plaats van als een bestuurd, levend onderdeel van hoe de organisatie over zichzelf redeneert. De remedie is nooit een beter tekenprogramma. Het is eigenaarschap, verbinding met echte besluiten, en de discipline om slechts zoveel te modelleren als die besluiten vereisen.

Nashua benadert business-architectuur als een instrument dat wordt besteld, niet als een document dat wordt opgeleverd. De opdracht begint bij de besluiten die de organisatie daadwerkelijk moet nemen: een transformatie te rechtvaardigen, een overname te integreren, een portefeuille te rationaliseren, een target operating model te ontwerpen. Wij werken vanuit die besluiten terug naar het minimaal levensvatbare capability-model dat ze kan informeren, in plaats van vanuit een blanco taxonomie vooruit naar theoretische volledigheid. Dit houdt de inspanning proportioneel en zorgt ervoor dat het model een taak heeft op de dag dat het af is.

Wij bouwen de capability map met het bedrijf, niet voor het bedrijf. De kaart die standhoudt, is die waarvan de definities zijn uitgevochten en overeengekomen door de mensen die verantwoordelijk zijn voor de capabilities, want hun eigenaarschap is wat haar daarna in leven houdt. Onze architecten brengen de structureerdiscipline: de lijn vasthouden tussen wat en hoe, de kaart van het organigram af houden, capabilities tekenen op een hoogte die een reorganisatie overleeft, en de decompositie stoppen waar de besluiten stoppen. Vervolgens leggen wij oordeel over: wij beoordelen volwassenheid, belang, kosten en risico om een heat map te produceren die eerlijk laat zien waar het vermogen van de organisatie en haar ambitie uiteenlopen.

Van daaruit verankeren wij de rest van het landschap aan het model. Applicaties, informatie en initiatieven worden gekoppeld aan de capabilities die zij ondersteunen, zodat de businesslaag de ruggengraat wordt die de strategie aan de ene kant verbindt met de applicatie-, data- en technologie-architectuur aan de andere. Dit is waar een target operating model ophoudt een dia te zijn en een traceerbaar ontwerp wordt: een toekomstige configuratie van capabilities en waardestromen, met een verdedigbaar pad vanuit de huidige toestand. Gedurende het geheel staan wij op de twee dingen die bepalen of hiervan iets het contact met de organisatie overleeft: een verantwoordelijke business-eigenaar voor het model, en een klein aantal levende besluiten die het in gebruik houden. Wij leveren liever een kleiner model dat wordt bestuurd en geraadpleegd dan een volledig model dat behang wordt.

Het verschil dat Nashua brengt, is geen eigen notatie of een dikkere deliverable. Het is het erop staan dat business-architectuur verbonden blijft: met de strategie erboven, met de applicatie-, data- en technologiedomeinen eronder, en met de echte investerings- en veranderbesluiten die haar omringen. Een capability-model dat in isolatie leeft, is een academische oefening. Een capability-model dat is ingebed in hoe een organisatie haar verandering besluit, financiert en bestuurt, is een duurzaam strategisch bezit, en het bouwen van het tweede soort in plaats van het eerste is waar onze praktijk haar inspanning op concentreert.

Er is ook een praktisch uitvloeisel dat verandert wat het werk mag veronderstellen. Wanneer een opdracht vraagt om een capability die nog niet bestaat, hoeft die niet te wachten op een inkoopcyclus of op de roadmap van een leverancier. Het Nashua 360 Enterprise Platform is gebouwd om vrijwel elke functie in hoog tempo te accommoderen, door middel van extreme vibe coding: wat nodig is, wordt in gewone taal beschreven en snel gegenereerd, maar altijd binnen vaste architectuurprincipes en onder strikte kwaliteitsborging, zodat snelheid nooit ten koste gaat van samenhang, beveiliging of controle. Het effect is strategisch in plaats van louter gemakkelijk. Het verschuift de make-or-buy-grens, houdt optionaliteit goedkoop, en laat de architectuur de strategie volgen in plaats van dat de strategie zich buigt naar wat toevallig op de plank lag.

Wat dit een organisatie oplevert, is een bedrijf dat zichzelf helder genoeg kan zien om zichzelf weloverwogen te veranderen. Duplicatie wordt zichtbaar en daarmee aanpakbaar. Investeringen kunnen worden getoetst aan de capabilities waarvan de strategie zegt dat zij onderscheidend zijn. Een overname kan worden beoordeeld op wat zij werkelijk toevoegt in plaats van op wat zij dupliceert. Een target operating model kan worden ontworpen met een traceerbare lijn terug naar de capabilities die het hervormt. Niets hiervan vereist dat de organisatie een nieuw vocabulaire adopteert of vertrouwt op een model dat zij niet heeft helpen bouwen. Het vereist alleen dat de businesslaag wordt behandeld voor wat zij is: het anker van de gehele architectuur, en het punt waarop de strategie ofwel aansluit op de uitvoering ofwel stilletjes faalt. De rol van Nashua is die verbinding te maken en te behouden, en niet een diagram achter te laten maar een instrument dat de organisatie nog lang na ons vertrek blijft gebruiken.