Architectuuroverzichtkrachtig managementinstrument
Als we vooruitkijken in plaats van achteruit dan komen er weer veel extra uitdagingen op de IT-wereld af: een verdere toename van globale outsourcing, inkoop van grote in zichzelf complexe deeloplossingen, vergaande integratie van heterogene applicaties, korte responsetijden in een dynamische markt. Alle genoemde trends leiden tot meer complexiteit en meer mensen die op een of andere manier betrokken zijn bij het tot stand komen van de IT-oplossing.
Een van de problemen van de laatste halve eeuw was dat voor veel projectdeelnemers het overzicht ontbrak of in de loop van het project verloren ging. Gezien de genoemde trends, dreigt dit probleem nog veel groter te worden. Er is een geneesmiddel tegen deze kwaal: een compact architectuuroverzicht (zie kader). In dit artikel geven we inzicht in het doel van zo’n overzicht, hoe het ontstaat en hoe het eruit ziet.
Gaten
Veel IT-projecten zijn zo groot dat er veel verschillende experts een bijdrage aan leveren, van de financieel directeur tot programmeurs. Het is de kunst om het hele projectteam gericht te houden op het bedrijfsdoel en daartoe de geëigende technologische middelen in te zetten. Een compact en specifiek architectuuroverzicht blijkt een effectief hulpmiddel om dit te bereiken. Zo’n overzicht kan de volgende bijdragen leveren:
• Veel specialisten zijn zich veel beter bewust van de context (omgeving, missie, rationale) en van de consequenties van hun keuzes voor deze context.
• Gaten en risico’s worden vroeg zichtbaar, door een equivalent gat in het overzicht.
• Onduidelijkheden en onzekerheden komen vroeg op tafel doordat het samenstellen van het overzicht al tot veel interactie in de organisatie leidt.
Samenvattend: het architectuuroverzicht plaatst technologische overwegingen in een bedrijfsmatige en organisatorische context. Het is een hulpmiddel voor veel belanghebbenden, het is een krachtig managementinstrument.
Hoe ontstaat een architectuuroverzicht? Het is verstandig een bottom-up- en top-downbenadering af te wisselen om in circa tien tot twaalf stappen tot een architectuuroverzicht te komen. Het gebruik van ‘time-boxes’ per stap is sterk aan te raden. De eerste iteraties kunnen in time-boxes van 15 tot 60 minuten worden uitgevoerd, latere iteraties gebruiken time-boxes van uren tot dagen.
Door de feiten zoveel mogelijk te kwantificeren wordt zeker gesteld dat deze verkenning voldoende specifiek wordt uitgevoerd.
De eerste top-downstap volgt de IEEE 1471 standaard (zie kader): wie zijn de belanghebbenden (‘stakeholders’), welke zorgen hebben zij (‘concerns’), wat zijn relevante gezichtspunten (‘views’), welke modellen zijn nodig om deze gezichtspunten te beschrijven (‘models’)? In de tweede stap worden de meest waardevolle en belangrijke punten vanuit klantenperspectief bepaald, in de derde stap de meest kritische en kostbare punten vanuit ontwerpperspectief . Deze selectiestappen zijn de meest cruciale, maar ook de moeilijkste in deze aanpak. Met de informatie die er nu ligt kan men in de vierde stap de structuur en de presentatie van het overzicht bepalen. Alle genoemde stappen worden meerdere keren herhaald.
Vervolgens de bottom-upbenadering. Het proces van het zoeken naar feiten is een snelle verkenning van verschillende views: bijvoorbeeld in drie stappen via de drie views: 1. bedrijf en gebruikers, 2. het product en de requirements, en 3. het ontwerp en de realisatie met technologische keuzes. Het resultaat is een grote collectie van nog niet verbonden datapunten: de stukjes van een legpuzzel. Voorbeelden van datapunten zijn het te verwachten aantal gebruikers, het aantal verschillende recepten, het aantal instanties van recepten, de vertaling van recepten naar omvang en snelheid bij een gegeven technologie. Deze collectie van datapunten is na de eerste verkenning nog zeer incompleet. Het hoofddoel van deze bottom-upstappen is de feiten te betrekken bij de discussie. Dit om een algemene valkuil te voorkomen: een hoog gehalte van te abstracte of te academische stellingen.
Discussie
Zowel de bottom-up- als de top-down-iteratiestappen leiden vaak tot een discussie over: wat moet binnen en buiten het overzicht vallen? Outsourcing en inkopen van grote deeloplossingen leiden bijvoorbeeld tot de vraag: tot hoe ver bemoeit de inkopende of de uitbestedende partij zich met de leverancier? Bij vergaande integratie vervagen de grenzen van het eigen systeem, de eigen organisatie en zelfs het eigen bedrijf. Snelle marktveranderingen beïnvloeden de beantwoording van de vraag eveneens. Het architectuuroverzicht kan houvast bieden door meerdere onderwerpen te onderkennen en helder vorm te geven, bijvoorbeeld de volgende drie:
• Het (te realiseren) systeem.
• Het maken en het invoeren van het systeem; het project en de organisatie die het systeem realiseert.
• Het gaan gebruiken van het systeem; het bedrijf of de bedrijven die het systeem operationeel gaan benutten.
Deze onderwerpen zijn niet onafhankelijk maar gerelateerd: sommige architectonische beslissingen hebben impact tot voorbij de grenzen van deze onderwerpen. De waarde van een architectuuroverzicht met bijvoorbeeld deze drie scopes en de behandeling van zaken die over deze drie scopes heengaan, is dat het hele team de samenhang blijft begrijpen en elke deelnemer eigen acties beter kan laten passen in de eigen strategie.
Interessant
Voor de top-downbenadering is IEEE 1471 een bruikbare standaard. Deze standaard werkt het begrip architectuurbeschrijving verder uit, positioneert het systeem in de omgeving, en laat zien dat een systeem een doel heeft (‘mission’). De architectuurbeschrijving moet een rationale geven voor de architectuur, aan de ene kant gebaseerd op doel en omgeving en aan de andere kant op de mogelijke oplossingen.
IEEE 1471 gaat over architectuurbeschrijving in plaats van de architectuur zelf. Laten we hier het begrip architectuur definiëren als de manier waarop het systeem wordt ervaren en beleefd door de belanghebbenden. Het onderscheid tussen architectuur en architectuurbeschrijving verschaft dan een interessant inzicht. De architectuur is oneindig, rijk en ongrijpbaar. De architectuurbeschrijving is een projectie, een extractie van deze rijke architectuur in een platgeslagen, armere, maar tastbare beschrijving. Deze beschrijving wordt gedeeltelijk gemaakt door de architect(en), maar ook alle andere projectleden schrijven delen ervan. Zo’n beschrijving is heel bruikbaar om te communiceren, te discussiëren, te besluiten, te verifiëren et cetera. Het is wel belangrijk in gedachten te houden dat de beschrijving slechts een beperkte benadering van de architectuur zelf is. Het architectuuroverzicht (zie kader) is weer een klein deel van de architectuurbeschrijving.
Gerrit Muller is verbonden aan het Embedded Systems Institute te Eindhoven (gerrit.muller@embeddedsystems.nl).
NK ICT-Architectuur
Een architectuuroverzicht is een onderdeel van een volledige architectuurbeschrijving. Het overzicht is bedoeld voor alle betrokkenen. Het bestaat uit zowel visuele als tekstuele informatie. Het overzicht moet onder de twintig pagina’s blijven, met maximaal twee pagina’s meta-informatie, omdat meer meta-informatie afleidt van de feitelijke architectuur. De beperking tot twintig pagina’s garandeert dat alle belanghebbenden in korte tijd het overzicht tot zich kunnen nemen, en zij dwingt de architect tot het selecteren van de inhoud: de essenties van het systeem en de belangrijkste boodschappen.
De doelen van een architectuuroverzicht zijn:
• focus op klant en bedrijfsdoelstelling;
• richtinggevend voor het projectteam
• inzicht in belangrijke keuzes en risico’s;
• aandacht voor zaken die over organisatorische grenzen heen gaan.
Architectuuroverzicht
De standaard IEEE 1471 introduceert een aantal belangrijke concepten:
· Stakeholders; mensen of organisaties die een belang hebben bij het systeem.
· Concerns; een articulatie van de behoeftes en de zorgen van stakeholders.
· Viewpoints; de gezichtspunten die gebruikt worden om een deel van het probleem of de oplossing te beschrijven. We negeren hier het subtiele verschil dat IEEE 1471 maakt tussen ‘views’ en ‘viewpoints’.
· Models; een middel dat veelvuldig wordt gebruikt om het probleem en de oplossing te beschrijven.
· Architectuurbeschrijving; de combinatie van stakeholders, concerns, viewpoints en models om de architectuur van een systeem te beschrijven.
Standaard 1471
Dit jaar wordt voor de derde keer het Nederlands Kampioenschap ICT-Architectuur gehouden, zie www.nkictarchitectuur.nl. De uiterste inzendingsdatum voor architectuurbeschrijvingen is 15 oktober 2006.
Het NK ICT-Architectuur heeft in 2004 elf inzendingen en in 2005 vier inzendingen opgeleverd, die in meerderheid een architectuuroverzicht waren. Deze zijn openbaar toegankelijk.