Dit artikel bevat een korte samenvatting van een definitie van enterprise architectuur voor lezers van mijn artikelen over enterprise architectuur.
Ten eerste kan ik natuurlijk verwijzen naar het wikipedia artikel over Enterprise-architectuur. Dit artikel is op zich heel geschikt om zich een beeld te vormen, alleen is het erg ICT-centrisch. Op zich is dat geen probleem, maar de sterke invloed van ICT-centrische architectuurframeworks als Zachman en TOGAF is duidelijk zichtbaar.
Voor een deel is het een kwestie van perspectief, wat ik probeer te visualiseren door de “lagen” anders te tonen. Bijna alle architectuurmodellen, zeker op het gebied van enterprise architectuur, associëren “lagen” met architectuur, bijna alsof het hetzelfde is.
Dit is een standaard representatie die we in verschillende varianten tegenkomen:
Het wordt al anders (maar niet topologisch) als we het als volgt presenteren:
Vervolgens, min of meer op dezelfde wijze als wij hebben uitgelegd in het satelliet model, kunnen de “ringen” rondom het gedeelte waarom het gaat (nu zichtbaar prominent in het centrum geplaatst) in “segmenten” worden verdeeld voor de verschillende diensten waarvan de business architectuur gebruik van wil maken, zoals Security, Marketing, Sales, HR, enz.
Deze diensten worden in kaart gebracht met Business Capability modellen, waarvoor ook steeds meer referentiemodellen beschikbaar komen, bijvoorbeeld in de BizBok, maar ook zijn er modellen gepubliceerd voor bijvoorbeeld de zorgsector, het hoger onderwijs, en de woningcorporaties.
De meeste capability modellen hebben een structuur zoals hieronder getoond, met drie hoofdgebieden: Core, Strategic, en Supporting.
Hieronder een voorbeeld uit de zorgsector.
Een kenmerk van een goed gestructureerde enterprise architectuur is het doorvertalen van de structuur van dit capability model naar de buitenlagen. Het capability model weerspiegelt zich als het ware in de andere lagen. Zo kunnen wij bijvoorbeeld Finance herkennen in de applicatielaag: daar zit het grootboek, daar zitten de transacties.
Een belangrijk onderdeel van de satelliet-topologie is de koppeling tussen de “schillen” (als bij een ui). Zoals Archimate heel goed heeft afgedwongen vindt die koppeling plaats via services. De services laag isoleert als het ware de schillen van elkaar. Ook dwingt een service laag de ontwerpers tot het nadenken over de interfaces en niet over de implementatie (of een service door een proces wordt ingevuld, en of dat proces lokaal of remote is, enz.). Dit realiseert losse koppeling tussen de lagen. We zien dat het satelliet model topologisch niet veel verschilt van het standaard model, maar vooral een conceptuele kanteling wil benadrukken. De taal die ik hier gebruik is weliswaar gekleurd door IT, maar we hebben het hier niet over IT! Een afdeling HR die samenwerkt met een afdeling Projecten doet dat via een services laag. Dat wil alleen maar zeggen dat de communicatie en de afspraken lopen via afspraken op dat terrein. Het is een samenwerking die de partners in die samenwerking aan het elkaar koppelt via services of diensten.
We zien dat enterprise architectuur dus vooral business-centrisch is, of zou moeten zijn. Het gaat om het inzichtelijk maken wat de business is en doet, ter ondersteuning van zowel strategische als tactische als operationele doelen. Dat informatiemanagement er een belangrijke rol in speelt, is evident. Dit is echter om andere redenen, en dan ook nog vaak met een andere focus dan wij meestal tegenkomen. ICT is vaak nog een groot probleem, en een té grote kostenpost. Om die reden gaat er veel aandacht naar uit. Een andere reden is de pathologische focus in de moderne maatschappij op technologie in het algemeen en informatietechnologie in het bijzonder. Ook wel gekarakteriseerd als “our love affair with technology”. Reden temeer om de technologie niet in het centrum te plaatsen!
Enterprise architectuur is ook, en in mijn definities op de eerste plaats, een proces. Het faciliteert een zelflerend en zelfreinigend proces, dat de organisatie transparant maakt, en dat in deze tijd waarin ongelooflijke bestuurlijke missers mogelijk zijn, van immense betekenis kan zijn. Een enterprise architect van een (zeer) grote overheidsorganisatie vertrouwde mij toe dat enterprise architectuur maar moeizaam gedragen wordt door de directie, “omdat het de organisatie té transparant maakte…” (sic!). Dát is echter wel waarom het moet gaan bij enterprise architectuur!
Enterprise architectuur geeft handvatten om de verschillende perspectieven van een organisatie (bijv. de lijn- en de projectorganisatie) op elkaar aan te laten sluiten. Hierdoor zullen projecten doen wat ze moeten doen, in plaats van, zoals te vaak gebeurt, hun eigen doelen definiëren.
Doordat enterprise architectuur op deze wijze dwars door de gehele organisatie heen snijdt, is het een lastig probleem als het mandaat van de enterprise architect teveel ingeperkt wordt door deze rol te plaatsen binnen de ICT context. Elke organisatie of een enterprise (van elke omvang) heeft het liefst maar één enterprise architect (eind-verantwoordelijk), en omdat het over de inhoudelijke bewaking gaat van de enterprise zou deze rol geplaatst moeten zijn naast de CEO, die over de executieve bewaking van de enterprise gaat. Enterprise architectuur in elke enterprise zou die plek moeten bevechten. Maar die plek moet ook verdiend worden! En dat gebeurd niet met onafzienbare stapels modellen en referentie architecturen, maar door afgerekend te worden op de geleverde toegevoegde waarde voor de enterprise als geheel.
Leave a Reply