Artikel

Infrastructuurarchitectuur: tijd voor focus op functionaliteit en kwaliteit

Echt architectuur op infrastructuur toepassen? Dat is heel goed mogelijk! Met een nieuwe, functionele benadering van het voortbrengingsproces van infrastructuur. Hiermee kunnen architecten hun verantwoordelijkheid binnen dit vakgebied beter invullen én praktisch handen en voeten geven.

Constructiedenken dominant

Infrastructuur en architectuur lijken sinds jaar en dag een ongelukkige combinatie te vormen. Vooraanstaande IT-architecten hebben lang volgehouden dat infrastructuur helemaal geen onderwerp van architectuur is, maar dat dit puur een engineering-domein zou betreffen. En een kritische beschouwing van veel architectuurmethoden leert - dat als het om infrastructuur gaat - er grofweg twee benaderingen zijn, die beide niet goed werken: ofwel infrastructuur wordt oppervlakkig en globaal benaderd (infrastructuur als applicatieplatform of -container, netwerk, opslag), ofwel er is een zeer technische benadering te onderkennen met uitwerkingen op het niveau van constructies en topografieën (zoals stacks en netwerkdiagrammen). De eerste aanpak werkt niet, omdat er te weinig mee wordt uitgedrukt. Infrastructuur blijft dan een vaag en abstract begrip en de ontwikkeling van een infrastructuurlandschap kan er dan ook niet mee worden gestuurd en gevormd. De tweede aanpak is feitelijk engineering, want het is gericht op de technische constructie, dus op ‘hoe het in elkaar zit’. Vanwege de hoge mate van detail en het gebruikte jargon is deze manier van vastleggen niet toegankelijk voor andere architecten en disciplines.

TOGAF®v9 is hierin een goed voorbeeld, omdat het beide benaderingen in zich heeft: enerzijds wordt infrastructuur teruggebracht tot ‘Platform’ in het Content Metamodel, anderzijds is onder het Technical Reference Model een enorme stapel technische componenten ondergebracht die met toevoeging van het woord ‘service’ nog enigszins een functioneel tintje moeten krijgen. Uiteraard is TOGAF®v9 op allerlei fronten bruikbaar, maar niet om infrastructuur mee te modelleren en te ontwikkelen. Dit leidt tot de onvermijdelijke vraag: welke benadering voor infrastructuurarchitectuur werkt wél? Het antwoord komt van vaderlandse bodem.

Blaauw: de drie ontwerpstappen

Het is ‘onze eigen’ professor Gerrit Blaauw die al in 1972(!) in zijn zoektocht naar een gestructureerd ontwerpproces voor mainframes een goed hanteerbare workflow voor de ontwikkeling van geautomatiseerde systemen definieerde. Blaauw onderscheidt drie abstractieniveaus die overeenkomen met drie stadia van ontwerp: Architectuur, Implementatie en Realisatie [a].

  • Architectuur is de fase waarin de benodigde functionaliteit wordt bepaald, waarbij die functies volstrekt technologieneutraal worden vastgelegd. In deze fase wordt gebruik gemaakt van archetypen en grondstructuren om de functionaliteit te modelleren en vast te leggen.
  • In de Implementatiefase wordt de architectuur vertaald naar een model voor een specifieke manier van toepassing van die functionaliteit, waarbij principes en richtlijnen voor de technisch ontwerper worden vastgesteld.
  • In de Realisatiefase ten slotte, wordt vastgesteld met welke middelen de oplossing wordt gematerialiseerd en wordt een technisch ontwerp opgesteld.

Een mooi voorbeeld om de drie stadia van ontwerp van Blaauw mee te verduidelijken is dat van de analoge klok. De architectuur van de analoge klok (de grondstructuur) kan worden beschreven als het ‘tijd aangeven’ met een grote wijzer, een kleine wijzer en een wijzerplaat. Alle analoge klokken voldoen aan deze structuur. Dit maakt, dat als een kind eenmaal klok heeft leren kijken, het dit overal kan, ongeacht de aard of vormgeving van de klok. Met andere woorden: het kind (her)kent de architectuur van de analoge klok.

