Op dit moment vindt er in de pers een discussie plaats over het mislukken van ICT projecten binnen de Nederlandse overheid. Daarbij worden verschillende argumenten als oorzaak en oplossing aangevoerd. Ook de focus vanuit architectuur is hierbij aan de orde gekomen (zie het ingezonden stuk in de Volkskrant van 8 december 2011). Het idee dat architectuur een bijdrage kan leveren bij de het voorkomen van falen onderschrijf ik, maar ook dat architectuur kan bijdragen aan het falen zelf zie ik regelmatig gebeuren.

Basis van het probleem is dat projecten vanuit de basis autistisch zijn. Ik heb de definitie van autisme even opgezocht in wikipedia:

Autisme is een pervasieve ontwikkelingsstoornis die zich kenmerkt door beperkingen in de sociale interactie, de communicatie en zich steeds herhalend gedrag.

Projecten kenmerken zich voornamelijk dat het resultaat, de middelen en de datum van opleveren vooraf zijn beschreven. Met name de combinatie van resultaat en opleverdatum werkt in de hand dat projecten naar binnen gekeerd raken. Als daarnaast het project wordt uitgevoerd door projectleden die alleen binnen het project actief zijn dan heb je al snel de poppen aan het dansen. Waarom zou je immers met je omgeving interacteren als daar vanuit je opdracht helemaal geen reden toe is, jij bent tenslotte aangenomen voor het projectresultaat binnen de gestelde termijnen.

Architectuur kan hierbij een goede bijdrage leveren om de borging met de omgeving en de reeds aanwezige architectuur te bewaken. Bijvoorbeeld door het opstellen van architectuurdocumenten zoals de Project Start Architectuur. In de praktijk zie ik echter twee patronen optreden. Het ene is dat de architect volledig op het project gericht is en zich committeert aan het eindresultaat. Het andere is dat een architect naast dit project nog andere activiteiten heeft en dus de focus moet verdelen. In het eerste geval zal de architect zich moeten gaan committeren aan het resultaat binnen de tijd met als risico dat er geschipperd moet worden met de architectuurkwaliteit. In het andere geval blijft de architect min of meer een buitenstaander en kan daardoor onvoldoende invloed aanwenden in de projectsturing.

Een paar voorbeelden uit mijn dagelijkse praktijk:

  • Gezamenlijk traject voor implementatie van een informatiesysteem. Project legt zichzelf een onrealistische deadline op. Deeltijdarchitect poogt om invloed aan te wenden in diverse overleggen maar moet vanwege andere verplichtingen een aantal sessies missen. Gevolg is dat men voor een suboptimale oplossing kiest en dit zelf ook onderkend. Deadline wordt niet gehaald door andere knelpunten, vervolgens wordt er doorgemodderd met de suboptimale oplossing in het vervolg.
  • Project voor de implementatie van componenten gebaseerd op open standaarden. Projectarchitect is alleen actief binnen dit project en gaat aan de slag met de uitwerking van de open standaarden. Komt vanuit      projectperspectief al snel tot de conclusie dat de standaard voor dit project niet volstaat en past deze dan ook aan. Echter zonder hierover te communiceren met de omgeving, zoals de beheerder van de open standaard (die bestaat niet vanuit de project scope). Bij implementatie een groot probleem omdat de omgeving terecht ageert tegen afwijkingen ten opzichte van de open standaard.

Wat zou een oplossing kunnen zijn? De belangrijkste is volgens mij dat architecten in een heel vroeg stadium betrokken moeten zijn bij de project kalender. Zo is er in en vroeg stadium een helder beeld van de aankomende projecten en kunnen architecten hierop anticiperen. Daarnaast moeten we voorkomen dat architecten met hun huidige invulling steeds in een spagaat terecht komen. Architectuur wordt in projecten niet als een middel of resource gezien en dat is een tekortkoming van ons als architect!

Weergaven: 225

