'The best architectures, requirements and designs emerge from self-organizing teams', is wellicht het meest misbruikte principe uit het Agile Manifesto. Door de jaren heen was de gangbare interpretatie van dit principe verworden tot: 'Hoe minder je nadenkt over de toekomst, hoe beter je systeem wordt.” Het was de afgelopen tien jaar in de software-ontwikkeling niet bon-ton om het over architectuur te hebben. Maar het tij is langzaam aan het keren.
Modelleren wordt weer oogluikend toegestaan – zij het soms achter gesloten deuren, om het stigma ‘Big Up-front Design’ te vermijden. We durven het nog nauwelijks hardop architectuur te noemen, dus ontstaan er eufemismen als ‘Design thinking’ en ‘Master builder’. Maar het besef dat een beetje anticipatie in je systeemontwerp noodzakelijk is om risico’s beheersbaar te houden is nu wel doorgedrongen, getuige bijvoorbeeld het concept van de ‘Architectural Runway’ in het steeds populairder wordende Scaled Agile Framework.
Het is dus weer veilig voor ons, de anticiperende ontwerpers in de digitale wereld, om voorzichtig uit de kast te komen en ons bekend te maken als bijvoorbeeld enterprise-architect, solution-architect of software-architect. Daarmee is het ook tijd om de balans op te maken: wat staat ons te wachten, wat speelt er in het land van de digitale architectuur? Hieronder een korte inventarisatie van de belangrijkste trends en ontwikkelingen.
Digitale transformatie
Nieuw opkomende technologieën vermenigvuldigen en transformeren in toenemende mate de kanalen waarmee organisaties, personen en ‘dingen’ (in het ‘internet of things’) met elkaar verbonden zijn. Gebruikers en organisaties verwachten dat deze connecties voldoen aan hoge eisen op het gebied van tijdigheid (‘near realtime’) en consistentie, naar voorbeeld van organisaties als Amazon en Google.
De verandering die organisaties moeten doormaken om deze technologieën te integreren wordt digitale transformatie genoemd. Bij digitale transformatie is het grootste probleem vaak het omvormen van de bestaande ict-landschappen. Het bestaande landschap wordt vaak als zo belemmerend ervaren, dat organisaties het soms makkelijker vinden om een compleet nieuwe ‘digitale afdeling’ op te richten, waar de bestaande ict-afdeling zich niet of nauwelijks mee mag bemoeien.
Architectuur speelt een belangrijke rol bij het anticiperen op deze transformatie, en enterprise- en solution-architecten doen er goed aan zich te verdiepen in dit onderwerp.
Ecosysteem-architectuur
Bij veel bedrijven en instellingen wordt ‘samenwerking over de grenzen van de eigen organisatie heen’ een steeds belangrijkere business-prioriteit. Met de toenemende connectiviteit en digitalisering neemt ook de onderlinge afhankelijkheid tussen instellingen, bedrijven, personen en ‘dingen’ toe. Om deze afhankelijkheden te beheersen is het van belang een integrale visie te ontwikkelen op de verbindende concepten in het waarde-netwerk: de ecosysteem-architectuur.
Gartner stelt bijvoorbeeld dat het modelleren van business-ecosystemen steeds belangrijker wordt voor organisaties om hun rol in het waarde-netwerk te begrijpen en te kunnen herdefiniëren. Architecten verbreden hun scope van de eigen organisatie naar het modelleren van de informatie en interactie binnen het gehele ecosysteem.
Open data en gefedereerde datamodellen zijn essentiële smeermiddelen voor soepele interacties in het business-ecosysteem. Naast deze statische modellen is het vooral belangrijk de dynamiek binnen een ecosysteem-architectuur te begrijpen, om met de steeds sneller optredende veranderingen om te kunnen gaan.
Wendbaarheid
In de moderne aanpak van architectuur verschuift de balans van ‘zware’ doel-architecturen naar ‘precies genoeg architectuur’. Gedwongen door de steeds sneller veranderende business- en technologische context, worden elementen uit het Agile gedachtengoed verweven in de wijze waarop architectuur bedreven wordt.
Transformaties richting doelarchitectuur vinden in steeds kleinere (beter beheersbare) stappen plaats, en architecten zijn nauwer betrokken bij de uitvoering. Door gebruik te maken van Agile architectuur-practices kunnen architecten sneller inspelen op veranderingen, en samen met belanghebbenden de juiste balans bepalen tussen architectuurverbeteringen, innovaties, functionele uitbreidingen en het onder controle houden van technische schuld.
Architectuur gaat daarmee steeds minder over de ‘stip op de horizon’, en steeds meer over de weg daar naartoe. Deze trend wordt door veel organisaties belangrijk gevonden, en uit zich in ontwikkelingen als het Scaled Agile Framework, en ons eigen architectuuraanpak Risk- and Cost-Driven Architecture.
Service-gerichte architecturen
Grote ict-moderniseringstrajecten blijken in de praktijk bijzonder riskant. Organisaties zijn daarom steeds meer op zoek naar architecturen die kleine, beheersbare projecten mogelijk maken. Dit is één van de doelen van service-gerichte architecturen (sga): flexibiliteit creëren door de afhankelijkheid tussen aanbieders en afnemers van diensten te minimaliseren. Deze sga’s worden steeds volwassener, en maken steeds betere ontkoppeling, componentisering en standaardisering mogelijk.
In een modern ict-landschap worden applicaties samengesteld door standaard componenten als case-management systemen, rules engines en workflow engines te orkestreren met behulp van standaard infrastructuur (esb, PaaS). In plaats van grote, specialistische pakketten die moeilijk te vervangen zijn, kiest men voor standaard-componenten die voor meerdere bedrijfsfuncties ingezet kunnen worden, met zoveel mogelijk open source software.
Architectuur speelt een belangrijke rol in het beheersen van de complexiteit van een dergelijk landschap, en service-gerichte architectuur is cruciaal. In de software-architectuur vormen micro-services de nieuwste manifestatie van deze trend. In infra-architectuur zien we de trend terug in steeds geavanceerdere cloud-platformen, waarbij de cloud-diensten op een steeds hoger niveau in de applicatiestack gestandaardiseerd geleverd worden. De ict-nfrastructuur van een organisatie bevindt zich daardoor voor een deel vaak in de cloud. De architectuur moet dus openingen, maar ook controls bieden om daarmee om te gaan.
De belangrijkste architectuurtrends
Dit zijn volgens onze bronnen de belangrijkste architectuurtrends voor de komende jaren: digitale transformatie, ecosysteem-architectuur, wendbaarheid en de nieuwe service-gerichte architecturen. Ze haken natuurlijk op elkaar in: de ecosysteem-architectuur ontstaat door de digitale transformatie, en de nieuwe service-gerichte architecturen zijn nodig om de wendbaarheid te realiseren die noodzakelijk is om die digitale transformatie te maken.
De vier trends laten ook zien dat architectuur wel degelijk veranderd is ten opzichte van vóór de Agile-revolutie: architecten doen er goed aan zich minder blind te staren op die stip op de horizon, en meer betrokken te zijn bij de weg ernaar toe. Op die manier ontstaat een architect-nieuwe-stijl die een sleutelrol gaat vervullen bij de transformatie van ons gezamenlijke digitale ecosysteem.
Bronnen:
CGI’s Voice of the Client programma, marktverkenning bestaande uit duizend interviews met cliënten in zeventien landen.
Gartner Predicts 2016: Five Key Trends Driving Enterprise Architecture Into the Future, 10 December 2015
scaledagileframework.com
Poort, E. R. Driving Agile Architecting with Cost and Risk. IEEE Software, September/October 2014
www.agilemanifesto.org
“Architectuur gaat daarmee steeds minder over de ‘stip op de horizon’, en steeds meer over de weg daar naartoe.”
Beter kun je het gebrek aan visie niet duidelijk maken.
Mieke Telkamp architectuur van waarheen leidt de weg.
Hoe bedien je een business die geen idee heeft wat ze willen ?
Met no-clue-driven-architecture natuurlijk. Who needs TOGAF ?
Gewoon een bouwdoos vol open micro-services voor als ze weer iets richtingsloos willen. Orkestreren zonder dirigent, want weet hij veel hoe het moet klinken. Zwaai de nieuwe stijl : Precies-genoeg-architecture voor de precies genoeg cultuur. Oordopjes in en we zien wel waar we heen gaan.
@Dino,
Zonder voor dhr. Poort te willen spreken lijkt het me dat je hier de plank misslaat. Het lijkt me dat de auteur hier wil aangeven dat de architect zich niet alleen maar moet bezig houden wat er voor nodig om bij die stip te geraken (en daarmee in de val van ‘Big Upfront Design’ te trappen).
De architect moet (met in het achterhoofd wel degelijk de uiteindelijke eindbestemming) met de inzichten van het moment, de juiste architecturele keuzes maken.
Ik geloof niet dat Dhr. Poort een uitspraak heeft gedaan over TOGAF of een andere architectuur-raamwerk. Als een business geen idee heeft wat ze willen helpt er ook geen architect aan; wat dat betreft is er geen nieuws onder de zon.
Als een architect maar wat aan gaat zitten archtectureren omdat de business toevallig op enig moment geen idee heeft wat ze willen lijkt het me dat het moment is gekomen dat de architect afscheid moet nemen. Tegelijkertijd lijkt het me dat de business zich achter de oren moet krabben of het nog wel zin heeft om door te gaan.
In een Agile omgeving weet een business het soms niet precies waar ze heen willen en dan heeft het zin om dit te verduidelijken met een demo of een prototype. Dat is het reguliere Agile proces dat wordt doorlopen om deze korte termijns onzekerheden te lijf te gaan. Maar dat sluit niet uit dat er toch een soort van overkoepelende, richtinggevende stem (entiteit, functie, geef het een naam) nodig is die voorkomt dat het bedrijf te maken krijgt met een explosie aan gekozen oplossingen die uiteindelijk de business geen meerwaarde geeft (het uiteindelijke doel van Agile, toch?).
Naar mijn idee geeft Dhr. Poort aan dat het nu het moment is gekomen om de mensen binnen een Agile team die richting geven aan een ontwikkeling gewoon weer meer te zien als een soort van architect (even los van exacte titelatuur). Dat kan ook gebeuren door een centraal persoon te benoemen die voor die teams als klankbord kan dienen om de oplossingsrichting te toetsen of te laten verifieren. Gewoon een architectenrol dus.
Cpt, Dino wil vooral humor brengen, toch zit er ook wel een kern van waarheid in….
“Modelleren wordt weer oogluikend toegestaan – zij het soms achter gesloten deuren, om het stigma ‘Big Up-front Design’ te vermijden”
Hier staat veel meer informatie in, niet alleen over de inhoud, maar ook over Eltjo en hoe hij tegen de wereld aankijkt.
Agile volgens architecten en architectuur volgens architecten bevinden zich op de uitersten van een schaal. Architecten (van gebouwen) worden niet ingehuurd omdat ze architectuur platen kunnen maken, maar voor de noodzaak iets goeds neer te zetten dat faalt zonder goede opzet.
Agile zonder enig inzicht in wat men wenst te verkrijgen is al net zo kansloos als een rigide big-up-front Design. Let wel, de nuance ligt op het woord “rigide”.
Modelleren is *altijd* een goed idee en modelleren kan ook agile 🙂 Het realiseren van (deel) implementaties van het model kan gewoon prima agile. Maar oplossingen bouwen zonder modelleren is alleen goed voor proof of concept of prototyping, als je een prototype in productie gaat nemen ga je een wereld van pijn tegemoet.
Kennismanagement / Business Process Management / Enterprise Architectuur heeft nooit echt voet aan de grond gekregen. Waarom niet? Omdat mensen het geen bal interesseert en mensen niet meegaan in de gedachten van anderen en met name architecten.
Rule #1 van enterprise architectuur is dat je nooit praat over enterprise architectuur.
Je moet gewoon dingen ontwerpen -modelleren als dat beter bekt- die aansluit op wat mensen prettig vinden. Een model in RAD of RUP spreekt niemand aan, dan zijn agile user stories een veel beter middel.
Architectuur en Agile gaan *prima* samen. Je kunt ook prima geloven in God en de Evolutie theorie, alleen als je de Bijbel letterlijk neemt gaat het mis. (Deuteronomium 23:1)
Nu even niet beginnen over de aanhoudende crisis in Enterprise Architectuur.
Want alle ingrediënten voor de faalindustrie zijn er weer:
rule-engines, workflow-engines, orkestratie, microservices, het houdt niet op.
Zolang architecten niet de overstap maken van ecosysteem- naar selfservice-architecturen kunnen ze maar beter in die kast blijven zitten.
Lees desgewenst nog even:
https://www.computable.nl/artikel/opinie/outsourcing/5168040/1509029/svb-brand-in-het-ecosysteem.html
Als je nu opnieuw start met het bouwen van software dan moet je het nog steeds niet over architectuur hebben. We komen in een fase waarbij je functionaliteit aan elkaar klikt in een snel tempo, waarbij het prototype er is voordat je een architectuur hebt opgetekend.
Je hebt een een aantal richtinggevende principes nodig en prikkels om anders te gaan werken waarbij wendbaarheid en schaalbaarheid voorop staan.
Af en toe moet de architect even meekijken en bepalen of iets specifiek of generiek is en dit vervolgens met agillity implementeren of zorgen dat het wordt geïmplementeerd.
In een wereld waar bedrijfsmodellen een lifecycle hebben van 4-5 jaar heb je geen Enterprise architectuur meer nodig.
Je moet veel meer gaan denken in vervangbare blokken in de waardeketen om je businessmodel continu aan te passen aan de eisen en wensen van afnemers. De architect is veel meer de tacticus die overzicht heeft en kan meehelpen en denken om het businessmodel op de juiste manier van IT te voorzien.
Willem, ik volg je redenatie, maar ik zie wel degelijk een rol in enterprise architectuur. Er moet toch samenhang komen in al die punts oplossingen en een brug tussen techniek en het begrip van mensen over (data) structuren. Goede basisprincipes helpen je op weg en ik denk dat er ook een architect nodig is die fundamenten bewaakt en verder kijkt dan software alleen. Iemand die vanuit diverse invalshoeken (techniek, juridisch, compliance, risk, governance) er naar kijkt.
Maar goed, ben het redelijk met je eens en zou er vooral nog op aan willen vullen.