Wanneer het principe van de analoge klok wordt toegepast voor een specifiek doel, dan komen implementatiekenmerken in beeld. Het specifieke doel vraagt om een specifieke methode van vormgeving van de klok. Neem een stationsklok. Een belangrijke eigenschap is dat binnen een station en op ieder perron de klokken gelijk dienen te lopen. Zouden ze dat niet doen, dan zou dit verwarring en onzekerheid oproepen bij de reizigers: “Kan ik mijn trein nog halen en welke klok kan ik wel of niet vertrouwen?” De architect dient een keuze te maken tussen verschillende manieren waarop meerdere klokken synchroon kunnen lopen. Zo kan hij kiezen voor de toepassing van zeer secure uurwerken, die per maand hoogstens een afwijking kennen van luttele seconden. Bij een klein aantal klokken in een geïsoleerde context misschien een prima keuze. Maar wanneer het om grote aantallen gaat over een grote hoeveelheid locaties, dan is het zeer waarschijnlijk dat het beter is om tussen eenvoudige klokken een netwerk aan te leggen, waarmee de klokken per minuut gesynchroniseerd kunnen worden. Uiteindelijk is ook deze oplossing gekozen door de Nederlandse Spoorwegen. Te herkennen aan de secondewijzer, die iedere minuut eventjes ‘wacht’ tot hij door kan lopen. N.B. Ook in dit stadium zijn de richtlijnen nog technologieneutraal en worden nog geen technische componenten vastgelegd. Uiteraard is het wel mogelijk om in richtlijnen naar technische componenten en/of protocollen te verwijzen, maar de beschrijving zelf is niet op dit niveau. Dit is namelijk het onderwerp van het volgende stadium.

In de realisatiefase worden de door de architect opgestelde richtlijnen toegepast in een technisch ontwerp, waarmee de constructie van de oplossing wordt uitgewerkt. Dit is dus de blauwdruk van de stationsklok,die door de constructeur wordt gebruikt om één of een heleboel fysiek identieke exemplaren van deze klok te bouwen.

Een nieuw vocabulaire voor infrastructuurarchitectuur

De stadia van Blaauw zijn heel goed toe te passen op het voortbrengen en aanpassen van infrastructuurlandschappen. Wat hiervoor nodig is, is een vocabulaire waarmee de functies kunnen worden uitgedrukt die in het infrastructuurlandschap voorkomen. Het standaard infrastructuurjargon voldoet niet, omdat het te technisch is. Daarom is vanuit de methodiek DYA|Infrastructuur en de community die zich hier omheen heeft gevormd een nieuwe set aan definities ontwikkeld. Er zijn, gebaseerd op het gedachtegoed van Blaauw, vier verschillende soorten definities te onderscheiden, die infrastructuurfunctionaliteit uitdrukken:

  • Enkelvoudige functies op architectuurniveau (Bouwbloktypen)
  • Samengestelde functies op architectuurniveau (Patroontypen)
  • Enkelvoudige functies op implementatieniveau (Bouwblokvarianten)
  • Samengestelde functies op implementatieniveau (Patroonvarianten)

Een Bouwbloktype heeft voor de architect het karakter van een atomaire of ondeelbare, universele infrastructuurfunctie. Van een Bouwbloktype kunnen één of meerdere Bouwblokvarianten worden afgeleid, die voor een specifiek doel de instantiatie van dit type zijn. Een voorbeeld is het universele functietype ‘Message Engine’, waarvan een specifieke variant kan worden gedefinieerd die geschikt is voor het verwerken van applicatieberichten, en een andere specifieke variant wordt vastgelegd die het afhandelen van gebruikersmail beschrijft.

Twee of meer Bouwbloktypen vormen samen een Patroontype, die op universele, technologie- en organisatieneutrale wijze een model voor een infrastructuuroplossing beschrijft. Een voorbeeld hiervan is ‘Message Handling’, dat een aantal functies bundelt tot een model voor een totaaloplossing die berichten afhandelt. Dit Patroontype bevat naast ‘Message Engine’ onder andere ook de functies ‘Message Store’, ‘Message Distribution’ en ‘Message Filtering’.

Uit één of meerdere Patroontypen worden Patroonvarianten afgeleid, die oplossingen beschrijven voor een specifiek doel, waarbij de Patroontypen als grondstructuren functioneren. De Patroonvarianten bestaan daarbij uit twee of meerdere Bouwblokvarianten. Dit ziet er in modelvorm als volgt uit:

Figuur 1: Gedeeltelijk informatiemodel, dat de samenhang tussen Functies (Bouwblokken) en Patronen en die tussen Typen en Varianten weergeeft.

Het complete informatiemodel (met daarbij ook kwaliteitsattributen en andere definities die in de modellering een rol spelen) is hier te vinden.

De rol van de community

