Juridische vervolging van de digitale architect na een mislukt IT-project is onwenselijk. Dat stellen Kees Smaling en Martijn Akse, respectievelijk CIO Aegon Europe en lead-architect van Aegon Nederland. Het tweetal reageert op een eerder verschenen artikel naar aanleiding van een discussie over de rol, competenties en verantwoordelijkheid van architecten in het digitale domein.

“Wanneer het fout gaat, heeft dat weinig met de kennis en kunde van het individu te maken”, aldus Smaling. “De interne dynamiek binnen de organisatie is veelal de oorzaak.”

Het artikel See you in court! verscheen naar aanleiding van een discussie met architecten, gespecialiseerde juristen en CIO’s. Gesteld werd dat de architect geen vrijblijvende opdracht heeft en verantwoordelijk kan worden gehouden voor de gevolgen van eventuele verkeerde keuzes.

Belangrijk kritiekpunt van Aegon-CIO Kees Smaling is dat een ‘archaïsche wereld’ het uitgangspunt was: grote organisaties, met name overheden, waar grote IT-trajecten spelen die ingevuld worden door een grote leverancier. “De architect zou een rol hebben moeten spelen bij de beoordeling of het allemaal wel haalbaar was”, aldus Smaling.

“Dat is een casus die niet zo vaak meer voorkomt. Die hele grote brokken functionaliteit zijn ecosystemen geworden. Als uitbestedende partij ben je een spin in het web van beschikbare oplossingen. De rol van een architectuur bij zo’n heel grote deal is daarmee niet te vergelijken.”

Martijn Akse, als Head of Enterprise and Solution Architecture verantwoordelijk voor architectuur binnen Aegon Nederland en tevens betrokken bij de wereldwijde architectuurorganisatie, sluit zich daarbij aan: “Het is een andere wereld. Die big bang-implementaties komen bijna niet meer voor. Nieuwe technologieën zoals api’s en ontkoppelingen stellen je in staat om gradueel modulair over te gaan naar nieuwe oplossingen. Ook vanuit de grote, traditionele back-end.”

Competenties

De vraag is bovendien waar het bij zo’n grote uitbesteding fout gaat. Is dat verwijtbaar aan de architect, aan de organisatie? Wat is bijvoorbeeld de relatie geweest tussen opdrachtgever en bestuur?

Smaling: “Natuurlijk worden er ten aanzien van het architectuurontwerp echte fouten gemaakt. Daar mag je een architect best op aanspreken, net zo goed als je een jurist mag aanspreken op een onwerkbaar contract. Maar ik denk dat het vaker fout gaat door een gebrek aan alignment op het gebied van architectuur bij de opdrachtgever, dan qua persoonlijke competenties van de verantwoordelijke architect.”

Akse vult aan: “Wanneer je achteraf niet helder kan maken waar het misging, heb je iets fout gedaan in de contractering of in het verzamelen van de requirements. Er komen dus veel verschillende aspecten bij kijken die blijkbaar niet goed genoeg op papier zijn gezet.”

Smaling: “Als het in de nieuwe wereld misgaat, dan is de impact door de grote mate van modulariteit veel kleiner. Er is wel een randvoorwaarde: het start allemaal wel met professionals en teamwork. Anders houdt het gewoon op. Maar ook dat is een kwestie die de totale organisatie betreft: hoe ga je met elkaar om, hoe serieus nemen we elkaar en hoeveel ruimte geven we.”

Onafhankelijk

Binnen een groot bedrijf mag je van de architect een bepaalde mate van onafhankelijkheid verwachten, zo vindt het tweetal. Op basis van de juiste competenties adviseer je de directie, waarna deze vervolgens een besluit neemt. “Dan kan het niet zo zijn, dat wanneer de directie om wat voor reden dan ook het advies niet opvolgt, de architect daarvoor verantwoordelijk gehouden kan worden. Laat staan dat deze voor de rechter kan worden gesleept”, aldus Kees Smaling.

“Het moet Martijn niet uitmaken of hij onze CEO voor zich heeft, mij, of wie dan ook”

“De relatie tussen opdrachtgever en architect zou teamwork moeten zijn, met daarin wel ieder zijn of haar onafhankelijke rol. Ik hoop, en daar hebben we Martijn op geselecteerd, dat het hem niet uitmaakt of hij onze CEO voor zich heeft, mij of wie dan ook. Hij wordt ervoor betaald om zijn mening te geven.”
Smaling ziet dat in de praktijk nogal eens anders.

“Ik noem dat wuivend riet: meewaaiend met de wind. Dat probleem los je niet op door architecten op een digitale academie te sturen. Het knelpunt is niet zozeer de kennis, al is dit zeker een randvoorwaarde, maar vooral de attitude. Plus de dynamiek waarin je samenwerkt. Want als het bedrijf bol staat van de politieke spelletjes, kun je dat moeilijk de architect verwijten.”

Requirements

Binnen Aegon bestond de oude enterprise-architectuur uit zo’n zeventig principes, met daarbovenop nog eens zo’n vijftig afwijkingen hierop. Een grote administratie moest inzicht geven in alle tijdelijke afwijkingen.

Smaling: “Onze conclusie was dat wanneer er structureel meer afwijkingen dan regels zijn, de regels wellicht niet goed zijn. Al die principes zijn teruggebracht tot een minimum set aan requirements die nodig zijn om de flexibiliteit voor vandaag en naar de toekomst toe te kunnen borgen. Als we ontwikkelteams willen laten versnellen, dan moeten we teams de vangrails meegeven waar ze tussen moeten blijven. Een team kan dan zelf gas geven. Op de non-negotiables zijn geen afwijkingen, die zijn immers niet onderhandelbaar.”

Ze zijn volgens Akse wel in de lijn met de tijdgeest. “Het gaat erom hoe je zaken oplost. Sommige regels zijn vrij directioneel, andere zijn vager en meer richtinggevend. Daarnaast hebben we nog enkele voorkeuren, waar men zich niet per se aan hoeft te houden. Binnen de non-negotiables hanteren we drie modellen en een aantal productstandaarden.

Daarnaast focussen we op flexibiliteit, waardoor we niet voor elke capability architecturele standaarden gaan voorschrijven. Wel moeten we ervoor zorgen dat de blokjes in de architectuur, de capabilities dus, op de juiste wijze ontkoppeld zijn en met elkaar kunnen communiceren. Zo creëren we een omgeving waarbij iedereen voldoende vrijheid houdt om binnen de kaders een goede oplossing te vinden.”

Waarde definiëren

Het gaat allemaal veel verder dan architectuur, zo stelt Smaling. “In de nieuwe manier van werken definiëren we de waarde en geven we de teams vooraf mee waaraan ze moeten voldoen. De diverse supportafdelingen, waaronder bijvoorbeeld legal maar ook architectuur, komen in de nieuwe situatie dus niet om de zoveel maanden eens langs om de boel te auditen en vervolgens goed te keuren. Door richtlijnen vooraf te definiëren maken we veel meer tempo. Het heeft uiteindelijk maar één doel: door een grote mate van flexibiliteit de time-to-market verkorten.”

We leven in Smalings ogen in een totaal ander tijdperk. “Vijftien jaar geleden ging architectuur nog vooral over techniek, en kon je nog een plaatje van de doelarchitectuur met een levensspanne van vijf tot zeven jaar maken. Daarna kreeg je een periode waarin alles was gefocust op de waarde voor de business-lines.

Inmiddels is elke focus naar buiten gericht: klanten, ecosystemen of leveranciers. Het verandert bijvoorbeeld ook de manier waarop je naar sourcing kijkt. Je kijkt binnen de waardeketen naar waar je excelleert als organisatie. Maar ook binnen dat stukje heb je weer een nieuwe waardeketen waarin je niet één leverancier ziet maar tien”, aldus de CIO.

Pragmatisch

Het werken onder architectuur gaat niet vanzelf, dat moet je verdienen, vindt Martijn Akse. “Je moet pragmatisch zijn, dingen naar de stakeholders op de juiste wijze kunnen vertalen. Modellen zijn leuk, zeker voor intern gebruik, maar naar buiten toe is het een geheel ander spel. Je moet in staat zijn om vanuit de enterprise-architectuur een breed samenhangend verhaal te kunnen overbrengen. Wanneer Kees hier de architectuur niet meer kan uitleggen, heb ik het fout gedaan.”

Kees Smaling: “De enterprise-architect hoeft niet op schoot te zitten bij de CIO. We hebben soms best heftige discussies en zo hoort het ook. Ik sta dus achter een behoorlijke mate van autonomie. Maar om het eindresultaat toe te schrijven aan een van de participanten in de totale keten, dat gaat echt te ver. Dan gaat er op veel meer fronten wat mis. Mijn ervaring leert me dat het vaker fout gaat in de interne dynamiek dan op het terrein van inhoudelijke competenties.”

“Ik heb nog niet zoveel echt slechte architectuurontwerpen gezien. Wel zijn ze bijna nooit goed over de bühne gebracht. Bij grote projecten en in politieke omgevingen is de architect te vaak een roepende in de woestijn. Zo iemand kan heel veel vakinhoudelijke competenties hebben en de mooiste academische achtergrond, maar toch niet voldoende bij machte zijn om het af te dwingen. Dat is een gedeelde verantwoordelijkheid van de totale organisatie. Martijn wordt er daarentegen bij alle strategische trajecten bij geroepen, dat moet de standaardreflex zijn.”

“Wanneer Kees de architectuur niet meer kan uitleggen, dan heb ik het fout gedaan”

Eigenaarschap

Naast de competentievraag speelt ook de vraag rond het eigenaarschap, of beter: het ontbreken ervan. Dan vaart men blind op een architect aan de leverancierskant. Het inschakelen van een externe architect is volgens Smaling niet de oplossing. “Martijn zit hier omdat ik het onwenselijk vond dat ik op die positie een externe architect zou hebben. Wat is er mis mee om de solution-architect bij de leverancier te hebben? Het wordt pas een probleem in het geval van een enorme aanbesteding. Dat is in de tegenwoordige gang van zaken, in een modern IT-landschap, zoals gezegd helemaal geen issue meer. Dan verwácht ik niet anders dan dat de leverancier dit regelt.”

Akse merkt op dat er geen eenduidige definitie van de verschillende typen architecten is, hetgeen de discussie bemoeilijkt. Want over wat voor architect hebben we het? “Pak willekeurig een aantal vacatures voor een enterprise-architect en je ziet dat de rolbeschrijving behoorlijk varieert.” Smaling: “Certificering en opleiding kunnen best belangrijk zijn, maar het zegt niet zoveel over hoe iemand in de praktijk functioneert. Wat ik wel kan zeggen: echt goede architecten zijn schaars, zeker in de combinatie van vakinhoudelijke kennis en gedrag.”

End-to-end

“Er is zeker nog een rol voor solution-architecten weggelegd binnen de scope van de onderneming”, vervolgt Martijn Akse. “Iemand in vaste dienst, die focust op end-to-end aandachtsgebieden. Neem het ingewikkelde vraagstuk hoe je met je processen omgaat. Dat loopt van RPA en BPM tot cognitive computing en decision management. Dat is volledig met de architectuur verweven. Dat is niet een eenmalige activiteit die je even bij een externe partij kunt beleggen. Een klein intern team volstaat daarbij, eventueel tijdelijk aangevuld met mensen van buitenaf. Het budget daarvoor bepaal je per traject of businesscase.”

Hotze Zijlstra (1964) is taalkundige en heeft al meer dan 30 jaar ervaring in het journalistieke domein. Als ‘vaste freelancer’ doet hij thans de hoofdredactie van CDO Magazine en maakt hij dragende artikelen voor de uitgaven BAAS en CIO Magazine.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter