• It Architectuur Amersfoort

  

  • Home
  • Publicaties
  • Blog
  • Effectieve architectuur in een agile context

Effectieve architectuur in een agile context

29 april 2019

Enterprise-architectuur en agile ontwikkeling zijn inmiddels gebruikelijke praktijken, maar de combinatie van beiden blijft een onderwerp van discussie. Enterprise-architecten die zich blijven houden aan hun eerdere aanpak, houding en gedrag komen bedrogen uit. De wereld draait ook zonder hen door. Het is duidelijk dat de combinatie vraagt om iets anders, maar een goede balans vinden tussen lange termijn planning en korte termijn resultaten is voor architecten niet eenvoudig. Een aantal ervaren architecten en managers hebben gezamenlijk een inspiratiesessie gehad over het onderwerp en gezocht naar gemeenschappelijke inzichten. Dit blog item beschrijft het resultaat van de sessie en geeft er een verdere betekenis aan.

Gedrag versus inhoud

agileeaIn de eerste gedachtewisseling tussen de deelnemers werd al duidelijk dat een overgroot deel van het effect van een architect wordt bepaald door zijn of haar gedrag boven de inhoud. Het is de rol van de architect om anderen te beïnvloeden zodat zij doen wat wenselijk is. Tegelijkertijd geldt dat een belangrijk deel van de toegevoegde waarde van een architect ligt in het bieden van structuur en dat vastlegging van deze structuur daarvoor randvoorwaardelijk is. Een architect die alleen praat zal daarom onvoldoende effectief zijn.

Eigenschappen van effectieve agile architecten

In een eerste werkvorm is gezocht naar kritische succesfactoren voor architecten die effectief willen opereren in een agile context. Hieruit volgenden de volgende eigenschappen.

Een duidelijk doel en een duidelijke visie

Een agile ontwikkeling dient naar een duidelijk doel te bewegen en het is de rol van de architect om dit inzichtelijk en concreet te maken, voor zover dat nog niet het geval is. Een doel dat duidelijke waarde levert voor de organisatie, maar dat tevens voldoende vrijheid biedt om bij te sturen; een meerjaren streefdoel. Het kunnen bereiken van dat doel vraagt om een integrale architectuurvisie die duidelijk maakt wat daarvoor nodig is. Tegelijkertijd moet ook de visie ruimte laten om steeds nieuwe inzichten op te doen, te leren, bij te sturen en dus de uiteindelijke oplossing nog niet helemaal vastlegt.

Denken in tussenstappen

Het is duidelijk dat het doel niet in één keer gehaald kan worden en dat nieuwe inzichten tot andere routes zullen leiden. Het doel en de visie zullen daarom ontleedt moeten worden in kleinere behapbare waardevolle tussenstappen. Denk daarvoor in minimum viable products die realistisch zijn. Voorkom teveel kortzichtigheid; houdt rekening met wat logische stappen zijn.

Net genoeg architectuur

De architectuur zelf hoeft in een agile context minder ver te worden uitgewerkt en kan globaler en meer schetsmatig zijn. In een agile context geldt dat werkende oplossingen belangrijker zijn dan de beschrijving ervan (documentatie). Mensen hebben ook steeds minder zin om nog dikke pakken (papier) te lezen; het is al snel “too long to read”. De kunst daarbij is om die dingen op te schrijven die echt belangrijk zijn; de keuzes die bepalend zijn. Een agile architectuur moet overigens wel de doelstellingen, capabilities, principes en diensten beschrijven.

Emergente architectuur

De architectuur is ook niet helemaal vooraf te bedenken. Je moet ook kunnen uitproberen of dingen werken en verrast worden door dingen die anderen bedenken. Het is dus niet nodig dat de architect alles bedenkt en kiest. Het is belangrijker dat een omgeving ontstaat waarin de juiste inzichten en keuzes ontstaan. Om de ontwerpruimte toch wat in te perken helpt het om te denken in patronen. Denk bijvoorbeeld aan iets als een microservice patroon; ontwikkelaars weten direct wat je bedoelt, maar willen ook de vrijheid om te bepalen hoe een specifieke microservice precies werkt.

Communiceren en verbinden

Architectuur gaat voor een belangrijk deel over het verbinden van mensen en teams. Dat vraagt open communicatie, waarbij er alle ruimte is voor eenieder om denkbeelden in te brengen. Vriendelijkheid, empathie en assertiviteit stimuleert dit soort communicatie. Daarnaast is belangrijk dat de architect beschikbaar en aanspreekbaar is, voor zowel teams als stakeholders zoals bijvoorbeeld de directie. Als verbinder zal de architect moeten zorgen dat er (inhoudelijke) consensus komt.

Tonen leiderschap

Alhoewel verbinden zorgt voor maximale betrokkenheid en draagvlak is het ook belangrijk dat er inhoudelijke keuzes worden gemaakt. Daarbij zul je moeten accepteren dat je niet iedereen meekrijgt, mensen je soms niet aardig zullen vinden en dat de tijd voor discussie ook een keer op is. De architect zal daarom leiderschap moeten tonen, geloofwaardig zijn en anderen kunnen overtuigen. Een uitdaging daarbij is de besluitruimte van de architect en tevens het vertrouwen dat de opdrachtgever en management heeft in de architect.

Fundamentele verschuivingen

In andere werkvormen is gezocht naar verschuivingen in architectuur; wat zal in een agile context meer of minder relevant zijn. We hebben zowel gekeken naar de architectuurinhoud (wat beschrijft een architect) als de activiteiten (wat doet een architect). Hieruit kwamen de volgende fundamentele verschuivingen naar voren.

Meer aandacht voor doelstellingen en capabilities

Het is minder belangrijk hoe oplossingen er precies uitzien, zolang deze passen bij het doel. Het concreet krijgen van dit doel, de waarde die dat creëert voor stakeholders en de capabilities die het vraagt is belangrijker in een agile context. Doelstellingen zijn vaak niet vantevoren eenduidig vastgelegd en vraagt daarom expliciete inspanning van de architect, inclusief het begrijpen van de ontwikkelingen die eraan ten grondslag liggen. Capabilities benoemen wat de organisatie en de systemen moeten kunnen, zonder uit te leggen hoe.

Van eisen naar principes

Er worden in een agile context geen gedetailleerde programma’s van eisen meer beschreven. Er is veel meer keuzevrijheid in teams. Principes kun je zien als meer abstracte eisen, die wel richting geven maar tevens bewegingsvrijheid bieden. Het formuleren van principes is daarmee toenemend belangrijk voor architecten. Principes zijn richtinggevende uitspraken die een oplossingsrichting schetsen, zonder te beschrijven hoe de oplossing zelf er precies uit ziet.

Van oplossingsdomein naar probleemdomein

Doordat het minder belangrijk is hoe de oplossing er precies uitziet, zal de architect dat ook niet meer hoeven te modelleren. Denk bijvoorbeeld aan welke apparaten worden gebruikt of hoe de technologie precies werkt, maar denk bijvoorbeeld ook aan het ontwerp van het proces. Het moet wel duidelijk zijn welk probleem moet worden opgelost en hoe het probleemdomein er uit ziet. Het modelleren van de concepten en de diensten die moeten worden geleverd is wel relevant.

Meer nadruk op integratie

De oplossing en daarmee de interne constructie van systemen is minder relevant geworden om te beschrijven. Daarmee verschuift de aandacht naar integratie van systemen. Het is belangrijk om snel inzicht te creëren in de koppelvlakken (API’s) en de data die wordt uitgewisseld. Deze kunnen sterk bepaald zijn door vooraf gedefinieerde contracten of afspraken, die dan een leidende rol vervullen.

Meer begeleiden en coachen

Architecten zullen minder vooraf en meer gedurende ontwikkeling betrokken zijn. Omdat vooraf minder bekend is zullen zij meer op de werkvloer aanwezig moeten zijn om te ondersteunen bij de verdere uitwerking en helpen oplossen van lacunes. Aangezien architecten veelal ervaring en senioriteit inbrengen, zullen zij daarbij al snel een meer inhoudelijk begeleidende en coachende rol vervullen. Toetsing zal nog steeds relevant zijn, maar is meer ondersteunend dan formeel.

Tenslotte

Het is duidelijk geworden dat enterprise-architectur in een agile context echt anders moet. Er moet meer ruimte zijn voor teams om invulling te geven aan keuzes. Doelen en visie zullen bijstelling vragen en de architect wordt meer een coach en begeleider. Een blauwdruk voor hoe het precies moet werken hebben we niet opgesteld en is ook niet wenselijk. Wij willen alleen de principes schetsen waarbinnen anderen hun eigen keuzes kunnen maken.

