|
Architectuur wordt veelal aangeprezen als een manier om inhoudelijk te sturen op de lange termijn. Dat is nodig om het hoofd te kunnen bieden aan de veranderende omstandigheden. Met de architectuur kun je op koers blijven. Maar is je architectuur bestand tegen de golven van verandering?
Meestal geven we een architectuur vorm als een aantal, hopelijk goed gedocumenteerde, platen op een hoog abstractie niveau. Deze zijn dan nog aangevuld met een aantal richtlijnen voor de ontwerpers en bouwers, van vrijblijvend tot wet, die in deze context vaak principes worden genoemd.
Voordat deze platen er zijn, worden meestal een aantal alternatieven geschetst, waaruit de uiteindelijke oplossing wordt gekozen of samengesteld. Die alternatieven heten in deze context trouwens vaak scenario's. 'T woord scenario brengt -gelukkig- met zich mee dat er vaak ook wat dynamiek en actie in de beschrijvingen zit, maar verder vraag ik me wel af wat het verschil is. Bij de keuze uit deze scenario's wordt soms ook iets toegepast wat je zou kunnen
benoemen als een veranderingsanalyse: Stel dat we voor deze eindsituatie kiezen en voor deze veranderingstrategie, wat zijn daar dan de voor- en nadelen van?
In deze veranderingsanalyses heb ik tot nu toe echter steeds een stukje gemist. Ik mis namelijk de toets op de robuustheid, de veranderingsflexibiliteit van het gekozen scenario. Meestal ontbreekt het aan de tijd of aan het inzicht om het te doen, maar het lijkt me toch een noodzakelijke actie.
Waar bestaat die toets uit? Nou, in theorie is het simpel.
- Stap 1 Brainstorm.
In deze stap hoest je met een groepje deskundigen de mogelijke veranderingen op, die zouden kunnen optreden. Deze veranderingen moeten op kunnen treden in de tijd tot aan de realisatie van de architectuur. Te denken valt aan exemplaren van de volgende soorten: een wetswijziging, een nieuw op te leveren product, outsourcing van een proces, insourcing van een proces, introductie van een pakket, sanering van een pakket. D.w.z. allemaal veranderingen die meestal leiden tot een project om de verandering door te voeren.
- Stap 2 Selectie.
De vorige stap levert een lijst van groen en rijp door elkaar. Met de groep selecteer je een aantal met een grote kans, dan wel met een grote impact. (eigenlijk dus met een groot veranderingsrisico).
NB. soms weet je gewoon dat de verandering er komt, alleen niet wanneer. Die moet je hoe dan ook meenemen.
- Stap 3 Visualiseer.
Elke gekozen verandering wordt zo bloemrijk mogelijk beschreven. Je maakt of verzamelt plaatjes, teksten (bijvoorbeeld een verzonnen opdracht tot realisatie). Iedereen moet een goed beeld krijgen bij het probleem of de kans achter de verandering en waarom dat die verandering nodig is voor de organisatie. Dit kun je met de hele groep opstellen, maar dat is niet noodzakelijk. Wel moet je alle beelden uiteindelijk goed delen.
- Stap 4 Bepaal de impact.
Nu komt de toets op de architectuur. Ga na welke invloed de verandering heeft op de platen en op de principes. Moet je er veel bij maken? Is de verandering te localiseren op één plek? Moet je helemaal overnieuw beginnen? Indien enigzins mogelijk zou je ook een inschatting kunnen doen van de kosten die je moet maken om de alles weer bij te stellen. Ook hier zijn weer wat groepssessies aan te wijden.
- Stap 5 Verbeter.
Ga na of je de gekozen architectuur zodanig kunt wijzigen dat de impact van de gevonden veranderingen minimaal is. Daarbij komt het weer aan op de creativiteit van de architect en zijn team.
- Stap 6 Presenteer.
Presenteer het resultaat aan de deelnemers en neem het commentaar mee in de documentatie van de uiteindelijke architectuur.
Zelf heb ik dit -ondertussen al weer ruim 10 jaar geleden- in een heel rudimentaire vorm toegepast op een applicatie. De fout die ik toen heb gemaakt, is dat ik de bovenstaande stappen voor mezelf wel uitvoerde, maar dat ik de groep onvoldoende meenam. In vele projecten daarna is het gesneuveld, omat ik de opdrachtgever onvoldoende kon overtuigen van het nut. En, eerlijk is eerlijk, soms ben je al gewoon blij dat je een oplossing hebt. Je gaat er dan maar van uit dat deze ook bestand is tegen de veranderingen. Ook het feit dat je al uit verschillende scenario's hebt gekozen, hebt laten kiezen, draagt er aan bij dat deze meta-scenario's er bij inschieten.
Jan Bosch heeft ooit wel eens geschreven en gepresenteerd over de mogelijkheid om zo'n toets uit te voeren. In dat geval ging het om de architectuur van een softwaresysteem. Hij stelde dit voor om de onderhoudbaarheid van het te realiseren systeem te toetsen. In tegenwoordige termen zouden we dat het toetsen van de adaptiviteit kunnen noemen. Volgens mij meestal het argument om aan architectuur te doen. Ik heb echter nog nooit een architectuurbijlage gezien waarin deze toets is beschreven, of is aangegeven dat deze toets is uitgevoerd. U wel?
Only registered users can write comments.
Please login or register.
|
