Architectuur is parallel proces

De architectuur van een applicatie wordt vaak bepaald tijdens de applicatieontwikkeling. Dit leidt meestal niet tot een applicatielandschap met de gewenste kwaliteit. Bovendien ­ervaren projectleden de architect soms als vertragende factor. Een goed gekozen ­architectuurproces biedt uitkomst, concludeert Louis Stevens.

Een projectmanager stuurt zijn project op doorlooptijd, budget en ­resultaat. Dit geldt ook bij applicatie­ontwikkeling. Als fulltime­ project­medewerker zal een architect zich moeten conformeren aan de door de projectleider gestelde kaders. Dit betekent dat hij zich volledig zal moeten richten op dat ene project. Aandacht voor het applicatielandschap zal beperkt blijven tot de applicaties waarbij de te realiseren applicatie zal moeten aansluiten.

Het kan dan gebeuren dat er software wordt gemaakt die beter in een ander, mogelijk later gepland project gebouwd had kunnen worden of met enige generalisatie elders in het applicatielandschap had kunnen worden ­hergebruikt. Onvoldoende aandacht voor het applicatielandschap als geheel resulteert in suboptimale oplossingen. Bij een suboptimale oplossing beschikt een individuele applicatie wel over de gewenste eigenschappen, maar het applicatielandschap als geheel niet. Om een goed compromis te kunnen vinden is een projectenoverstijgende aanpak nodig. Deze benadering beperkt zich niet tot het applicatielandschap. Het is van belang dat bedrijf-, applicatie- en technologiearchitectuur tezamen ook één samenhangend geheel vormen.

Een architect zou zijn tijd ook kunnen verdelen over meerdere projecten. Hij is dan wél in de positie om meerdere applicaties wat betreft architectuur op elkaar af te stemmen. De architect loopt bij deze projectenoverstijgende aanpak het risico een vertragende factor te worden. Dit geldt des te meer als niet alleen het applicatielandschap, maar ook kwesties zijn aandacht vragen die zijn gerelateerd aan de bedrijfsvoering of de infrastructuur. Hulp van collega-architecten kan enig soelaas bieden, maar is geen afdoende oplossing, want ­architectuur moet ook dan in de loop van een project worden bepaald.

De noodzaak van een benadering die de onderhanden projecten overstijgt, pleit voor een op zichzelf staand bedrijfsproces, als onderdeel van de staande organisatie. Met dit ‘architectuurproces’ worden de activiteiten van de ­architecten bedoeld om de producten en diensten te kunnen leveren waarvoor ze verantwoordelijk zijn. Het architectuurproces verloopt parallel aan de overige bedrijfsactiviteiten, zoals het bouwen van software. Architecten zitten dus niet met de handen over ­elkaar totdat er zich een project aandient. Daarom kan bij een nieuw project de architectuur al in belangrijke mate gereed zijn en afgestemd met alle betrokkenen.

 

Parallel ontwikkelen

Af is een architectuur nooit. In de omgeving van een organisatie of binnen de organisatie zelf zullen zich nieuwe ontwikkelingen en mogelijkheden voordoen waar een organisatie alleen met de juiste architectuurkeuzes goed op in kan spelen. Voorbeelden zijn bijgestelde bedrijfsdoelstellingen, reorganisaties en nieuwe technologische mogelijkheden. Dit maakt het ontwikkelen van architectuur tot een continu proces. Als het architectuurproces onderdeel is van de staande organisatie en architectuur niet meer in projecten voor softwareontwikkeling wordt bepaald, kan een architect deze nieuwe ontwikkelingen en mogelijkheden tijdig signaleren en er adequaat mee omgaan. Het geeft hem bovendien de ruimte om ook zijn andere verantwoordelijkheden te nemen, zoals adviseren bij aan architectuur gerelateerde vraagstukken en toezien op de kwaliteit van architectuur. Toch is deze aanpak geen vanzelfsprekendheid (zie kader).

Parallel ontwikkelen van architectuur lijkt op de wijze hoe een bestemmingsplan tot stand komt: bij de start van de bouw ligt het al klaar. Een bestemmingsplan houdt niet alleen rekening met dat ene gebouw, maar ook met een hele wijk, gemeente of provincie. En het is breed afgestemd met uiteenlopende, maatschappelijke groeperingen. Als pas bij de start van een bouwproject een bestemmingsplan zou worden opgesteld, dan zouden er weinig gebouwen van de grond komen.

Een architect richt zich primair op het bepalen van de gewenste architectuur en het vastleggen ervan met de daartoe geëigende artefacten. Maar hij speelt ook een rol bij het realiseren van de architectuur. Daarom neemt hij deel aan projecten om de beoogde architectuur van de te implementeren organisatie of het tot stand te brengen systeem over te dragen, te verfijnen en te verbeteren. Dit geldt ook bij ­applicatieontwikkeling. Daarbij realiseren architecten en applicatieontwikkelaars tezamen de applicatie met de gewenste applicatiearchitectuur.

Aandacht

Een applicatiearchitectuur kan zonder er aandacht aan te besteden ‘ontstaan’ tijdens het bouwen van software of door haar te bepalen vanuit de scope van een project als een van de eerste stappen van softwareontwikkeling. In beide gevallen is het zeer de vraag of dit het gewenste applicatielandschap oplevert. De kans is groter dat het resultaat vanwege de complexiteit zal lijken op de nauwelijks te ­onderhouden ‘legacy’-software uit de vorige eeuw. Voldoende aandacht voor applicatiearchitectuur is daarom noodzakelijk. Deze architectuur heeft betrekking op het ­gehele applicatielandschap en wordt bepaald parallel aan en los van het bouwen van applicaties.

Architect moet belang bedrijfsbrede architectuur aantonen

Een projectleider is verantwoordelijk voor het project dat hem is toegewezen tot het moment van decharge. Daarna vervallen zijn verantwoordelijkheden. Hij zal daarom niet willen investeren in een architectuur die verder reikt dan de scope van zijn project. Architecten zijn tezamen met andere professionals verantwoordelijk voor de gehele informatievoorziening van een organisatie en ook op de langere termijn. In dit spanningsveld tussen korte- en langetermijnbelangen zal een organisatie een juiste afweging moeten maken.

De opdrachtgever van een project zal zich achter de projectleider scharen, omdat hij de projectresultaten waarschijnlijk direct nodig heeft voor de dagelijkse werkzaamheden van zijn bedrijfsonderdeel. Een architect kan de standpunten proberen te beïnvloeden door te wijzen op de kwalijke langetermijngevolgen van uitsluitend aandacht voor projectgerelateerde architectuur. In de praktijk blijken de concrete, kortetermijnresultaten als regel aantrekkelijker dan de abstractere, langetermijnverwachtingen.

Maar ook de architect zou een medestander aan zijn zijde moeten vinden: het management dat verantwoordelijk is voor de continuïteit van de organisatie. Het is daarbij de taak van de architect het belang van een bedrijfsbrede architectuur voor het voetlicht te brengen. En hij heeft recht van spreken: mede als gevolg van jarenlang onvoldoende aandacht voor een bedrijfsbrede architectuur, kampen veel grote hedendaagse organisaties nu met een IT-landschap dat hen hindert slagvaardig om te gaan met nieuwe ontwikkelingen. Een dergelijk IT-landschap kenmerkt zich door een grote diversiteit aan computers, besturingssystemen en applicaties die met een wirwar aan koppelingen met elkaar verbonden zijn. De voor een vereenvoudiging vereiste investering blijkt te kunnen oplopen tot een jaarlijks bedrag van honderd miljoen euro gedurende meerdere ­jaren op rij.

Een soepel architectuur­proces is niet vanzelfsprekend

Het belang van een continu architectuurproces parallel aan systeemrealisatie wordt in het IT-domein breed onderkend. Toch is de implementatie van een soepel functionerend architectuurproces nog allerminst een vanzelfsprekendheid. Zo stelt Ralph Foorthuis in zijn promotieonderzoek vast dat ruim 60 procent van degenen die enterprise-architectuur in projecten toepassen, deze als vertragend ervaren (Automatisering Gids, 12 oktober 2012). Foorthuis ziet de vaststelling als een signaal dat er nog veel verbetering mogelijk is.

Een vertragend architectuurproces staat in het bijzonder op gespannen voet met agile initiatieven. In het agile domein wordt architectuur vaak als een hinderlijk ‘Big Up-Front Design’ ervaren. Dit doet vermoeden dat in de betreffende organisaties het architectuurproces slecht is geïmplementeerd. Bij agile softwareontwikkeling staat het bepalen van architectuur als parallel en continu proces onder druk. Veel agilisten vinden dat architectuur vooral tijdens softwareontwikkeling zou moeten worden bepaald.

De belangstelling voor het architectuurproces lijkt over het algemeen klein vergeleken met die voor architectuur. Zo is in het architectuurdomein een ‘agile architectuur’ al jaren gemeengoed, maar een ‘agile architectuurproces’ nog steeds niet. Een bekende methode voor een architectuurproces is de TOGAF Architecture Development Method (1995). Een andere benadering met aandacht voor het architectuurproces is DYA (2001). De belangstelling is een gevolg van de grotere behoefte aan architectuur, toen vanaf het begin van de jaren tachtig nieuwe technologieën het mogelijk maakten applicaties te integreren.

Volwassen architectuurmethoden benaderen het architectuurproces als een van de bedrijfsprocessen in de staande organisatie. De samenwerking met ­betrokken organisatieonderdelen en projecten is integraal onderdeel van de methode. De bestaande organisatie is het uitgangspunt, in plaats van een ‘green field’. De methoden richten zich op het creëren van waarde, bijvoorbeeld met een projectstartarchitectuur of een aantal gerationaliseerde oplossingsvarianten voor een aan architectuur gerelateerd vraagstuk. En ‘agility’ heeft de voorkeur boven het in een vaste volgorde realiseren van een aantal voor­geschreven artefacten.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag