Blog

Wie betaalt de architectuur?

Ik kom het nu al bij meerdere klanten tegen. Wie betaalt eigenlijk de architectuur? De meeste organisaties die onder architectuur werken hebben een doelarchitectuur (SOLL) opgesteld. Soms is er zelfs een redelijke beschrijving van de bestaande architectuur (IST). Volgens het boekje (nou ja, het TOGAF boekje is zo’n 800 pagina’s…) moet er een gapanalyse komen tussen de IST en de SOLL architectuur en moeten er samenhangende projecten komen om de gaten op te vullen. Tot zover de theorie.

In de praktijk zie ik echter dat de meeste IT projecten helemaal geen gevolg zijn van bovengenoemde gapanalyse, maar het gevolg zijn van business wensen; vaak gebaseerd op wijzigingen in de markt of wet- en regelgeving. Er moet vaak een applicatie worden aangepast, soms zelfs meerdere. Er wordt een Projectstartarchitectuur (PSA) geschreven waarin de wijziging wordt beschreven.

Maar dan komt ineens de afdeling Architectuur om de hoek kijken. De nieuwe of aangepaste applicatie moet (ineens) gaan voldoen aan de doelarchitectuur (SOLL). En daarvoor moet het project de applicatie ineens op een nieuwe infrastructuur gaan bouwen of moet de applicatie gebouwd worden met de nieuwste versie van het ontwikkelframework. Dat vindt het project niet leuk. Tenslotte is het grootste belang van het project de doelstellingen van het project zelf te bereiken (en niet die van de architectuurafdeling) binnen de gestelde tijd en binnen het gestelde budget. Maar omdat de SOLL architectuur vaak is bekrachtigd door hogerhand rest het project weinig dan het voldoen aan de architectuur, waarmee de projectleider wordt geconfronteerd met hogere kosten, meer doorlooptijd en een hoger risico.

Natuurlijk is er begrip voor de projectleider. Ook is er begrip voor de architectuurafdeling. Het is tenslotte in het belang van de hele organisatie dat de beschreven SOLL architectuur wordt gerealiseerd. Maar er ontstaat wel ongewenst een spanningsveld. De architecten kunnen weinig anders doen dan dreigen – “als het project niet volgens de SOLL architectuur wordt gebouwd, wordt de applicatie niet in productie genomen” of “de SLA kosten zullen enorm zijn”. De projectleider kan ook alleen dreigen – “als ik volgens de SOLL architectuur moet opleveren, dan lever ik te laat op en dat is slecht voor de business”. Uiteindelijk moet het project opdraaien voor de kosten van het implementeren van een architectuur waarvan hij de kosten niet kan beïnvloeden. En de architecten kunnen de prachtigste SOLL architecturen maken zonder op de kosten te letten.

Welke kant de strijd opgaat is onduidelijk. Dat hangt af van wie de meeste macht heeft in de organisatie; de projectleider of de architecten. Het project loopt uit door nieuwe eisen vanuit architectuur of er moet een uitzondering worden gemaakt door de architecten voor dit specifieke project (80% van de gevallen); als de uitzondering maar tijdelijk is (en zoals u weet: alles is tijdelijk). In veel gevallen leidt bovenstaande belangenconflict tot een escalatie die voor alle partijen onwenselijk is. Architectuur wordt gezien als politieagent en projectleiders als onbuigzame types die niet denken aan het langetermijnbelang.

In mijn opinie is er een uitweg voor deze impasse. De architectuurafdeling zou een jaarbudget moeten krijgen om de kosten van het bereiken van de SOLL architectuur te bereiken. Dit budget kan worden ingezet voor het uitvoeren van projecten die leiden richting de SOLL architectuur. Dit kunnen projecten zijn die op initiatief van de architectuurafdeling worden uitgevoerd, of – nog beter – projecten die toch al liepen. Bij bestaande projecten kan de architectuurafdeling als sponsor optreden (geld en mensen) als men in het project stappen zet richting de SOLL architectuur.

Zo helpen de architecten de zorgen van de projectleider te verkleinen en stellen ze zich opbouwend op. Bovendien moet architectuur het doen met het gestelde budget. Dat betekent een snel einde aan te ambitieuze kostbare plannen. Bovendien kan architectuur aantonen wat haar toegevoegde waarde is (want ze krijgen het budget natuurlijk alleen als er een goede business case ligt voor de SOLL architectuur). En als een project niet wil meewerken, kan de architectuurafdeling een apart project starten om de rommel van het betreffende project op te ruimen waarmee bij hogerhand kan worden aangetoond dat werken onder architectuur op termijn toch goedkoper is. Ten slotte kunnen architecten nu eindelijk gaan werken met een fatsoenlijke plateauplanning om te komen van IST naar SOLL. Komt dat TOGAF boek toch nog van pas. Iedereen blij lijkt mij.

Toch zie ik het nog niet gebeuren. Als ik mensen spreek over dit idee is iedereen het met mij eens. Dat zouden ze wel willen. Maar ook: “Dat is niet hoe het nu werkt” en “We hopen over een paar jaar zover te zijn”.

Ik zeg: “Start nu en eindig de strijd!”

Deze blog is geschreven door Sjaak Laan. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van sjaaklaan
Sjaak Laan
Logica - Principal IT Architect

Sjaak Laan (1964) werkt bij Logica als Principal IT Architect en heeft 22 jaar IT ervaring. Sjaak is een specialist op het gebied van architectuur, security en infrastructuur en heeft veel kennis van bedrijfsprocessen en systeemintegratie. Hij wordt vaak gevraagd als lead architect of adviseur in complexe projecten. Hij is ITAC Master Certified IT Architect, CISSP (Certified Information Systems Security Professional) en TOGAF certified. Sjaak publiceert regelmatig over zijn vakgebied, onder andere via Computable en via zijn sites www.sjaaklaan.nl en www.sjaaklaan.com.

 
Reacties
René Hamberg op maandag 23 januari 2012 15:07

Voor mijn gevoel is dit teveel symptoombestrijding aangezien je onvoldoende structureel, altijd en overal toewerkt naar de SOLL architectuur. Je praat over incidentele projecten en opruimwerk.
Een SOLL architectuur mag alleen maar tot stand komen met een gedegen businesscase als integraal onderdeel van de besluitvorming. Net zoals die plateauplanning. Dan heb je die architect uit z'n ivoren toren en van z'n stip op de horizon terwijl de projectleider niet anders kan implementeren conform de voorschriften. Want die eventuele extra kosten waren al ingecalculeerd en voor lief genomen omdat de bestuurders weten dat ze op termijn terugverdiend worden.
Blijf alleen wel reëel en maak geen uitgekauwde doelarchitecturen voor over 5 jaar maar doe dat 1 a 2 jaar vooruit op basis van speerpunten waarvan je mag verwachten dat ze haalbaar zijn. De wereld verandert al hard genoeg.

Jurjen Berends op maandag 23 januari 2012 21:07

Volgens mij ligt het probleem in de term ProjectStartArchitectuur. Dat lijkt er op dat er voor elk project een architectuur bedacht wordt. Maar volgens mij hebben we de tijd achter ons gelaten dat een project een op zichzelf staande applicatie oplevert.
De meeste projecten leveren een toevoeging of een wijziging aan een applicatielandschap dat beheerd wordt door Architectuur en de beheerafdeling. Wanneer beide disciplines professioneel zijn ingericht, kunnen zij de projecten ondersteunen met architectuurstandaarden(ProjectStartArchitectuur?), programmeerstandaarden, NonFunctionalRequirements, tooling... Zeg maar alles wat standaard voor elk project nodig is.
Bij meerdere bedrijven heb ik inmiddels gezien dat wanneer het beheer en de architectuur goed is ingericht, het project meer kans heeft om te slagen binnen tijd en budget.

