Wat is het moeilijkste voor een business architect? (3/3)

Een business architect laat de relevantie van behoeften en eisen zien door ze te koppelen aan de strategische context. En daar hebben we meteen het meest ingewikkelde deel van het werk van een architect te pakken. De samenhang begrijpen is één, maar deze overbrengen aan ontwikkelaars en ontwerpers is een ander verhaal. Dit doe je niet met een paar rapporten waarin de functionaliteiten of use cases staan beschreven. Dat doe je door communicatie. Maar, wat moet ik dan als architect van de visie of strategie overbrengen aan ontwikkelaars? Ik denk dat dit niet door technieken te realiseren is, maar door communicatie moet gebeuren in het ontwerp proces.

Het is goed om eerst te begrijpen hoe een ontwerp proces verloopt. Ik heb hierbij niet in gedachten een product investering, maar het ontwerp van een operatie met nieuwe technologie of hulpmiddelen. Dit begint met een idee, getriggerd door nieuwe mogelijkheden en de aanname dat deze uiteindelijk meer kwaliteit of opbrengsten opleveren. Gedurende zo’n traject ontkom je niet aan een minimaal aantal disciplines die je daarbij moet betrekken. Eerst moet het idee bij de verschillende executives voldoende draagvlak hebben. Het idee wordt dan in een half A4-tje beschreven. Wat is het grote idee? Wat is de aanleiding? Zijn er showstoppers? Wat levert het naar verwachting op?

Welk idee dan ook, in de huidige tijd is technologie (nieuwe machine of digitale hulpmiddelen) niet meer weg te denken. Daarnaast is een financiële afweging nodig, en ook de verander- en invoeringstrajecten zijn complexer geworden door fragmentatie van processen en operaties. In een grotere onderneming zit je als snel in het begin met vijf mensen beslissingen te nemen, en worden al snel meer dan tien professionals ingeschakeld om de beslissing voor te bereiden. Dit moet je wel methodisch doen als je voortgang wil boeken. Zonder methode kan ook, maar duurt veel langer en gaat niet zelden gepaard met regelmatig vertraging en extra kosten omdat niet alle disciplines er bij betrokken worden. In zo’n ontwerp proces – ik zou het transformatie cyclus noemen – is methode en de communicatie tussen de verschillende disciplines kritisch.

Het is de belangrijkste drijfveer van een business architect om met een beperkt aantal concepten de connectie tussen de strategische context en de ontwerp vragen simpel uit te leggen, vooral gedurende de besluitvormingsfase. Iedereen in ontwerp heeft wel meegemaakt dat aan het einde van het traject twee of drie hardnekkige issues overblijven. Ik heb deze altijd terug kunnen voeren op een strategische eis, en meestal is dat ook al de halve oplossing.

Welke concepten zijn dan nodig in een ‘controlled language’? In de eerste blog zagen we al dat bijna alle bedrijven worstelen met het eerste deel transformaties waarin een strategische context in al zijn facetten recht te doen in het ontwerp van proces of technologie. Vroeger werd dit probleem ‘business en IT afstemming’ genoemd. Nu is de complexiteit het afstemmen van alle fragmenten in een proces. Meestal is eenvoudig te verzinnen welke vaardigheden (‘capabilities’) nodig zijn in de toekomstige situatie. Maar de complexiteit ontstaat eigenlijk altijd in de vertaalslag van strategie naar capabilities. Welke prioriteiten, en welke consequenties heeft de strategie voor technologie, persoonlijke skills, proces inrichting of hulpmiddelen die samen zo’n vaardigheid vormgeven? Het concept waarmee de transparantie voor iedereen duidelijk te maken is, is het concept ‘competentie’. Competenties zijn daarmee de verbinding tussen strategie en vaardigheden geworden.

Als je nieuwsgierig geworden bent naar de set van 20 concepten die een business architect nodig heeft bekijk dan het Open Business Architectuur preliminary standard van The Open Group. Veel succes met je volgende stap naar een excellente business architect!