Hoe werkt een Business Architect (2/3)

In de vorige blog betoogden we dat de business architect de verbinding kan leggen tussen de strategische ambitie en de operatie van een organisatie, en niet in de laatste plaats dit zo doen dat het door vertaald wordt in de technische infrastructuur. Dit laatste doen de andere architecten natuurlijk, maar er moet wel een pad geslecht worden waarlangs dit te realiseren is. En daar heeft de business architect een verantwoordelijkheid. Hoe communiceer ik de intentie van top management zodat de proces ontwerpers, de informatie analisten, de applicatie ontwikkelaars en IT ingenieurs effectief aan de slag kunnen.

Een business architect houdt van twee zaken: goed begrijpen hoe de doelen van een organisatie te realiseren zijn, en veel communiceren. Ieder business initiatief begint met een wens om iets te bereiken of op te lossen. Maar, hoe vertelt hij dat aan de andere disciplines. Daar zijn een paar sleutelbegrippen voor uitgevonden. Deze begrippen zijn noodzakelijk om de abstractie niveaus in een organisatie ontwerp aan elkaar te verbinden, en om ontwerpen overzichtelijk te houden. De business architect vertaalt eigenlijk de grote context – lees: de visie en strategie – in een aantal kleine contexten – lees: de capabilities, door sommigen business functie genoemd. De kleine context is dan voldoende overzichtelijk om door te vertalen in mensen, processen, technologie en informatie behoefte.

Dit hebben we jaren lang gedaan, maar dat bleek niet voldoende. Rond 2010 was er onvrede in de internationale werkgroep bij The Open Group. Het gat tussen strategie en capabilities was te groot. Er was kennelijk iets ongrijpbaars dat dit gat doet ontstaan. En dat ongrijpbare gat is het mechanisme waarmee je aan je collega vertelt hoe de samenwerking tussen die vaardigheden er uit ziet. Daar is het concept competenties voor uitgevonden. Niet de competentie van een persoon, maar van een organisatie. Als je dit concept goed wil begrijpen is het artikel in de Journal of Enterprise Transformation nuttig. De competenties van een bedrijf zijn de mechanismes waarmee het samenspel tussen capabilities mogelijk is, en daarmee de strategische wensen gerealiseerd kunnen worden. Dit was de missing link voor een volwassen professie. Het is heel nuttig om in de training bij de academie goed te oefenen om dit begrip eigen te maken. Het helpt je als architect om te communiceren hoe abstractie niveaus in verbinding staan en wat de toegevoegde waarde is van onderlinge afhankelijkheid.

Neem IKEA. De ambitie van dit bedrijf was ‘Leveren van Design meubelen op grote schaal tegen een betaalbare prijs’. Dit betekent dat er veel geld in design gestopt wordt, maar de massa productie stelt ook eisen aan dit ontwerp, en tegen lage prijzen vraagt weer om efficiency in de levering. Uiteindelijk leidde dit tot onderlinge afhankelijkheid tussen de capabilities Design, massa productie en het doe-het-zelf magazijn. Die leidden op hun beurt weer tot de eisen aan volume en groeistrategie. Probeer die afhankelijkheden eens in je eigen organisatie te ontdekken.

In de volgende en laatste blog geven we een kijkje in het belang van een gemeenschappelijke taal voor de communicatie tussen de verschillende abstractie niveaus en domeinen in een ontwerp.