Misverstanden rondom business architectuur

Business architectuur wordt al lang genoemd als één van de ‘domeinen’ van architectuur. In de meeste architectuurraamwerken (uitgezonderd het Zachman-raamwerk, dat een ander soort indeling hanteert) komt het voor. Het lijkt dus een geaccepteerd vakgebied, met een zelfde status als andere architectuurdomeinen. De praktijk is echter anders. Enkele misverstanden zijn hiervoor mede verantwoordelijk.Veel organisaties zijn tegenwoordig bezig met een variant van informatiearchitectuur of technische architectuur. Business architectuur komt echter minder vaak voor. Zoek bijvoorbeeld naar de verschillen op wervingssites: een snelle zoekopdracht naar aanvragen voor een ‘architect’ gaf me:

• 1 business architect
• 7 data-architecten
• 10 infra-architecten
• 13 solution-architecten

Of zoek naar gespecialiseerde architectuurgroepen op LinkedIn: de ‘IASA: The Global IT Architect Association’, een van de grotere LinkedIn-groepen op het gebied van IT-architectuur, heeft bijvoorbeeld zo’n 45.000 leden.  De ‘Business Architecture Community’? ‘Slechts’ ±8.000 .

In mijn werk merk ik dan ook nog veel misverstanden over wat business architectuur eigenlijk inhoudt. Deze worden zelden uitgesproken, maar blijven impliciet tot ze uitgedaagd worden. Gelukkig deelt lang niet iedereen deze misverstanden, maar toch zie ik ze met al te grote regelmaat terug in mijn dagelijkse praktijk. Graag stip ik er een paar aan.

Business architectuur == enterprise architectuur

Een eerste misverstand dat ik tegenkom is het beeld dat business architectuur en enterprise architectuur hetzelfde zijn. Dit zie je vaak terug in de rolverdeling in architectuurteams: naast enkele informatie- en applicatiearchitecten is er dan één ‘enterprise architect’. Voor deze architect wordt een veel zwaarder gewicht gelegd op communicatieve en politieke vaardigheden (alsof deze niet belangrijk zijn voor andere architectuurrollen…). Deze architect is vaak de ‘leider’ van het architectuurteam. Hij of zij bewaakt het proces, rapporteert aan de directie en ‘praat met de business’.

Het misverstand zit in het op één hoop vegen van verschillende dimensies. Business architectuur is een ‘architectuurdomein’. Het bevindt zich daarmee op dezelfde dimensie als informatiearchitectuur en technische architectuur. Deze dimensie onderscheidt welke onderwerpen onder de loep worden genomen in de architectuur. Denk bijvoorbeeld aan processen, verantwoordelijkheden, applicaties, gegevensstromen, netwerken, etc.

Enterprise architectuur bevindt zich daarentegen op twee verschillende dimensies:

• Detailniveau; dit bepaalt in hoeveel detail een architectuur wordt uitgewerkt. Abstractieniveau is een andere term die hierop past. In deze dimensie is enterprise architectuur gericht op de meer abstractere, niet-specifieke kaders. Deze kunnen vervolgens in projectarchitecturen, capability architectures, systeemarchitecturen etc. nader worden uitgewerkt.
• Organisatiescope, oftewel: welke onderdelen van de organisatie worden in de architectuur behandeld. Wordt bijvoorbeeld een architectuur uitgewerkt voor een specifieke business unit, een specifieke bedrijfsfunctie, of voor de organisatie als geheel? In deze dimensie is enterprise architectuur meestal gericht op de organisatiebrede architectuur. In sterk gediversificeerde holdings focust het zich ook wel op een business unit.

Deze twee dimensies hangen om praktische redenen sterk samen. Een organisatiebrede architectuur blijft over het algemeen op een hoger abstractieniveau. Een detailarchitectuur opstellen is immers tijdrovend en, uitzonderingen daar gelaten, het is moeilijk om organisatiebreed geldende architectuurkaders uit te werken tot een zeer gedetailleerd niveau. Wel is het natuurlijk mogelijk om een ‘enterprise business architectuur’ te hebben, net als een ‘enterprise IT architectuur’, aangezien de dimensies elkaar deels overlappen. Maar business architectuur is dus niet hetzelfde als enterprise architectuur.

Business architectuur heeft als doel business-IT alignment

Nauw samenhangend met het vorige misverstand is de vaak impliciete aanname dat business-IT alignment het doel is van business architectuur. Natuurlijk is het mooi als je business-IT alignment kan bereiken met behulp van business architectuur. Het kan hier ook zeker een bijdrage aan leveren, bijvoorbeeld door duidelijk te maken welke bedrijfsfunctie of –proces een IT-systeem ondersteunt en wat de beste manier is om dit te doen.

Maar de overmatige focus op business-IT alignment versterkt het beeld dat architectuur ‘voor de IT is’ alleen maar. Het suggereert namelijk dat je zelfs de business-aspecten van de architectuur vooral in kaart brengt voor een beter begrip van IT. Er wordt daarmee een ander belangrijk doel over het hoofd gezien: de inrichting en opzet van de organisatie zelf, los van de IT. Zo kan business architectuur ingaan op de opzet van processen, de (semantische) definitie van gegevens, de wijze waarop klanten worden benaderd, de omgangsvormen en cultuur in een organisatie, etc.

Een voorbeeld: bij een van mijn vorige klanten had ik de verantwoordelijkheid om een architectuur uit te werken voor de IT-ondersteuning van een product dat nog in de kinderschoenen stond. Gaandeweg het traject werd duidelijk dat de betrokkenen vooral geholpen werden door een samenvatting van hun waardepropositie en een vertaling hiervan naar de ondersteunende processen benodigd om deze te kunnen leveren. Dit stond hen toe om hun aanbod aan te scherpen en gaten in ondersteunende processen op te (laten) vullen. Gaten die overigens vooral lagen op facilitair- en marketinggebied. Zo helpt business architectuur niet alleen bij de verbetering van de IT-ondersteuning, maar ook – of juist – bij de niet-IT-gerichte aspecten van een organisatie.

Afsluiting

Mijns inziens laten veel organisaties na om de potentiële waarde van business architectuur goed te benutten. Deze misverstanden zijn daar in mijn ervaring mede aan schuldig, en hier beter op letten kan helpen om de toegevoegde waarde van architectuur in je organisatie te vergroten!