Home Architectuur Agile-ontwikkeling heeft Jan des Bouvrie nodig

Agile-ontwikkeling heeft Jan des Bouvrie nodig

79

De IT-architect vervult een onmisbare rol bij het creëren van een hoogwaardig, integraal en beheersbaar systeemlandschap. Hij is degene die het grotere geheel overziet en die bepaalt hoe de afzonderlijke applicaties ontworpen dienen te worden zodat ze passen in het complexe geheel van informatiesystemen.

Kenmerkend voor een architect is dat hij de eisen van de opdrachtgever omzet in een globaal ontwerp ten behoeve van de technisch specialisten, die het gedetailleerde ontwerp en de bouw moeten uitvoeren.
Architecten vervullen een bemiddelende rol tussen de stakeholders. Ze zijn de intermediair tussen opdrachtgever en de bouwer die in een creatief proces wensen vertalen naar mogelijke oplossingen. Ze buigen zich in principe over beleving en structuur van ‘hun’ product. Om de functie-inhoud, de rol en de plaats van een IT-architect te duiden, wordt vaak een vergelijk gemaakt met de ‘echte’ wereld. Het verschil tussen de diverse architecten zit ‘m vooral in het abstractieniveau en het eindproduct waar zij uitspraken over doen.

Over het algemeen wordt verwezen naar een stedenbouwkundige als het gaat om een enterprise- of domeinarchitect en naar een gebouwarchitect als men het heeft over een systeemarchitect. Een stedenbouwkundige houdt zich net als een enterprisearchitect in eerste aanleg bezig met de grote lijnen van een ontwerp. Ze zijn vooral kaderzettend en planmatig bezig, maar nemen ook de details mee, als die van belang zijn voor de werking van een afzonderlijk deel of het geheel der delen. De gebouwarchitect en de systeemarchitect op hun beurt, moeten een concrete architectuur neerzetten waar de bouwers op eenduidige wijze mee uit de voeten kunnen.

Met de opkomst van Agile als ontwikkelmethode, is het belang van een goede architectuur nog groter geworden dan het al was. Agile is namelijk een beetje een naar binnen gericht proces, waarbij er vooral aandacht is voor het systeem en de gewenste functionaliteit. Hierdoor is er niet of nauwelijks aandacht voor de bedrijfscontext, of architectuur, waarin de applicatie moet draaien. Om te voorkomen dat er uiteindelijk een applicatie staat die los van de omgeving functioneert, is het belangrijk dat voordat begonnen wordt met de bouwfase eerst een stapje terug wordt gedaan en er een globaal procesmodel en gegevensmodel wordt opgesteld. Op deze manier wordt inzichtelijk, binnen welke bedrijfscontext de applicatie moet functioneren, wat de interfaces met andere systemen zijn én welke ‘business value’ de applicatie creëert.

Dit is wat ik Architected Agile noem en wat mijns inziens tot het takenpakket van de enterprise-architect behoort. Vervolgens is het de beurt aan de systeemarchitect om op hoofdlijnen de functionaliteit van het te ontwikkelen systeem in kaart te brengen. Hij zorgt voor een basis op hoofdlijnen die je kunt vergelijken met de fundering, het raamwerk en het aanzicht van een gebouw. Het omvat ook een globale indeling van de ruimtes. Dit is allemaal het werk van een gebouwarchitect. Het systeem is al wel in beton gegoten, maar daarmee is het gebouw nog niet gebruik- of bewoonbaar, net als een systeem bij Agile-ontwikkeling op dit punt nog niet af is.

Met de Agile-ontwikkelmethode is er ook een nieuwe dimensie aan het begrip van IT-architect toegevoegd. En wel die van interieurarchitect, om maar weer het vergelijk te maken met de ‘echte’ wereld te maken. Agile richt zich op een flexibele manier van softwareontwikkeling waarbij de specificaties en het eindresultaat niet tot in detail van te voren worden vastgelegd. De eisen en wensen kunnen tijdens het ontwerpen voortdurend veranderen. Agile vraagt een intensieve communicatie tussen de ontwikkelaars en de klant. Dit is vergelijkbaar met hoe een interieurarchitect te werk gaat bij het inrichten van een gebouw of ruimte. Dit gebeurt ook in intensieve interactie met de klant, waarbij door de interactie steeds nieuwe inzichten ontstaan en de eisen en wensen ten aanzien van de uiteindelijke inrichting voortdurend veranderen. Zoals het bij het inrichten van een ruimte eenvoudig is om zaken aan te passen, meubels te verschuiven, accenten ergens anders te leggen en de volgorde van handelingen te veranderen, kan bij de Agile-methode eenvoudig functionaliteit worden aangepast, met blokken technologie worden geschoven, prioriteiten ergens anders worden gelegd en stukken functionaliteit in een andere volgorde worden ontwikkeld. Bij Agile-ontwikkelprojecten moeten ze kortom op zoek naar de Jan des Bouvrie onder de architecten.

Eric ten Harkel, directeur van COOLProfs

2 REACTIES

  1. Goed artikel wat inderdaad een veel voorkomend probleem beschrijft. In het algemeen ben ik het met de strekking eens echter ik onderscheid 3 niveaus:
    1- Enterprise Architect:
    Verantwoordelijk voor de omgeving waarin de functionaliteit moet functioneren, basis (data) interfaces, etc. Dus veel business impact visie.
    2- IT architect:
    Het hele raamwerk van van IT methodieken, (coding) standards, omgeving keuze (b.v. OS, platform, coding taal, dbms, etc.)
    3- Systeemarchitect/Analist:
    Het vertalen van de gebruikerswensen in de globaal ontwerp binnen het raamwerk wat door de IT-architect is vastgesteld.

    Reden om het verschil te maken in de 2 architecten rollen is dat de enterprise architect niet een IT’er hoeft te zijn. Hij moet natuurlijk wel inzicht hebben in welke applicaties welke busines processen implementeren.

    Ook in een Agile methodiek kan het niet zo zijn dat niet eerste een soort globale visie van het totale project wordt gemaakt (dit is ook nuttig voor het datamodel). Dit laat onverlet dat de volgorde van implementatie en uiteindelijk of deelfunctionaliteit wordt geïmplementeerd in de methodiek dynamisch wordt bepaald.

    Om terug te komen op de titel, Jan de B hoeft ook niet zelf exact elk kastje of stoel van een inrchting te bepalen, maar wel de stijl van ’t geheel.

  2. Goede aanvulling, Rob.
    Denk wel dat een Architect die, op welk niveau dan ook, iets meent te moeten zeggen over (ondersteuning door) IT van die IT verstand moet hebben. Niet per se over de details, maar een beetje inzicht in wat IT en softwarebouw eigenlijk is kan nooit kwaad. Want, zoals mijn oma altijd zei: “Inspraak zonder inzicht leidt tot uitspraak zonder uitzicht”

LAAT EEN REACTIE ACHTER

Vul alstublieft uw commentaar in!
Vul hier uw naam in