Management
Antifragiliteit smeermiddel voor digitalisering overheid
Enterprise-architectuur kan beperkend en vertragend werken.
Enterprise-architectuur kan beperkend en vertragend werken.
De overheid moet adequaat blijven besturen terwijl de maatschappij razendsnel digitaliseert en allerhande zeer grote incidenten en vraagstukken spelen. Snelle aanpassingen zijn broodnodig, maar dat is niet eenvoudig. Een oplossing daarvoor is een antifragiele werkwijze, waarbij een systeem stress incasseert maar daar ook beter van wordt. Dat eist echter ook wel wat van de manier waarop enterprise-architectuur moet worden toegepast, ziet René Bliekendaal.
Stel je bent verantwoordelijk voor de bedrijfsvoering van de organisatie Nederland B.V. Je probeert de bedrijfsvoering zo goed mogelijk uit te voeren door deze continu bij te stellen op de verwachtingen van burgers en ondernemingen. Tegelijkertijd heb je te maken met de digitalisering van de samenleving. Vraagstukken zoals inclusie en de menselijke maat spelen dagelijks. Dit alles binnen een omgeving waarbij de technologische veranderingen in de digitale transformatie elkaar razendsnel opvolgen, er een oorlog gestart wordt door Rusland, we net aan het einde zijn van een pandemie, er een energiecrisis gaande is tijdens een energietransitie en er protesten zijn vanwege de aanpassingen in het stikstofbeleid. Dit zijn maar een paar voorbeelden. De meeste van dit soort incidenten zijn niet voorspelbaar en de impact is vaak groter dan verwacht. De burger en bedrijven verwachten vervolgens dat je de bedrijfsvoering snel aanpast en ten dienste staat van de samenleving bestaande uit meer dan 17 miljoen mogelijke belanghebbenden. Hoe is dit te besturen en kun je het eigenlijk wel goed doen?
Het is voor de publieke sector steeds moeilijker de veranderingen binnen de markt te volgen en het tempo van aanpassen te verhogen. Dit is vanwege de bestaande normen, processen, structuren en bureaucratie. Laat staan als er ook nog flexibiliteit nodig is om ‘zeldzame’ incidenten het hoofd te bieden.
Er is veel onderzoek gedaan naar de publieke sector en specifiek de overheid in relatie tot verandersnelheid. Veel van de onderzoeken zijn uitgevoerd naar het waarom maar niet heel veel onderzoek geeft een antwoord op of enige richting aan hoe de publieke sector ondersteund kan worden om dit mogelijk te maken.
Antifragiel: beter worden van stress
Er zijn verschillende theorieën over hoe systemen kunnen omgaan met onduidelijkheid en ‘ontwrichtende’ veranderingen. Eén van die theorieën is die van de Amerikaans hoogleraar risicomanagement Nassim Nicholas Taleb: antifragiel. Antifragiel is onderdeel van een triade van fragiel, robuust en antifragiel. Fragiele systemen zijn systemen die het moeilijk vinden om om te gaan met veranderingen of systemen waarvoor het onmogelijk is om te gaan met veranderingen. Dat wil niet zeggen dat deze systemen niet succesvol kunnen zijn. Echter, een fragiel systeem komt vaak in de problemen als de omgeving iets verlangt wat buiten de mogelijkheden van dat systeem ligt. Deze verwachtingen resulteren in stress met alle gevolgen van dien. Een robuust systeem absorbeert stress en keert terug naar de oorspronkelijke staat, maar een antifragiel systeem incasseert niet alleen de stress - het wordt er zelfs beter van. Met dit ‘beter worden onder stress’ verandert het systeem ‘automatisch’ mee. Antifragiel laat systemen omgaan met onduidelijkheid en ontwrichtende veranderingen.
Enterprise-architectuur een zegen of een vloek?
Binnen de publieke sector wordt vanwege het risicoverlagend effect veel gebruik gemaakt van enterprise-architectuur als een veranderinstrument. Enterprise-architectuur binnen de overheid wordt ondersteund door een diversiteit aan referentie-architecturen in een bepaalde gelaagdheid met een ondergeschiktheid. Voorbeelden zijn de Nederlandse Overheids Referentie Architectuur (NORA) en de bijbehorende sectorale referentie-architecturen zoals de GEMeentelijke Model Architectuur (GEMMA), de Enterprise Architectuur Rijk (EAR), de Provinciale Enterprise Referentie Architectuur (PETRA) en de Waterschap Informatie & Logisch Model Architectuur (WilMA).
Referentie-architecturen worden gebruikt als normatief kader voor organisatiespecifieke architecturen waaruit projectarchitecturen worden opgesteld. En precies deze twee laatste specifieke architecturen zijn van belang bij veranderingen binnen de publieke sector maar worden in bedwang gehouden door referentie-architecturen.
Een ondergeschikte architectuur zoals een organisatie-architectuur van een gemeente mag niet tegenstrijdig zijn met de GEMMA, die op haar beurt niet tegenstrijdig mag zijn met de NORA. Veel van de referentie-architecturen zijn deterministisch en normatief. Deterministisch en normatieve architecturen zijn lastig in een context waar systemen, organisaties en projecten snel van richting moeten veranderen. Je hebt te maken met een cascade van architectuuraanpassingen die niet tegenstrijdig mogen zijn met bovenliggende architecturen. Daarbij is de governance van deze architecturen niet de verantwoordelijkheid van één organisatie maar van velen. Een verandering is hierdoor enorm complex als deze buiten de bestaande kaders valt. Het zorgt er voor dat een organisatie binnen de publieke sector niet heel wendbaar kan zijn. Op dit moment lijkt enterprise-architectuur meer een vloek dan een zegen.
Hoe dan wel
Het probleem zit hem in twee belangrijke aspecten. Het eerste aspect is dat enterprise-architectuur deterministisch en normatief is. Wat als wij architectuur niet gebruiken om voor te schrijven maar architectuur laten ontstaan? Werk alleen met kaders om er voor te zorgen dat de architecturen binnen bepaalde spelregels blijven en uitgevoerd worden. Dit is niet nieuw en het gebruik van bijvoorbeeld principes is gemeengoed binnen enterprise-architectuur. In 2008 schreef Jan L.G. Dietz, emeritus hoogleraar Ontwerpen van Informatiesystemen aan de TU Delft, al: ‘’Theoretisch is architectuur de normatieve beperking van ontwerpvrijheid. In de praktijk is architectuur een consistente en coherente reeks ontwerpprincipes.’’ Geef voldoende kaders mee maar stop met het voorschrijven op detailniveau; dat komt ten goede aan de veranderbaarheid.
Het tweede aspect is dat enterprise-architectuur vooral gericht is op de interne organisatie of op de interne werking van een systeem zoals de overheid. Er wordt te weinig naar buiten gekeken. Laat staan dat de omgeving, ten goede van het systeem, beïnvloed wordt. De publieke sector gebruikt enterprise-architectuur voornamelijk als de lijm tussen de bedrijfsvoering en IT en/of om er voor te zorgen dat de bedrijfsstrategie ook daadwerkelijk geïmplementeerd wordt. Wat als de wijze waarop wij enterprise-architectuur toepassen verandert en we ons richten op de lerende organisatie met de nadruk op de omgeving van het systeem en de relatie tot deze omgeving? Het uiteindelijke doel is om ons snel te kunnen aanpassen en het beïnvloeden van onze omgeving komt ten goede aan dit doel. Het mag duidelijk zijn dat dit een betere aanpak is om wendbaar te zijn. Met een goede besturing wordt je er zelfs beter van en ondersteunen we een antifragiele publieke sector.
Wat is hiervoor nodig
Om te werken aan een wendbare en antifragiele publieke sector is het van belang om op basis van vertrouwen veranderingen door te voeren. In een snel veranderende wereld zoals de huidige is er niet veel tijd om bij elk besluit lang stil te staan. Voor een antifragiele publieke sector is het juist van belang om te experimenteren, te leren van successen maar ook van fouten en samen te werken. Alleen dan kunnen we groeien en beter worden. Hiervoor zijn vertrouwen nodig en een veilige werkomgeving. Dit wordt op dit moment tegengewerkt door het uitvoeren van de publieke verantwoording. De uitgaven van publieke gelden moeten in detail worden verantwoord. Het is hierdoor lastig om om te gaan met onvoorspelbaarheid. Experimenteren is bijna niet meer mogelijk zonder een dreiging van een negatief rapport van het adviescollege ICT-toetsing of zelfs een parlementaire enquête. Er is geen veilige werkomgeving om grote risico’s te lopen.
In de huidige wereld is het van belang om het onbekende te accepteren en hier zo goed mogelijk mee om te gaan. Antifragiliteit is een methode om dit te omarmen en enterprise-architectuur, mits juist toegepast, kan dit ondersteunen.
Dit artikel gebruikt de uitkomsten van het onderzoek 'Towards an Antifragile Public Sector’ naar de succesfactoren van enterprisearchitectuur en antifragiliteit die een positieve invloed hebben op de bijdrage van enterprise-architectuur aan antifragiliteit in de publieke sector. Dit onderzoek heeft niet alleen een theoretische basis, maar de uitkomsten zijn ook specifiek gemaakt met diverse bestuurders en experts vanuit de publieke sector. Dit levert een gevalideerde lijst op van veertien belangrijke succesfactoren van antifragiliteit en enterprise-architectuur die van toepassing zijn op de publieke sector. Deze veertien succesfactoren zijn op te delen in zeven voor antifragiliteit en zeven voor enterprise-architectuur. De zeven succesfactoren voor enterprise-architectuur ter ondersteuning van een antifragiele publieke sector zijn:
1. Systems-in-Environment thinking. Denk in systemen in hun omgeving, waaronder niet alleen het systeem maar ook zijn omgeving en de bi-directionele relatie en transacties tussen het systeem en zijn omgeving.
2. Environmental learning. Leer van de omgeving en pas de doelen van het systeem aan zodat ze beter aansluiten bij de omgeving.
3. Intra-organisational coherency. Door de gewenste intra-dynamiek te versterken en de ongewenste af te zwakken, is het mogelijk om het systeem bevorderlijk te maken voor ecologisch leren, omgevingsbeïnvloeding en coherente strategie-uitvoering.
4. System-in-Environment coevolution learning. Systeem-in-omgeving co-evolutie is de combinatie van ‘environmental learning’, ‘intra-organisational coherency’ en het verminderen/dempen van ongewenste krachten.
5. Holistic (systemic) stance. Het enterprise-architectuurproces moet niet alleen denken aan één domein, maar aan de combinatie van domeinen (IT- en bedrijfsdomeinen) samen. Het afzonderlijk aanpakken van alle subdomeinen van IT- en bedrijfsarchitectuur en proberen de andere subdomeinen dienovereenkomstig aan te passen, zal waarschijnlijk een ineffectief en onhoudbaar resultaat opleveren.
6. Organisational learning. Ontwerp alle facetten van de organisatie (het systeem), inclusief de relatie met de omgeving. Dit bevordert het lerend vermogen van het systeem. Dit komt ten goede aan innovatie en maakt systeem-in-omgeving-aanpassingen mogelijk.
7. Adapt to business language. Door gebruik te maken van de natuurlijke taal van belanghebbenden (stakeholders) wordt enterprise-architectuur eerder geaccepteerd buiten de IT-domeinen.
Dit artikel is ook gepubliceerd in het magazine van AG Connect (december 2022). Wil je alle artikelen uit dit nummer lezen, zie dan de inhoudsopgave.
Het komt op mij over dat enterprise architectuur in dit artikel de enterprise IT architectuur is en ben het eens met Atilla. Succesfactor 5 en 6 geven mij de indruk dat de huidige enterprise architectuur niet holistisch is en niet het bedrijfsdomein omvat en niet de omgeving in beschouwing neemt. Ik heb een ander beeld van enterprise architectuur.
Juist het vervatten van de gewenste richting en inrichting in principes geeft wendbaarheid aan de uitvoering en stelt iedereen in staat om bij gewijzigde omstandigheden nieuwe keuzes te maken.
In de laatste alinea staat wat er nodig is maar dat heeft niks te maken met andere vormen van enterprise architectuur en alles met andere vormen van (publiek) besturen.
Wat een ouderwetse kijk op EA. EA is al een tijd lang verbreed buiten de IT. Dat nog heel volksstammen blijven roepen wat wel of niet in EA zit, heeft volgens mij meer met belangen te maken, dan de natuurlijke groei van de volwassenheid van een vakgebied. Als je architectuur maar blijft zien als een IT dingetje, dan zal het zeker niet kloppen. Een tweede is natuurlijk dat ik veel "architecten" en anderen hoor roepen dat EA of een andere vorm van architectuur (domein, solution, etc....) een vorm van blauwdruk denken is, wat al heel lang compleet achterhaald is. Misschien is het een idee om alleen architecten te laten spreken die dagdagelijks met hun "poten in de modder" staan en ik durf je op een briefje te geven, dat de problemen die we in onze samenleving hebben, grotendeels allemaal terug te voeren zijn op een te grote complexiteit van die samenleving. De oorzaken van die complexiteit zijn in mijn optiek terug te voeren op 4 cultuuraspecten binnen die BV Nederland: hiërarchische besluitvorming ("omdat we dat nu eenmaal zo afgesproken hebben"), alles politiek maken ("want dan ga je er niet meer over"), risicoloos denken te leven ("ik wil geen gelazer met mijn bestuurder") en het gemiddeld niveau van de mens is prima ("een gesprek aangaan met mijn medewerker die feitelijk niet functioneert is eng"). Inhoudelijk is complexiteit verminderen niet moeilijk ("uitdagend"), maar het wordt in mijn "bescheiden" mening tegengehouden door de genoemde cultuuraspecten.