Danny Greefhorst (Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.) is directeur en principal consultant bij ArchiXL

Met dank aan Bas Crompvoets, Anton van Weel, Fernand Rouwendaal, Hans Guldemond, Andre Schrander, Tony Sloos en Manuel Rejen voor hun bijdragen in de inspiratiesessie.

Social Bookmarks

Reacties (10)

  • hans.konstapel 29 april 2019 op 22:53 | #

    Ik ben geruime tijd dhoofd geweest van het gegevensbeheer van de ABN.Tot de gegevens behoorden ook de meta-gegevens.Het beheer van de architectuur was gebaseerd op de macht die aan ons was verstrekt door de Raad van Bestuur. Wij keurden proces- en dataarchitecturen goed (of af) en gaven opdracht tot bouwen en in productiename. Om onze taak dat goed te kunnen doen maakten we gebruik van een eigen ontwikkelde datadictionary-applicatie(ADA) gebaseerd op het pakket Datamanager. De architectuur groeide door de projecten die werden gedaan. Het bedrijfsmodel (data & proces) ontstond stap voor stap. De fusie van ABN & AMRO gaf een groot probleem omdat de AMRO een eigen beheerproces had gebaseerd op de IB-Mdictionary en een een nder meta-model hanteerde. Daarnaast was het meta-model niet volledig en in overeenstemming van de realisatie Het lukte niet om de beide modellen te fuseren omdat de software soms niet paste op het model. Om dat recht te trekken hadden we bij de ABN AMRO een nieuw soort dtictionary gekocht fenaamd Rochade. Rochade had een speciale functionaliteit waarmee je software en databases kon laden waarna de modellen automatische wuit elkaar werden gehaald. Die aanpak bleek naderhand erg succesvol te zijn. De dictionary (of beter repository) werd niet meer met de hand gevuld maar de meta-data werd gescand, geherstructureerd en weer gegeneeerd. Het scannen werd verbeterd door gebruik te maken van een meta-parser die bij het CWI was ontwikkeld. Hier is het bedrijf SIG uit ontstaan.Naderhand is de aanpak van SIG verbeterd en ondergebracht bij het bedrijf wat we nu Alchemist noemen.
    Het grote voordeel van onze aanpak is en was dat je oude en nieuwe delen van de aechitectuur kunt administreren en hersstructureren en weer kunt genereren zelfs naar een nieuw platform en er dus helemaal geen bedrijfs-architecten nodig hebt die hun visie moeten verkopen. Die zijn in wezen geautomatsieerd door Alchemist. Het enige wat overblijft is management in de zin van een opdrachtgever en een functie die onderzoekt doet naar behulpzame platformen waarna de oude architectuur kan worden gegenereerd.

    antwoord

    • Danny Greefhorst 30 april 2019 op 06:39 | #

      Hallo Hans,
      Ik denk dat wat jij beschrijft zondermeer interessant is om inzicht te krijgen in de huidige architectuur (en implementatie) maar dat het je maar beperkt helpt in het bepalen wat de gewenste architectuur zou moeten zijn. Een visie is het resultaat van een denkproces waarin allerlei aspecten en argumenten met elkaar worden omgevormd tot uitspraken over wat wenselijk is. Daarnaast probeert deze blog juist allerlei zaken te benoemen die niet gaan over de inhoudelijke architectuur, maar meer over houding en gedrag van de architect. Uiteindelijk zal met kunstmatige intelligentie best meer van de architect te automatiseren zijn, maar op de korte termijn verwacht ik daar nog niet zoveel van.
      Mvgr,
      Danny

      antwoord

  • hans.konstapel 30 april 2019 op 11:51 | #

    Ik ben het eigenlijk helemaal niet me je eens. Ik vermoed dat het verschil in visie te maken heeft met het verschil in kennis en ervaring die weer zijn gebaseerd op een visie op besturen die weer is gebaseerd op de wijze waarop het "architectuurbeheer" was georgansieerd bij de ABN. Architectuurbeheer was een vorm van AO (Adminstratieve oOganisatie): https://nl.wikipedia.org/wiki/Administratieve_organisatie
    Het lijkt er op dat dit vakgebiied is verdwenen waardoor begrippen als "beheer" geen inhoud meer hebben.

    Het tweede verschil heeft te maken met de problemen die ik heb moeten oplossen die weer zijn veroorzaakt door een enorm complexe fusie.
    Het porsitieve gevolg hiervan was dat er hulpmiddelen moesten worden ontwikkeld die het mogelijk maakten om minstensn twee organisaties in kaart te brengen terwijl ze voorlop in ontwikkeling waren ("een rijdende trein") en waarvan verwacht werd dat ze een eenheid zouden worden. Dat kun je doen door inhoudsvolle objecten te verzamelen en hun structuur te bepalen. je brengt dat ik kaart wat er qua communicatie plaatvindt en gaat er vanuit dat het organisme zich toont door zijn communicatie.

    antwoord

  • hans.konstapel 30 april 2019 op 21:04 | #

    Ik ben benieuwd naar je reacie. In detyssentijd zal ik nog een beetkje commentaaar geven. Het lijkt er op dat de architect een losstaande persoon is die op slimme wije bezig is om de organisatie te beinvloeden om een goede kant op te gaan. Dit idee doet tekort aan allerlei andere rollen zoals de financiele functie, de marketing en het bestuur dat er is om alles samen te laten werken. Ik denk dat deze rol erg veel lijkt op de rol die jij op architect plakt. Is een architect een soort revolutionair die via een soort reverse takeover de onderneming overneemt. Is hij/zij op zoek naar macht en loopt daardoor over zowat alles heen wat past op het personeel en zorgt voor de klanten. Moet de architect de aandeelhouders helpen om meer rendement te halen?

    antwoord

  • Danny Greefhorst 30 april 2019 op 22:33 | #

    Hi Hans
    Het is wat lastig te begrijpen wat jij onder de rol van de architect verstaat op basis van wat je schrijft. Zoals je voorstelt op LinkedIn lijkt me een fysieke bijeenkomst een betere manier om elkaar te begrijpen. Gewoon inplannen? Samen voorbereiden?
    Overigens kijk ik maar een beperkt aantal keer per dag op deze blog en stond automatische goedkeuring ook uit waardoor interactie wat minder snel gaat dan jij wellucht verwacht.
    Mvg
    Danny

    antwoord

  • hans.konstapel 01 mei 2019 op 10:32 | #

    Beste Danny: Met behulp van Paths of Change (POC< jouw bekend: https://constable.blog/2018/03/08/over-anti-fragility/ (zie hfdst 4 in de blog) kun je een 12-tal basis-functie maken door Wereldbeelden te combineren. Ik vind dat een architect iemand is die Mythic & UNity combineert. Hij/zij koppelt "zien" ("in-in-zicht") aan waarheid ("een geheel", eenheid). De mythic-Unity-combinatie wordt ook wel ont-werpen genoemd waarbij ont lostlaten betekent. Je laat het gene dat he werp los. Wat je werp is een "beeld". Architectecten hebben een NT-Myersbrigss-profiel. Het zijn zieners (visonairs) die hun zicht in een schema onderbrengen,

    antwoord

  • Danny Greefhorst 01 mei 2019 op 19:52 | #

    Dat sluit aan bij mijn beeld. Lijken we het toch met elkaar eens te zijn.

    antwoord

  • Guestfoubs 03 oktober 2019 op 00:04 | #

    online dating first email subject line dating sites horsham celebs go dating charlotte dating millionaire uk astros pitcher dating model how to move online dating offline verify hookup chassis hook up dating sites dar es salaam gute dating seite

    antwoord

  • Guestfoubs 04 oktober 2019 op 11:40 | #

    delete clover dating app account dating in vancouver wa what to do when your ex girlfriend starts dating someone else hookup pin dating robin hood coc builder base matchmaking ich bin dating dating a southern girl reddit hook up quick how to avoid dating another narcissist

    antwoord

  • Guestfoubs 04 oktober 2019 op 11:45 | #

    a good headline for dating site best dating sites latin america dhaka dating singles how can relative dating and absolute dating be used together sample online dating profile female good intros for dating sites zimbabwe dating site cape town hook up charters hookup culture in spanish best dating websites for 18 year olds

    antwoord

Plaats een reactie

U plaatst een reactie als gast

Contact

ArchiXL B.V.
Nijverheidsweg Noord 60-27
3812 PM Amersfoort

Telefoon: 033 258 5545

E-mail: info@archixl.nl

   

Nieuwsbrief

Wil je op de hoogte gehouden worden van nieuws en ontwikkelingen binnen ArchiXL?

Aanmelden voor de nieuwsbrief