Webwereld is op zoek naar de beste IT architect van Nederland. Tot volgende week woensdag kun je jezelf of een collega nog inschrijven. De kandidaten zullen worden beoordeeld door een vakkundige jury. Een van de juryleden is Michael Widjaja, Master Technology Architect en partner bij Accenture. Hij legt uit wat architectuur voor hem betekent.

Drie rollen

Als je het over architectuur hebt, dan moet je rekening houden met een aantal factoren. Aan de ene kant is er een focus op de kwaliteit van je oplossing, op de voorspelbaarheid en beheersbaarheid. Men zoekt naar simplificatie en structuur. Aan de andere kant zie je dat het IT-landschap almaar complexer wordt, wat ook wordt versterkt door de verschillende wensen vanuit de business. Je ziet dat de eindgebruikers meer verwachten. Ze willen snellere responsetijden en flashier schermen. Tot slot zie je dat men kostenbesparingen wil doorvoeren en daar ligt heel sterk de nadruk op.

Dat zijn een groot aantal factoren waarmee je rekening moet houden bij het bouwen van de oplossing, en daar spelen architecten een onmisbare rol in. Zij moeten al die factoren mee laten wegen. Dat betekent dat ze drie rollen vervullen. Ze moeten de advocaat zijn van al deze wensen en de balans in de gaten houden tussen verschillende partijen, de kosten, de eindgebruikers, de business, de techniek, de kwaliteit en de beheersbaarheid. Anderzijds moeten ze de oplossing kunnen ontwerpen die voldoet aan de eisen die voor zo'n oplossing gelden. En als derde moeten ze als een soort uitvinder vernieuwingen in kunnen brengen, waardoor die oplossing ook echt gaat werken.

Architecten hebben dus die drie rollen. Ze zijn uitvinder, ontwerper en advocaat tegelijkertijd. Dat is de spagaat van de architect.

De goede balans

Er zijn verschillende definities van architectuur. Als je aan mij vraagt om een high level definitie te geven, dan zou ik zeggen dat IT architectuur een framework is, waarbij je structuren en richtlijnen afspreekt waar je oplossing aan moet voldoen. En die structuren en richtlijnen heb je in drie grote gebieden. Enerzijds moet je afspreken met welke componenten je je oplossing bouwt, met welke applicaties, welke databases en welke platformen. Dat is infrastructuurarchitectuur. Vervolgens maak je afspraken over hoe je je oplossing wilt beheren, de operationele architectuur. En tot slot maak je afspraken over hoe je je oplossing gaat ontwikkelen, welke tooling en ontwikkelmethodes je gaat gebruiken, dat is je ontwikkelarchitectuur. Het is aan de architecten om die drie lagen van het framework perfect op elkaar aan te laten sluiten.

Het doel van de architectuur is een beheersbare structuur over de hele enterprise die voldoet aan de functionele eisen en strategische wensen van het bedrijf. En daarbij moeten ook de kosten worden meegenomen. Zo'n structuur kost natuurlijk geld en daarin moeten keuzes gemaakt worden. De architectuur moet de juiste keuzes maken om te zorgen dat alle belangen behartigt worden in een goede balans.

Complexer landschap

20 tot 30 jaar geleden was architectuur iets gestructureerder dan nu. Toen had je monolitische oplossingen. Je had grote mainframes. Daarin was eigenlijk al uitgedacht hoe je de oplossing zou moeten bouwen en beheren. En er was ook gekeken naar voorspelbaarheid en beschikbaarheid.

Daarna is de architectuur geëvolueerd naar server-architectuur, waarbij je een serverdeel had en een client. Bovendien kreeg je een verdeling van verschillende applicaties, in verschillende applicatiesilo's die verspreid waren over de de verschillende afdelingen van een bedrijf. Het landschap werd nog complexer toen die verschillende silo's met elkaar verbonden moesten worden. Nu wil men bijvoorbeeld de supply chain verbinden met customer relation management systemen. Of men wil de supplie chain verbinden met het data warehouse. Daar komt integratieproblematiek uit voort die ontworpen moet worden.

Bovendien had je vroeger bij die monolitische systemen maar een beperkte keuze. Nu heb je veel meer variatie in je pakketkeuze en platformkeuze. Vroeger had je IBM mainframes, en dan maakte je een Cobol applicatie met een transactiesysteem. Maar nu heb je de keus uit verschillende softwarepakketten, Oracle, SAP, Microsoft. En je kunt kiezen uit verschillende platformen waar je het op installeert. Je kunt kiezen uit Unix, Linux en Windows. Je hebt verschillende middleware lagen en daar heb je ook weer de keuze uit zes of zeven grote leveranciers. Je ziet dus waar je vroeger een eenduidige keus had, heb je nu een veel grotere variëteit. Bovendien lag vroeger de focus op één enkele silo, terwijl we nu over het hele bedrijf heen kijken en al die silo's met elkaar willen verbinden.

Op de voorgrond

In het verleden heeft men architectuur als minder belangrijk gezien, als een zijpoot. Dan hebben we het over meer dan vijf jaar geleden. Ik denk dat de architectuur een heel grote stap heeft gezet met een aantal IT-trends die populair zijn geworden, zoals Service Oriented Architecture. SOA heeft de business en de IT bij elkaar gebracht. Vroeger gingen we heel erg uit van een IT-perspectief, met erg technische architecturen en heel erg technische frameworks. Toen was er eigenlijk heel weinig overleg met de business of met functionele afdelingen. Met de opkomst van SOA en BPM oplossingen, waar bij de oplossing heel erg sterk gekeken wordt naar de functionele eisen en waarbij die functionele eisen ook veel sterker afgespiegeld worden in de technische componenten, is de architectuur veel meer in het daglicht komen te staan.

En dat komt nu weer in andere vormen naar boven en voortaan wordt de architectuur ook meegenomen in de discussies. In de laatste vijf jaar is men tot de conclusie gekomen dat de onderliggende IT-architectuur heel veel business oplossingen kan ondersteunen. Men ziet er het belang van in. SOA heeft wat dat betreft echt als een katalysator gewerkt.

Skelet

Architectuur is te vergelijken met het skelet van een huis. De business heeft zijn wensen, hoeveel ingangen, hoeveel ramen, hoeveel kamers ze in het huis willen hebben. Daar moeten we als architecten voor zorgen. Maar architecten moeten niet alleen aan de korte termijn denken. Ze moeten er bijvoorbeeld ook rekening mee houden dat er later nog meer verdiepingen op het huis moeten komen. Dan moet het skelet wel zo in elkaar zitten dat het niet helemaal herbouwd hoeft te worden, wat weer extra kosten met zich meebrengt. De laatste jaren ziet men steeds meer in dat het skelet van dat huis dus inderdaad cruciaal is om flexibeler je business te kunnen voeren. Als je eenmaal een goed skelet hebt staan, dan kun je daar snel andere dingen mee doen. Je krijgt een stabielere oplossing en je kunt je oplossing sneller uitbouwen als dat nodig is. Dat is makkelijk, goedkoop en efficiënt.

De beste architecten kunnen de belangen van de verschillende partijen behartigen en zijn daardoor in staat het juiste skelet te bouwen. Bron: Techworld