Reactie van Louis Dietvorst op 14 December 2011 op 19.19

Mooi artikel Bert! Ik deel jouw mening dat architectuur ook een bijdrage kan leveren aan het falen van een project. Reden te meer om als architect heel erg voorzichtig te zijn met wat je adviseert. Misschien denk je wel dat je "de beste" richting weet maar hoe staaf je dat dan? Wie weet geef je morgen wel een advies waar de organisatie over 5 jaar nog vreselijke last van zal krijgen. Dat wil je toch liever niet op je geweten hebben. En misschien moet je ook heel goed nadenken vanuit welke context of drijfveren je jouw advies beredeneert. Als je de voor jou vertrouwde as-is en hergebruik als een van hoofddoelen ziet, terwijl projecten juist meestal veranderingen beogen en dus willen vernieuwen stuur je daarmee misschien wel een project een ongewenste richting in. Dus dan zouden architectuuradviezen ook juist primair gericht moeten zijn op het goed ondersteunen van de gewenste verandering. Architectuur invullen door het toevoegen van structuur alleen lost m.i. niet zo heel veel op. Je bakent iets wat complex is af in deelstructuren die je gaat bestuderen maar uiteindelijk is toch alles met alles verbonden dus (de verkeerde!) abstracties maken kan ook heel erg gevaarlijk zijn. Ik vind het een ouderwets hulpmiddel wat we vaak gebruiken om complexe thema's tijdelijk af te bakenen. Maar ja zo zit onze wereld nu eenmaal in elkaar. We weten gewoon nog niet beter. We duwen alles wat een beetje complex is in een hokje in de hoop dat we er dan niet meer over na hoeven te denken. Soms werkt dat maar bij organisatieverandertrajecten is dat toch wel even heel iets anders. Als architect wil je juist de totale samenhang van de verandering succesvol tot stand brengen. Verder zie ik steeds meer dat onze wereld (die al heel complex was), steeds complexer aan het worden is op allerlei niveau's: organisatievormen, relatienetwerken, technologieën die steeds meer met elkaar integreren. Alleen al om die reden zouden architecten zich meer vaardig moeten maken in het organiseren van netwerken (verbinden, bruggenbouwen, zowel in de relatiesfeer als in de technologiesfeer) i.p.v. zoals we nu nog vaak doen, afbakenen in structuren. Gedistribueerde concepten dus; die hebben de toekomst. Gecentraliseerde of gedecentraliseerde concepten zullen steeds meer op de achtergrond komen. Kijk bijv. eens naar het gedistribueerd ontwerp van Internet en hoe mooi dat eigenlijk werkt in de praktijk. Een prachtig voorbeeld van een bijna zelfsturend/zelfherstellend netwerk. Als je weet hoe routers grofweg werken zijn zij in feite een mooi voorbeeld van hoe je complexiteit kunt distribueren op basis van een paar heel simpele principes, vergelijkbaar met principes van bijv. een zwerm vogels: de afstand weten in te schatten tot je directe buren, de snelheid in weten in te schatten van je directe buren is al voldoende om de zaak "in de lucht" te houden. Zou zoiets ook niet kunnen gaan werken voor gedistribueerde architectuurconcepten?

Reactie van Bert Dingemans op 27 December 2011 op 11.23

Dank voor je reactie Louis, leuke anecdote over je laatste alinea. Op de universiteit heb ik een keer een groepsopdracht moeten doen om een simulatie te maken van een zwerm vogels. Daar kwamen we als groep niet uit er ontstond een heel omvangrijk model van gebeurtenissen en acties uit onze discussies. Vervolgens bracht de docent het terug tot de twee regels die jij in je tekst benoemd, we waren er zelf niet opgekomen. Het terugbrengen tot de essentie van de oplossing is misschien wel de belangrijkste taak van een architect, maar het is tegelijkertijd het moeilijkste onderdeel.   

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Advertenties

Je kunt hier adverteren

© 2019   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden