Architectuur denken

Organisaties huren om diverse redenen (ICT-)architecten in. Dit heeft alles te maken met de behoefte aan een adequaat kwaliteitsniveau van producten. 

Wat is (ICT-)architectuur?

Enterprise- en ICT-architectuur zijn breed gehanteerde begrippen. Elke organisatie van enig formaat heeft enterprise-architecten, ICT-architecten, en/of informatie-architecten in dienst die zich bezighouden met de lange termijn vormgeving van processen, systemen, infrastructuur en bedrijfsgegevens. Een soms geplaatste kanttekening is dat hieruit voortvloeiende architectuurplaatjes voor de lange termijn al vaak verouderd zijn voordat ze af zijn, en al zeker voordat ze volledig geïmplementeerd zijn.

Dus wat levert architectuur ons nu eigenlijk op? 

Er zijn talloze definities van (ICT-)architectuur, al hebben deze wel het een en ander gemeen. Bijvoorbeeld: architectuur bestaat uit regels, richtlijnen, ontwerpprincipes, modellen en standaarden. ICT-architectuur dient de organisatiestrategie en de proces- of domein-architectuur van de organisatie, te ondersteunen. Zoveel is helder. Wat minder helder is, is hoe we tot bepaalde architectuurkeuzes komen. Een groot aantal architectuur-frameworks is inmiddels in omloop, zoals Zachman-architectuur. Deze bieden echter weinig handvatten voor goede architectuurkeuzes. Maken we architectuurkeuzes uitsluitend op basis van vakmanschap, zonder dat de klant er veel toe doet? Of zijn er misschien manieren om beredeneerd architectuurkeuzes te maken op basis van de situatie en behoeften van de klant? 

Functionaliteit en de rest

Alle architectuur is een vorm van ontwerp; we bedenken constructies en uitgangspunten om aan behoeften tegemoet te komen. Alle ontwerp is gericht op het samenbrengen van mogelijkheden en behoeften. In de ICT zijn de mogelijkheden meestal beperkt door tijd, geld en techniek. De behoeften komen uit de organisatie waarvoor de ICT moet worden ingezet. Het is gebruikelijk om dergelijke behoeften uit te drukken in termen van functionaliteit: de oplossing moet een bepaalde functie vervullen. Bij het ontwerpen van informatiesystemen beginnen we normaliter dan ook met deze functionele behoefte. Hierbij is de leidende vraag: ‘wat moet het doen?’.

We nemen natuurlijk wel meer in ons achterhoofd mee dan alleen functionele eisen; zo snapt iedereen wel dat er kwaliteitseisen zijn, zoals: ‘de user interface moet zo intuïtief mogelijk zijn’. 

We nemen echter niet alle kwaliteitseisen even gemakkelijk mee in ons achterhoofd en daarnaast, we kennen ze niet allemaal. Onuitgesproken verwachtingen van klanten (‘Hoe bedoel je dat dit niet op een Mac draait?’) resulteren nog te vaak in een lauwe ontvangst van het product. Als we dergelijke verwachtingen en behoeften van de klant expliciet maken en meenemen in het ontwerpproces, verhogen we onze kansen dat die blij wordt met het product aanzienlijk. 

Het bepalen van architectuurkeuzes werkt analoog aan ontwerp, maar richt zich niet in eerste instantie op de functionaliteit, al moet de architectuur deze wel ondersteunen. Architectuur richt zich met name op de niet-functionele behoeften; de vraag ‘hoe moet het gebeuren?’. Bijvoorbeeld ‘het moet op alle in gebruik zijnde platforms kunnen draaien’, of ‘het moet binnen een dag door een materiedeskundige te leren zijn’. 

Dit brengt ons tot onze definitie van "architectuurdenken":

Architectuurdenken is een benadering waarbij wij niet-functionele kwaliteitseisen bewaken, door ze expliciet te maken en vervolgens te vertalen naar architectuurkeuzes. De architectuurkeuzes dienen vervolgens als kaders voor het ontwerp. Door deze benadering kunnen we bewerkstelligen dat we alle belangrijke eisen afdoende onderkennen en niet per ongeluk buiten de boot laten vallen.

Dit houdt in dat we architectuur in brede zin zien als kaders die worden gesteld om met name niet-functionele eisen te bewaken. De niet-functionele eisen bepalen de kwaliteit van het product en noemen we dan ook wel ‘kwaliteitseisen’. Goed geformuleerde kwaliteitseisen zijn concreet meetbaar (SMART) en hebben daarbij een tolerantie. Sommige eisen zijn hard en onveranderlijk (bijvoorbeeld: ‘audit trail is verplicht’), van andere kan worden verwacht dat deze in de toekomst veranderen (bijvoorbeeld: ‘het product moet 100 simultane gebruikers ondersteunen’). Kwaliteitseisen SMART maken is nooit eenvoudig, vereist creativiteit en goede afstemming met de klant, maar dat probleem is niet nieuw. 

Deze visie op architectuur houdt in dat een ‘goede architectuur’ alleen bestaat in combinatie met de klant waarvoor de architectuur is opgesteld. Geen architectuurkeuze is universeel van toepassing. 

Architectuur gaat toch juist over de lange termijn?

Enterprise- en ICT-Architecten houden zich veel bezig met de lange termijn. In onze visie is dit wel een aspect van architectuurdenken, maar niet de essentie. In de meeste organisaties bestaan eisen voor de lange termijn-bruikbaarheid van producten en oplossingen en in die zin is het logisch dat architecten zich met deze vraag bezighouden. Het is een lastig punt om in te vullen in een snel veranderende wereld en organisaties die steeds sneller willen veranderen en daarin worden beperkt door onder meer hun ICT. Het is dan ook niet vreemd dat de architecten hier veel aandacht aan geven. 

Het lange termijn-denken levert vaak architectuurplaatjes op die zijn gericht op de situatie over vijf of zelfs tien jaar. De vraag hoe iets in de toekomst moet functioneren, is vrijwel altijd van toepassing, maar de antwoorden op deze vraag niet. Als een architect wordt gevraagd om kaders op te stellen voor een kleine, snel groeiende organisatie, kan een kader ook zijn: ‘kies voor snelle en goedkope korte termijn-oplossingen, aangezien alles toch over een paar jaar moet worden vervangen’. Al is dit geen lange termijn-architectuur, in deze situatie sluit hij juist goed aan op de lange termijn-behoeften. In een snel groeiende organisatie voldoet een wegwerp-oplossing waarschijnlijk beter aan de eisen dan het neerzetten van een architectuur die tien jaar lang meekan en zowel geschikt is voor een organisatie van 50 mensen als een van 1.000 mensen. Een goede architect kiest niet automatisch voor duurzame oplossingen, maar doet dit alleen als duurzaamheid echt een eis is.  

Hoe ver moet architectuur gaan?

Het is vaak verleidelijk om voor alles regels en kaders te bedenken. Maar deze leggen ook beperkingen op aan de organisatie en een onnodige beperking doet afbreuk aan de flexibiliteit. Dus hanteer bij het maken van architectuurkeuzes het principe van de minimale set van regels. Regel alles wat nodig is om te voldoen aan de eisen, maar ook niet meer dan dat. Onnodige beperkingen gaan ten koste van algemeen geldende kwaliteitseisen aan flexibiliteit. Ook wanneer er twee vergelijkbare architectuurkeuzes zijn, waarbij de een minder beperkingen oplegt dan de ander, is het een goede vuistregel om de minst beperkende keuze te nemen. Neem bijvoorbeeld de keuze tussen twee vergelijkbare softwarepakketten, waarvan een Microsoft Windows als platform vereist en de andere draait op meerdere platforms, waaronder Windows. Ook al is de standaard momenteel Windows, het tweede pakket heeft een streep voor op het eerste omdat toekomstige platformkeuzes niet bij voorbaat tot problemen  leiden.

Droomarchitecturen

Een veel voorkomend euvel bij de producten van architecten is het opleveren van ideale architecturen die niet binnen een reële termijn te realiseren zijn. Zo zijn Service Oriented Architectures (SOA) momenteel populair bij architecten. SOA kan inderdaad grote voordelen bieden, waar het gaat om flexibiliteit van de informatievoorziening. Het is hierbij wel zaak om de architectuur reëel te houden; de meeste organisaties van enig formaat kunnen onmogelijk binnen een paar jaar volledig overstappen op SOA. Een goede architectuur houdt dan ook rekening met meer dan de theoretisch wenselijke eindsituatie en biedt ook concrete meerwaarde in de tussensituaties. Bedenk daarbij dat tegen de tijd dat de eindsituatie bereikt kan zijn, de wereld waarschijnlijk al weer zover veranderd is dat deze niet meer relevant is. 

De afgelopen twintig jaar hebben we CASE driven development, 4GL-talen, RAD/DSDM, Extreme Programming, Component Based Development langs zien komen en weer weg zien zakken in de vergetelheid. Vandaag is SOA de heilige graal voor informatiesystemen. Elk van deze benaderingen is destijds geponeerd als de ultieme manier om ICT toekomstvast en flexibel te maken. Op al deze concepten zijn droomarchitecturen gebaseerd die enkele jaren later al vervielen tot legacy status. De kans dat SOA over tien jaar nog steeds een dominante architectuur is, lijkt daarom klein. Te ver proberen de toekomst inkijken, is alleen al om deze reden een illusie en het is zinnig om waar mogelijk een architectuur open te houden naar mogelijke of reeds voorziene toekomstige ontwikkelingen.

Voor kwaliteit hebben we toch al ISO-9000?

Er bestaan nog altijd veel misverstanden over wat kwaliteit is en wat kwaliteitssystemen zijn. Een van grootste is dat een kwaliteitssysteem borg staat voor goede kwaliteit. Dit is niet het geval; een kwaliteitssysteem als ISO-9000 staat slechts borg voor voorspelbare kwaliteit; welke kwaliteit maakt niet uit. Hoe hoog de kwaliteit van een product is, hangt af van tal van factoren, maar het kwaliteitssysteem garandeert alleen dat de processen voorspelbaar en gedocumenteerd zijn, waarmee de kwaliteit van een min of meer constant niveau is. Het is een illusie voor welk restaurant met Michelin-ster dan ook, om ooit ISO-9000 gecertificeerd te worden, aangezien alles afhangt van personen en met name van de chefkok. Maar voor McDonald’s is ISO-9000 certificering relatief gesproken een peulenschil. Welk van deze de betere kwaliteit voedsel levert, heeft niets te maken met het kwaliteitssysteem.

Conclusie

ICT-architectuur heeft dus niet alleen een bestaansrecht, maar ook een directe relatie met de situatie van de klant, gebaseerd op met name de niet-functionele eisen. Dit beeld wordt door een significant deel van ervaren Enterprise / ICT-architecten gedeeld.  

Voorbeeld functionele versus niet-functionele eisen: 

In de woningbouw is het al sinds lang en breed gewoonte om architectuurdenken te hanteren. Denk hierbij niet specifiek aan architecten die individuele woningen ontwerpen, maar meer aan bestemmingsplannen, normen en regelgeving voor de aanleg van woningen. Als een gemeente een woonwijk wil aanleggen, is de functionele eis: ‘er moeten X gezinnen kunnen wonen’. 

Niet-functionele eisen kunnen bijvoorbeeld zijn: 

• er moet groenvoorziening aanwezig zijn conform landelijke normen;
• de wijk moet bereikbaar zijn voor auto's, fietsers, voetgangers en via openbaar vervoer; 
• de wijk moet voorzieningen bieden voor 90% van de dagelijks boodschappen.

Daarnaast bestaan er bouwvoorschriften, Europese en landelijke regels waaraan woningbouw moet voldoen. Deze architectuur-voorschriften zijn vanuit een hoger niveau opgelegd om breder geldende kwaliteitseisen te garanderen.

Zo zijn gemeenten als Lelystad en Almere bewust planmatig opgezet om aan een veelheid van kwaliteitseisen te voldoen, naast het bieden van slaapplaatsen voor forensen die in de omgeving van Amsterdam werkzaam zijn. Er valt altijd iets aan te merken op deze keuzes, maar ze zijn expliciet genomen en er is over nagedacht. Was dit niet gebeurd, dan was mogelijk het Nederlandse equivalent van de getto’s van New Delhi ontstaan. Een verzameling gebouwen zonder samenhang of plan, met straten die als dusdanig herkenbaar zijn alleen omdat er geen gebouwen staan.

In Nederland hebben wij duizenden regels voor woningbouw en die maken het vaak lastig om iets voor elkaar te krijgen. Maar bij elke Nederlandse nieuwbouwwoning zijn veiligheid en een veelheid aan voorzieningen gegarandeerd en dat is gemakkelijk over het hoofd te zien; we kennen niet anders. 

Kwaliteit

Onze definitie van ‘kwaliteit’ staat in de ISO 9000 standaard: Kwaliteit is de mate waarin een geheel van eigenschappen en kenmerken voldoet aan de eisen

Deze definitie van kwaliteit gaat uit van de behoeften van de klant. Kwaliteit is niet een objectief gegeven, maar is direct gerelateerd aan de klant. Als we de Oracle database-software vergelijken met MySQL, dan is de onderlinge kwaliteit niet onafhankelijk van de klant gedefinieerd. Want voor de ene klant is het conformeren aan industrie-standaarden belangrijker dan voor de ander, die mogelijk meer waarde hecht aan het verifiëren van de interne werking en het aanpassen hiervan.

 De ISO 9126-standaard onderkent de volgende aspecten van productkwaliteit:

• Functionaliteit
• Betrouwbaarheid
• Bruikbaarheid
• Efficiëntie
• Onderhoudbaarheid
• Portabiliteit

Hierbij heeft elk niveau nog een eigen onderverdeling. 

Deze standaard biedt vaak bruikbare handvatten voor het definiëren van kwaliteitseisen.

Contact

Wilt u meer informatie? Neemt u dan contact met ons op via Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken. of bel met Martin Genuit, tel. +31 (0)6 304 18 297.

Euclides - de juiste beslissing.