Michel Laan op maandag 23 januari 2012 21:47

Bij meerdere klanten ben ik er tegenaan gelopen dat een architectuurbeslissing gefaseerd werd uitgevoerd, waarbij ieder component dat geraakt werd door een project, als onderdeel van dat project vervangen moest worden. Dat heeft een aantal projecten een onhaalbare business case opgeleverd, hoewel de doelstellingen van het project an sich wel degelijk financieel aantrekkelijk waren.
Hoewel het theoretisch klopt dat een soll architectuur als separaat project uitgevoerd zou moeten worden, is dit vaak niet het geval. Dit in verband met het "don't fix it if it ain't broken" principe. Zelfs met een sluitende business case voor de doelarchitectuur is het vaak op korte termijn goedkoper of minder belastend voor de liquiditeiten van het bedrijf om alleen een aantal componenten van de architectuur in lijn te brengen.
Om theorie en praktijk aan elkaar te koppelen, is het in het artikel beschreven voorstel zeker het overwegen waard.

Marco Coopmans op dinsdag 24 januari 2012 9:31

Ergens zijn we ooit de fout in gegaan met onze redenatie: we bepalen een strategie met doelstellingen, we bepalen de architectuur die deze doelstellingen moet ondersteunen, we definieren projecten om de architectuur te gaan realiseren. FOUT: een project heeft niet als doel een architectuur te realiseren (al denken een hoop architecten er wel zo over), maar het behalen van business doelstellingen (toegevoegde waarde). De architectuur is (maar) een hulpmiddel om richting te geven aan de oplossing, maar nooit een doel op zich. Daarnaast is als het goed is de architectuur ook ten dienste aan de doelstellingen en zou deze (in de meeste) gevallen niet strijdig mogen zijn met een project. Probleem is echter dat zoals gesteld er meestel niet gekeken wordt naar de haalbaarheid en betaalbaarheid van een architectuur (de bekende ivorentoren). Een goede architectuur is een architectuur de realistisch is, aansluit bij de doelstellingen, en genoeg ruimte overlaat. Agile denkend ontstaat de beste architectuur vanuit de teams die de realisatie doen (vanuit de projecten dus). Dan doet dit probleem zich helemaal niet voor.

Pieter Horchner op dinsdag 31 januari 2012 17:00

Helder verhaal met een voorstel die kan werken voor een aantal organisaties.

Als enterprise architect wil ik echter aanvoeren dat er ook een probleem ligt bij de beschrijving van de SOLL architectuur. Deze SOLL architectuur beschrijft namelijk vaak een situatie van een ideale wereld zonder organisatie en budget beperkingen. Net als de reclame van een bepaald kaasmerk (Ideaal!). Het erge is dat deze SOLL beschrijving ook nog is gebaseerd op de behoeftes en denkbeelden van vandaag. Tien tegen één dat, mocht de SOLL situatie ooit bereikt worden, je als organisatie toch niet gelukkig zal zijn omdat de wereld is veranderd, de organisatie is veranderd en de behoeftes en inzichten van de opstellers van de SOLL architectuur zijn veranderd.

De SOLL architectuur is een baken op zee die je richting geeft, niet iets waar je tegen aan moet varen.

In mijn optiek moet een SOLL architectuur slechts ambities, kaders en structuren beschrijven en dat op een hoog abstractie niveau. Als architect moet je er vooral op sturen dat de structuren zodanig zijn dat een organisatie maximale bewegingsvrijheid krijgt en houdt. Opdat een organisatie niet vastzit en mee kan blijven bewegen in de vaart der volkeren. Zo zijn Service Oriëntatie en Business Services structuren die hierbij passen. Een architect moet er bij projecten dan slechts op toe te zien dat informatievragen van de front-office netjes via services worden afgehandeld. Voor een project nauwelijks een risico maar voor de toekomst van een organisatie een duidelijke win.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.