Het is gebleken dat het ontwikkelen van een nieuw vocabulaire nog geen sinecure is. Tot op heden zijn er geen harde regels voor ontdekt en is het een kwestie van afwegen wat het beste werkt door het vocabulaire te toetsen in de praktijk. Om in het voorbeeld van de klok te blijven: Is het handig om de korte en de lange wijzer als twee afzonderlijke functies te zien (waarbij de ene de uren aanduidt en de andere de minuten). Of zijn het twee varianten van eenzelfde type, namelijk de functie ‘wijzer’? Een ander voorbeeld, meer in het infrastructuurdomein: Is ‘Authentication’ een functie, of is het een proces dat wordt ondersteund door een combinatie van de infrastructuurfuncties ‘Identity Validation’ en ‘Identity Store’? Meestal zijn meerdere mogelijkheden valide, maar wordt de keuze bepaald door een bepaald idee over de modellering rond de functie(s).

Al bij het begin van de ontwikkeling van het nieuwe vocabulaire is de community rondom DYA|Infrastructuur bij de vorming ervan betrokken. De definities op het niveau dat Blaauw architectuur noemt (Bouwbloktypen en Patroontypen) zijn dermate archetypisch, dat ze feitelijk zonder wijziging bruikbaar zijn voor elke organisatie. De vastlegging van deze definities leidt daarmee dus tot een referentiearchitectuur die direct bruikbaar is voor elke infrastructuurarchitect.

Voor het vastleggen is gekozen voor een kennissysteem op basis van een semantische wiki: de DYA|Infrastructure Repository (DIR). De universeel geldige onderdelen van deze repository zijn onder een soepele licentie (Creative Commons) via het Internet zonder beperkingen ter beschikking gesteld. Belangrijke effecten van het beschikbaar komen van (de inhoud van) deze repository zijn onder andere dat de community van infrastructuurarchitecten sterk is gegroeid. En dat er voor veel infrastructuurarchitecten een laagdrempelige instap beschikbaar is gekomen om vanuit een functionele benadering het vak uit te oefenen. Dit betekent niet dat het nieuwe vocabulaire af is. Het is een taal die zich binnen de community steeds verder ontwikkelt en wordt fijn geslepen. Handige ingangen tot de DIR zijn de overzichten van Bouwbloktypen en van Patroontypen.

De stappen van Blaauw in de infrastructuurpraktijk

Met het nieuwe vocabulaire wordt het voor infrastructuur mogelijk om de ontwerpstappen van Blaauw gestructureerd en efficiënt te doorlopen. De Patroontypen worden als grondplaat gebruikt, om van hieruit Patroonvarianten te definiëren, waarmee infrastructuuroplossingen voor een specifieke toepassing worden gemodelleerd. Hoe dit in zijn werk gaat? Hieronder wordt een voorbeeld gegeven voor het creëren van een architectonische beschrijving van een Cloud hosting service die wordt gebruikt om interne applicaties te hosten met een Best Effort beschikbaarheid.

De eerste stap in het ontwerpproces is het selecteren van één of meer Patroontypen die de basisstructuur vormen voor de uiteindelijke oplossing. Deze Patroontypen functioneren als grondplaat voor het te ontwikkelen model in de volgende stap, de Patroonvariant.

De architect start met het ter hand nemen van het Patroontype Application Hosting [b]:

Figuur 2: Architectuurmodel van de oplossing Application Hosting (Patroontype)

Aangezien het Patroontype een grondplaat vormt, dient de architect voor elk van de optionele (geärceerd weergegeven) onderdelen te bepalen of die onderdeel gaan uitmaken van de oplossing. Tevens zouden er andere Patroontypen of losse Bouwbloktypen toegevoegd kunnen worden. Voor ons voorbeeld van de Cloud Hosting service besluit de architect de Scheduler en Transaction Coordination functies niet nodig te hebben. Daarnaast zal de uiteindelijke oplossing geen gebruik hoeven maken van (een variant van) Data Storage, omdat Data Management voldoende is. Samengevat kan worden gesteld dat in deze stap de concepten worden geselecteerd die van toepassing zijn in het vormgeven van de gevraagde oplossing.

De tweede stap is het definiëren van een Patroonvariant, in het geval van dit voorbeeld op basis van bovenstaand Patroontype. Rekeninghoudend met de volgende functies, eisen en kenmerken, wordt een Patroonvariant geschetst:

PAV.Application Hosting.Cloud – Internal use only, Best Effort

Beschrijving
Deze Patroonvariant beschrijft de implementatierichtlijnen van een oplossing die applicatiehosting levert, met een Best Effort beschikbaarheid, gebruikmakend van een Cloud service.

Doel
Deze oplossing is bedoeld om te worden gebruikt voor experimentele en/of korte termijn business applicatiehostingbehoeften. Het is bedoeld voor interne toegang/intern gebruik, en moet beschikbaar worden gesteld aan eindgebruikers door middel van de Cloud Portal, die dient als een interface voor toepassingen van Cloud-gebaseerde applicaties. Omdat deze oplossing bedoeld is om zeer snel te leveren, kunnen er geen wijzigingen worden toegepast op de standaardoplossing.

Kenmerken en aanwijzigen voor gebruik

  • Zeer snelle levering voor het hosten van experimentele en / of korte termijn businessapplicaties
  • Alleen interne toegang toegestaan tot de gehoste applicaties
  • Alleen best-effort beschikbaarheid gegarandeerd
  • Maakt gebruik van standaarden van Cloud Providers; het is het niet mogelijk om additionele componenten toe te voegen
  • Er dient gebruik te worden gemaakt van Cloud Integration-oplossingen die reeds aanwezig zijn, indien nodig:
    • Data Management - Cloud Internal Usage
    • Asynchronous Messaging - ESB
    • Workflow Orchestration - Common Cloud Application Direction
  • Maakt gebruik van interne Authentication & Autorisation diensten; gebruik van extra Identity & Permission Validation voorzieningen zijn niet toegestaan.

Op basis van deze schets, zou een mogelijke invulling van een Patroonvariant, er zo uit kunnen zien [c]:

Figuur 3: Voorbeeld van een implementatiemodel van de oplossing Application Hosting, toegespitst op een middels de Cloud gerealiseerde toepassing (Patroonvariant)

Merk op dat voor elke infrastructuurfunctie die is gekozen, een specifieke variant wordt aangewezen. Deze functievarianten kunnen oplossingspecifiek zijn, maar het is ook heel goed mogelijk dat deze varianten door een (groot) aantal toepassingen gemeenschappelijk worden gebruikt. Daarnaast is de infrastructuurvoorziening gekoppeld aan naburige (al bestaande danwel nog te realiseren) infrastructuurvoorzieningen.

Op dit moment in het architectuurproces kan de architect ook de nodige infrastructuurspecifieke kwaliteitsaspecten van de te realiseren oplossing vastleggen (zoals beschikbaarheid, toerekenbaarheid en beheerbaarheid), en de relevante architectuurprincipes van de organisatie koppelen en vertalen. Samengevat worden in deze stap de requirements vastgesteld voor de specifieke oplossing aan de hand van de in de vorige stap geselecteerde concepten. Deze requirements worden vervolgens vertaald naar richtlijnen voor het ontwerp.

De derde stap is het vervaardigen van een Design Outline. De Design Outline functioneert als een artist impression oftewel een ontwerpstudie. Het beeldt uit (schetsmatig) hoe de architect de realisatie van de voorziening beoogt. De vorm waarin de Design Outline wordt gepresenteerd, is afhankelijk van de doelgroep van de architect en de middelen die hij heeft. Zo is het heel goed mogelijk om ook de constructie op min of meer abstracte wijze middels Archimate® te verbeelden, omdat Archimate® de nodige taalelementen heeft die gebruikt kunnen worden voor het afbeelden van infrastructuurcomponenten. Ook is het mogelijk om netwerkdiagrammen en/of tekeningen met systeemsymbolen (zoals bijvoorbeeld Microsoft hanteert) te vervaardigen. In sommige gevallen is een goede werkvorm het beschrijven van de oplossing in alledaagse taal. Een mogelijke uitwerking van bovenstaand model is hieronder weergegeven, gebruikmakend van Archimate® (in een sterk versimpelde weergave):

Figuur 4: Voorbeeld van een Design Outline, die de globale (deel)uitwerking van het hiervoor getoonde implementatiemodel (Patroonvariant) toont

De Design Outline levert niet het ontwerp zélf, maar bevat concrete aanwijzingen voor het ontwerp, in de termen (begrippen en technische specificaties) die in het ontwerp terug zullen komen. Het is in die zin nog abstract. Het geeft bijvoorbeeld geen invulling aan specifieke servers, al dan niet in specifieke aantallen, zoals in een technisch ontwerp zal worden gepreciseerd. Maar het geeft al wel duiding in de technische componenten die worden voorgeschreven voor (gemeenschappelijk) gebruik. N.B. In deze versimpelde Design Outline zijn (een deel van) de relaties met aanpalende functies/services niet opgenomen. In een werkelijke Design Outline zal hier juist veel nadruk op liggen, aangezien dit de meerwaarde is die het toepassen van architectuur biedt, namelijk de samenhang van de elementen van de constructie met de context waarbinnen deze constructie functioneert.

