Het borgen van de architectuurinbreng bij veranderingen blijft in veel organisaties een grote uitdaging. Gevolg is een onderbenutting van de investering in de architectuurfunctie. Daardoor ontstaan op de langere termijn grotere risico's en hogere kosten. genoeg reden om wat extra aandacht te schenken aan enkele van de meest voorkomende hindernissen en daarvoor oplossingen aan te dragen.
Alle organisaties onderkennen, naarmate zij groeien, de noodzaak om vooruit te kijken en te waken over de samenhang en richting van ontwikkelingen. Zij hebben daarom geïnvesteerd in een architectuurfunctie en coördineren veranderingen door middel van portfoliomanagement gebaseerd op een strategische agenda. Architectuur gidst de ontwikkelingen op basis van afspraken over toekomst en richting die eerder zijn gemaakt met het organisatiebestuur.
Volwassenheidsniveaus
In het werken met architectuur bestaan een aantal volwassenheidsniveaus, maar globaal genomen zijn de volgende zaken altijd essentieel voor het goed werken van de architectuurfunctie:
1. Verandermanagement en projectmanagement zijn geïmplementeerde processen.
Zonder gestuurde en gecontroleerde ontwikkeling geen architectuurtoepassing.
2. De inzet van architectuur is in die processen geborgd. Architectuurtoepassing is niet vanzelfsprekend. Input, output, verantwoordelijkheden, bevoegdheden en de integratie in het veranderproces zijn noodzakelijk.
3. De organisatie heeft een lange-termijn visie en een strategie. Zonder richting en strategie is architectuur tijdverspilling.
4. Er bestaat bewustzijn met betrekking tot architectuur. Als de business geen besef heeft van architectuur, dan wordt toepassing van architectuur een grote uitdaging. Men zal de beperkingen die de architectuur vaak oplegt niet accepteren.
5. Er bestaat vertrouwen met betrekking tot architectuur. Als de business geen vertrouwen heeft in architectuur, dan wordt toepassing van architectuur eveneens een grote uitdaging.
6. Er bestaan realistische ambities en verwachtingen met betrekking tot architectuur. Het moet duidelijk zijn wat architectuur wel en niet doet en die ambitie moet in de organisatie bekend zijn. Tevredenheid is het verschil tussen verwachtingen en het daadwerkelijke product.
7. Er is een evidente business case voor de inzet van architectuur. Architectuur gaat over continuïteit en voorspelbaarheid. Organisaties die ad hoc worden aangestuurd en worden geleid door snel veranderende, externe omstandigheden, hebben andere zorgen.
Voorwaarde één en drie zijn evident qua belang. Echter in de praktijk valt het toch nog vaak tegen hoe goed de veranderprocessen geborgd zijn en hou houdbaar en leidend een visie en een strategie gehanteerd worden.
De resterende punten twee en vier tot en met zeven wil ik, beginnend met de laatste, verder bespreken, omdat deze voorwaarden toch vaak over het hoofd worden gezien, er geen of niet afdoende afspraken worden gemaakt en er onvoldoende, blijvende aandacht is.
Flexibiliteit
Organisaties die geleid worden door snel veranderende, externe omstandigheden hebben veel behoefte aan flexibiliteit, niet aan procedures en afspraken. Zij zijn vaak inherent risicovol en de mogelijkheden om ver in de toekomst te kijken zijn beperkt. Wat er aan architectuurgedachten plaats vindt moet gericht zijn op het verhogen van de adaptiviteit van de organisatie en haar diensten en producten. In de architectuurvolwassenheidsmodellen scoren dit type organisaties altijd laag. Dat is niet erg. Het past bij dat type organisatie. Streven naar het hoogste volwassenheidsniveau zou een onverstandige investering zijn. Er is namelijk geen evidente business case voor een grote investering in een zware architectuurfunctie.
Gaat uw architectuurfunctie u alleen voor domme acties behoeden of stippelt zij uw toekomst uit, zodat u gedachteloos van de reis kunt genieten? Zijn uw architecten überontwerpers die alles tot in het kleinste detail in hun computer hebben staan of heeft u meer aan enkele goed geformuleerde, fundamentele principes, die door hen ook effectief bewaakt (kunnen) worden? Het beeld van wat architectuur zou moeten zijn, kan binnen een organisatie sterk verschillen. Stel eenduidig die ambitie vast en communiceer die herhaaldelijk. Onduidelijkheden met betrekking tot ambitie en doelen van architectuur ondermijnen sterk de tevredenheid.
Het vertrouwen in de architectuurfunctie bepaalt ook de inbreng en relevantie. Geen vertrouwen in architectuur betekent dat de organisatie waar mogelijk de architectuurfunctie zal vermijden en negeren. De architectuurfunctie krijgt vertrouwen door snel, goede producten te leveren en een pro-actieve dienstverlening te bieden. Lever dus producten die op de klantbehoefte zijn afgestemd. Denk vanuit de klantvraag, zodat u de klant begrijpelijke, to-the-point adviezen kunt leveren. Biedt alternatieven als een voorgestelde aanpassing om architectuurredenen niet door kan gaan. Vraag naar de behoefte achter de klantvraag. Vaak komen klanten immers met oplossingen in plaats van met vragen.
Als uw organisatie het niet doet, zet dan als architect of architectuurverantwoordelijke zelf prestatienormen neer: ‘Een projectstartarchitectuur leveren wij in een week.' Om pro-actief te kunnen werken, moet u niet alleen op de hoogte zijn van de bedrijfsstrategie en de toekomstvisie, maar – nog belangrijker – van de actuele discussies in het bedrijf: praat met mensen, fysiek of via social media. Architectuur = communicatie.
Cruciale succesfactor
Zoals uit de vorige punten blijkt is communicatie voor architectuur een cruciale succesfactor. Dat geldt niet alleen richting de potentiële, directe klanten van architectuur, maar zeker ook richting de sponsoren en budgethouders. Zij moeten weten wie u bent en wat u voor de organisatie betekent. Denk na over wie dit zijn en zorg dat er geen week voorbij gaat zonder dat zij u opmerken.
Veranderingen komen op het ict-terrein hoofdzakelijk vanuit twee stromen: projecten en changes.
Op het terrein van de projecten is een goede fasering zeer belangrijk. Creëer duidelijke mijlpaalmomenten, waarbij opnieuw gekeken wordt naar projectaspecten als scope, tijd, geld en business case, maar waar ook een aantal specifieke architectuur- en ontwerpproducten worden opgeleverd en beoordeeld, voordat het project verder mag naar de volgende projectfase.
De architectuur- en projectproducten die daarbij het belangrijkst zijn, zijn:
1. Projectvoorstel
2. Projectinitiatiedocument (PID)
3. Projectstartarchitectuur (PSA)
4. Oplossingsarchitectuur (OA)
5. Ontwerpen (functioneel, technisch en procesmatig)
6. Testplannen
De documenten hebben wat de architectuurtoepassing betreft de volgende rol:
1. Op basis van het projectvoorstel kan de impact op de bedrijfs-, informatie-, technische en beveiligingsarchitectuur worden ingeschat. Dat kan gebeuren binnen een zogenaamd BITS-architectuuroverleg. Daarbij staat BITS voor bedrijf, informatie, techniek en security en vertegenwoordigt daarmee vier belangrijke architectuuraspecten. In deze fase zegt de architect niets over hoe iets moet gebeuren, maar of iets moet gebeuren.
2. Het PID is een verdere uitwerking van de planning, investering, fasering en projectorganisatie. Het PID geeft meer inzicht dan het projectvoorstel en wordt in conceptvorm aan de architecten opgeleverd om een PSA op te stellen.
3. De PSA geeft relevante randvoorwaarden (verplichtend) en adviezen over ‘het hoe' op het terrein van de bedrijfsarchitectuur, informatiearchitectuur, technische architectuur en beveiligingsarchitectuur. De PSA vormt samen met het PID de goedgekeurde opdracht voor de projectmanager!
4. In de OA geeft het project een ontwerp en beschrijving van de verandering op hoofdlijnen. Dit ontwerp moet aannemelijk maken dat de verandering conform de in de PSA gestelde architectuurrandvoorwaarden wordt gerealiseerd.
5. De ontwerpen (functioneel, technisch en procesmatig) geven in detail weer hoe een en ander wordt vormgegeven. Omdat de details nu meer zichtbaar worden kunnen niet eerder waargenomen architectuurvragen naar boven komen.
6. Een beoordeling van de testplannen moet duidelijk maken of de tests zodanig zijn opgezet dat ze kunnen aantonen dat aan de gestelde architectuurrandvoorwaarden tegemoet gekomen wordt.
De PSA wordt tijdens de hele projectuitvoering gebruikt om periodiek te toetsen of aan alle eerder gestelde architectuurrandvoorwaarden wordt voldaan. Cruciaal daarbij is dat het PID met de PSA, onlosmakelijk, door de stuurgroep als één opdracht aan de projectmanager wordt gegeven. De PSA moet onderdeel zijn van de projectopdracht, niet een van de projectproducten! De PSA wordt door architectuur opgesteld vanuit haar bewakende functie op het project en niet vanuit haar deelnemende rol binnen het project!
Veranderingen via een change die niet door het projectproces lopen, maar die door een ITIL-achtig proces lopen, moeten ook worden beoordeeld op architectuurimpact. Anders zou er een gat ontstaan waarlangs allerlei ongewenste veranderingen de organisatie binnen lopen. De architectuurimpact van changes wordt door het eerder genoemde BITS-overleg beoordeeld. Dat overleg brengt een advies uit naar de ict-organisatie en de klant, waarin de wenselijkheid van de voorgestelde verandering en eventuele alternatieven worden geschetst.
Jo Sanders, architect bij de Politieacademie
