Omgaan met verandering is essentieel voor succes in digitale transformatie. Veranderingen moeten een plaats krijgen binnen de hele organisatie, waaronder de architectuur van ict-oplossingen die essentieel zijn voor de bedrijfsvoering en digitalisering. Het wordt tijd om evolutie in de architectuur mee te ontwerpen met 'precies genoeg anticipatie'.
Traditionele architectuur-aanpakken lopen achter op het gebied van evolutie en verandering, met name gezien vanuit de huidige, steeds digitalere wereld. Veel traditionele architectuurmodellen zijn tijd-agnostisch.
Wanneer evolutie en verandering niet effectief worden geadresseerd, kunnen architectuurdocumenten lang op zich laten wachten, of bij het uitbrengen al achterhaald zijn. Dit leidt tot ontwikkeling op basis van inadequate documenten en slechte planningen – potentieel grote obstakels voor iedere organisatie die de digitale opmars bij wil benen – en Agile wil kunnen inspelen op nieuwe concurrentie-bedreigingen.
De snelheid waarmee digitale technologieën een steeds groter deel uitmaken van ons dagelijks leven, maakt voortdurende en snelle evolutie en anticipatie noodzakelijk. Een goed voorbeeld is de urgentie en groeiende trend om cybersecurity al vanaf dag één in te bouwen in het ontwerp van ict-oplossingen. Wat voorheen werd gemanaged als een toevoeging aan de architectuur nadat een oplossing was gebouwd, moet tegenwoordig vanaf het begin worden ingebakken – zoals vele dure lessen ons de afgelopen jaren geleerd hebben. Een ander voorbeeld is de evolutie van big data technologieën die organisaties de mogelijkheid geven om hun gegevens-rijkdom te verzilveren.
Evolutie in architectuur mee-ontwerpen
Het integreren van evolutie in architectuur kan via een risico- en kosten-gedreven architectuuraanpak (RCDA). Zo’n aanpak leidt tot architectuurdocumentatie die niet alleen de huidige (‘as-is’) of toekomstige (’to-be’) situatie beschrijft, maar ook toekomstige gebeurtenissen identificeert en incorporeert, waarbij ‘precies genoeg anticipatie’ wordt toegepast. Deze gebeurtenissen omvatten het toevoegen van nieuwe features aan een dienst, het uitbrengen van een next-generation product door een concurrent, nieuwe wet- en regelgeving, of iedere andere ontwikkeling die impact heeft op de risico’s, kosten of business-waarde van een oplossing.
Het anticiperen op toekomstige gebeurtenissen zorgt ervoor dat architectuur zijn rol als risicomanagement discipline vervult. Het verhoogt tevens de praktische waarde van architectuurdocumentatie in gevallen waar de ’to-be’ situatie een bewegend doel blijkt te zijn. In een steeds veranderende digitale wereld blijft documentatie die verandering een plaats geeft relevanter dan documentatie die dat niet doet.
Bouw evolutie-viewpoint in
Een methode om de tijd-dimensie toe te voegen aan architectuur is het inbouwen van een evolutie-viewpoint, waarin de evolutie-aspecten van een oplossing worden gedocumenteerd. Viewpoints (gezichtspunten) worden in de architectuur gebruikt om aan belanghebbenden te laten zien hoe de architectuur specifieke belangen invult. Een evolutie-viewpoint demonstreert hoe de architectuur de impact van veranderingen rondom de oplossing adresseert.
Bij het ontwikkelen van een evolutie-viewpoint worden toekomstige gebeurtenissen geïdentificeerd, en worden de stappen om ze te adresseren gedocumenteerd. Dit plaatst het team in een betere positie om economische argumenten toe te passen bij de besluitvorming rondom toekomstige veranderingen, en daardoor betere beslissingen te nemen (bijvoorbeeld: wegen de extra kosten van het uitstellen van een release-deadline op tegen de schade die we lopen als we bepaalde regelgeving nog niet ondersteunen?). Bovendien is het team hierdoor beter in staat om effectief met belanghebbenden in de business te communiceren over toekomstige ontwikkelingen.
Evolutie-viewpoints en architectuur-roadmapping hebben hun effectiviteit bewezen op het gebied van wendbaarheid in het anticiperen van en omgaan met veranderingen in de ontwikkeling van een oplossing.
Ervaringen in architectuur-roadmapping
Wij passen de hierboven beschreven aanpak toe, en onze architecten zien in de praktijk hoe de aanpak helpt om de balans te vinden tussen over-anticipatie en onder-anticipatie bij het bouwen van architectuurconstructies (de ‘onder-de-motorkap’-onderdelen van een oplossing). Het documenteren van de tijd-dimensie van architecturen ziet er misschien uit als extra werk, maar anticipatie is toch al een belangrijk onderdeel van het werk van een architect. Als architecten die anticipatie communiceren als een evolutie-viewpoint blijven architectuurbeschrijvingen langer geldig, en zijn ze beter voorbereid op de veranderende omstandigheden.
In de meeste marktsectoren wordt de urgentie gevoeld om te digitaliseren en snel op de veranderende verwachtingen van consumenten en burgers in te spelen. Zonder sterke digitale architecten en architecturen is dit onmogelijk. Het wendbaarder maken van de gehele organisatie, waaronder de architectuur van ict-oplossingen, kan een hoognodige sprong voorwaarts betekenen.
Zie voor meer informatie over deze tijd-dimensie aanpak voor architectuur mijn artikel ‘Just Enough Anticipation: Architect Your Time Dimension‘.
Beste Eltjo,
Ik begrijp dat het voor IT-leverancier CGI belangrijk is om IT(-architectuur) in het centrum te hebben, as-is en to-be. Ik begrijp ook dat je van as-is naar to-be gaat met werk dat je doet om een gewenste IT-situatie te bereiken. Maar je zicht op “evolutie en verandering” inbedden in een IT-aanpak is feitelijk een oxymoron.
Als je niet het centrum ziet en zet in de organisatie en haar informatie zal geen ene IT-architectuur aanpak werken, “traditioneel” of nieuwer. Het is immers de organisatie die zal veranderen, en daar zal IT bij moeten blijven passen. Niet andersom. En natuurlijk kunnen IT-mogelijkheden in de gaten gehouden worden, maar pas als de organisatie die wil inbedden (en weet hoe ze dat gaan doen) komt IT aan de beurt.
Dus digitale transformatie is iets van een organisatie en alleen in tweede instantie rond passende IT (en de (hopelijk agile) architectuur die je daarvoor bedenkt). Als je dit echt toe gaat voegen aan wat je hier als aanpak voorstelt gaat dat voorstel er echt anders uitzien.
Beste Jan, ik ben het grotendeels met je eens – de aanpak die ik hierboven beschrijf is dan ook geen IT-aanpak, maar een architectuur-aanpak. Die gaat over het bedenken en maken van oplossingen die organisatie en IT overbruggen. Als je in die context geen zicht op evolutie en verandering hebt vaar je blind.
Dat die veranderingen altijd vanuit de organisatie moeten komen en pas daarna vanuit technologie is tegenwoordig geen algemeen houdbaar standpunt meer. Ik denk dat de beweging die we digitale transformatie zijn gaan noemen juist voortkomt uit de steeds groter wordende vervlochtenheid tussen organisatie en technologie, en de nieuwe inzichten die daaruit voortkomen.
Beste Eltjo,
Excuses voor mijn late reactie.
In je antwoord laat je me weten dat je een andere invalshoek voor het ontwikkelen van IT-applicaties gebruikt dan via een IT-aanpak neergezet wordt. Ik begrijp dat je organisatie en IT probeert te combineren, maar zover ik het lees blijft je architectuur-aanpak een aanpak om IT-oplossingen te realiseren met een wat andere invalshoek.
In de jaren heb ik heel vaak pogingen, zelfs hypes gezien die organisatie en IT trachten te mengen. Geen van die manieren is ooit gelukt. Logisch. Daarom zal wat nu digitale transformatie heet binnenkort ook wel weer een zachte dood sterven. Natuurlijk zijn er organisaties die, door hun doelen, IT als essentieel hulpmiddel hebben, maar in veruit de meeste organisaties gaat het om hun eigen doelen en kan je een hulpmiddel niet leidend maken.
Beste Eltjo,
Excuses voor mijn late reactie.
In je antwoord laat je me weten dat je een andere invalshoek voor het ontwikkelen van IT-applicaties gebruikt dan via een IT-aanpak neergezet wordt. Ik begrijp dat je organisatie en IT probeert te combineren, maar zover ik het lees blijft je architectuur-aanpak een aanpak om IT-oplossingen te realiseren met een wat andere invalshoek.
In de jaren heb ik heel vaak pogingen, zelfs hypes gezien die organisatie en IT trachten te mengen. Geen van die manieren is ooit gelukt. Logisch. Daarom zal wat nu digitale transformatie heet binnenkort ook wel weer een zachte dood sterven. Natuurlijk zijn er organisaties die, door hun doelen, IT als essentieel hulpmiddel hebben, maar in veruit de meeste organisaties gaat het om hun eigen doelen en kan je een hulpmiddel niet leidend maken.
Beste Eltjo,
Excuses voor mijn late reactie.
In je antwoord laat je me weten dat je een andere invalshoek voor het ontwikkelen van IT-applicaties gebruikt dan via een IT-aanpak neergezet wordt. Ik begrijp dat je organisatie en IT probeert te combineren, maar zover ik het lees blijft je architectuur-aanpak een aanpak om IT-oplossingen te realiseren met een wat andere invalshoek.
In de jaren heb ik heel vaak pogingen, zelfs hypes gezien die organisatie en IT trachten te mengen. Geen van die manieren is ooit gelukt. Logisch. Daarom zal wat nu digitale transformatie heet binnenkort ook wel weer een zachte dood sterven. Natuurlijk zijn er organisaties die, door hun doelen, IT als essentieel hulpmiddel hebben, maar in veruit de meeste organisaties gaat het om hun eigen doelen en kan je een hulpmiddel niet leidend maken.
Een boeiende vraag: “Hoe voeg je de tijdsdimensie toe aan architectuur”?
Wel opvallend dat architecten die de trom roeren voor snelheid en wendbaarheid komen aanzetten met zoiets traags als een evolutie. Zo waren voor de biologische evolutie, het ontstaan van leven op aarde toch wel enkele miljarden jaren nodig, en de daarop voortbouwende culturele evolutie, het ontstaan van de mens, inclusief zijn bewustzijn, nog eens zo’n 200.000 jaar; al ging het de afgelopen 14.000 jaar wel wat sneller (aldus dit zeer leesbare artikel:
https://www.nemokennislink.nl/publicaties/explosieve-groei-in-onze-culturele-ontwikkeling ).
Voor het realiseren van de tijdsdimensie binnen architectuur is mijns inziens dan ook niet het begrip evolutie maar het begrip selfservice de cruciale terminologie. Terecht wordt het concept van selfservice tegenwoordig als één van de centrale doelstellingen van Enterprise Architectuur opgevat, maar is dit principe niet evengoed in de architectuur en de werking van de menselijke psyche terug te vinden? En dan zitten we op het goede spoor, want terwijl de culturele evolutie enkele honderdduizenden jaren nodig had om bewustzijn bij de mens tot stand te brengen gebeurt hetzelfde in slechts enkele jaren bij een pasgeboren kind.
En dat is dus eens te meer een aanwijzing dat het vakgebied van de EA moet inzetten op kennistechnologie in plaats van procestechnologie. Valt tenminste ook eindelijk iets zinnigs te zeggen over kunstmatige intelligentie.