Waarom infrastructuurarchitectuur beter móet

Het toepassen van de workflow, zoals hierboven beschreven, is van toenemend belang in een tijd waarin infrastructuur steeds veelzijdiger en krachtiger, maar dus ook steeds complexer wordt. Het is voor de afnemers van infrastructuurdiensten belangrijk om de benodigde functionaliteit en kwaliteit te definiëren en vast te stellen op welke manier deze functionaliteit moet worden toegepast en welke richtlijnen er dientengevolge gelden.

Daarnaast wordt infrastructuur steeds meer als een product afgenomen (Cloud). Hierdoor is het steeds minder mogelijk om zélf de middelen te selecteren, het technisch ontwerp te genereren en de oplossing uiteindelijk te materialiseren (bouwen en construeren), zoals veel constructiegeoriënteerde infrastructuurarchitecten en senior infrastructuurontwerpers tot nu toe deden. Waar lange tijd de architectuur van de oplossing een impliciet gegeven kon zijn (die ervaren ontwerpers en constructeurs met zich meedroegen en zonder veel omzien of bezinnen toepasten), is het nu noodzakelijk dat de ene partij die de functionaliteit nodig heeft en de andere partij die de functionaliteit biedt, hier een heldere en ondubbelzinnige communicatie over voeren, zonder dat er a priori een discussie ontstaat over de technische invulling. Wat we wél willen, is inzicht in de functionaliteit en de kwaliteit van de producten die we selecteren en afnemen.

Met andere woorden: De architectuur en de architectuurkeuzen moeten helder worden. De DYA|Infrastructure Repository bevat hiervoor de basismodellen als vertrekpunt voor dit discours. Het is een eerste aanzet voor een vocabulaire dat recht doet aan de functionaliteit en de kwaliteit die infrastructuurlandschappen leveren. Hiermee is een goede basis neergezet voor een steeds betere ruimtelijke ordening van onze digitale landschappen.

Voetnoten

[a] "Computer Architecture", Gerrit A. Blaauw, Elektronische Rechenanlagen, 1972 heft 4, pagina 154-159

[b] Zie voor de volledige beschrijving van het getoonde Patroontype de definitie in de DYA|Infrastructure Repository. Voor het weergeven van de modellen is Archimate® gebruikt, waarbij vooruit wordt gelopen op het (waarschijnlijk) beschikbaar komen van de Infrastructuurfunctie als behavioural element. Binnenkort komt een modelleergids beschikbaar in de Repository, waarmee de regels voor het gecombineerd gebruik van Archimate® en DYA|Infrastructuur zijn vastgelegd en van good practises voorzien.

[c] Zie voor een vollediger uitwerking van de getoonde Patroonvariant de definitie in de DYA|Infrastructure Repository

 

Categorie:   
Auteur(s)
afbeelding van danieljumelet
Daniël Jumelet
BiZZdesign - Managing Consultant Business Infrastructure

Daniël Jumelet (1973) is Managing Consultant Business Infrastructure bij BiZZDesign en tevens voorzitter van de NAF-werkgroep infrastructuurarchitectuur. Sinds 2005 doet hij onderzoek naar de toepassing van architectuur in het infrastructuurdomein. Daarvoor was hij jarenlang werkzaam als infrastructuurspecialist op het gebied van netwerken en beveiliging. Hij is auteur van het boek “DYA|Infrastructuur, architectuur voor de fundering van de IT”, diverse (internationaal) gepubliceerde artikelen over dit onderwerp en medeverantwoordelijk voor de on-line bibliotheek voor infrastructuurarchitectuur, de DYA|Infrastructure Repository.

 
Reacties
Fred van den Boorn op donderdag 6 oktober 2011 16:13

Eindelijk eens een architectuur aanpak die verder gaat dan het constructie en technisch component denken.
Daniël Jumelet heeft een oplossing gevonden voor het probleem waar de infrastructuur al heel lang mee te kampen heeft: Een integrale aanpak waarbij enerzijds de brug wordt geslagen richting infrastructuur specialisten (Supply) en anderzijds richting infrastructuur dienst afnemers (demand) middels het gebruik van een voor de doelgroep geijkte vakjargon incl. bijbehorende modellering.

Chapeau,
Drs. Ing. F.L. (Fred) van den Boorn
Sr. ICT architect

Oude Lindestraat 70, 6411 EJ Heerlen
MUB 01.20
T +31 45 579 70 64
M +31 6 53 92 57 52
fred.vanden.boorn@apg.nl
www.apg.nl

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.