Management

Infrastructuur
Business

Veranderen met Inzicht

Enterprise Architecture geeft bestuurders inzicht in structurele aspecten van veranderingen.

16 december 2016

Enterprise Architecture geeft bestuurders inzicht in structurele aspecten van veranderingen.

Traditioneel worden veranderingen top-down opgezet. Veranderingen gebeuren echter steeds minder top-down, maar ontstaan juist ook bottom-up. Dit betekent ook dat de rol, en invulling, van Enterprise Architecture met deze ontwikkelingen moet meebewegen.

 AG tekstballon-1Organisaties in beweging

Het is al vaker gezegd en beschreven: voor veel organisaties is verandering de enige constante. De managementagenda's staan vol met grootschalige veranderprogramma's, LEAN verbetertrajecten, applicatieportfoliorationalisatie, cloud migratie, en ga zo maar door. Langzaamaan lijken ook steeds meer organisaties in te zien dat het traditionele onderscheid tussen “business” en “IT” ook weinig zinvol meer is. De belangrijkste trends van dit moment raken alle aspecten van de organisatie en dienen dus ook als zodanig gemanaged te worden [6]. Twee voorbeelden ter illustratie zijn:

  • In overheidsland wordt steeds meer gedacht in termen van ketens van organisaties, waarin niet langer enkel één partij dominant is. Grote maatschappelijke zaken zoals openbare orde en veiligheid vereisen de samenwerking van vele partijen. Informatisering is essentieel in deze context: zonder effectieve informatiestromen gaat het lastig worden om als keten te opereren.
  • In steeds meer organisaties heerst een “data driven” cultuur waarbij besluitvorming plaatsvindt op basis van data. Hierbij wordt zowel interne (gestructureerde) data, als externe (linked / open data, big data) data ingezet. Nieuwe IT-technieken worden ingezet, maar zonder business context zijn deze vrijwel betekenisloos.

De klassieke manier van omgaan met verandering is gebaseerd op een top-down aanpak met veel aandacht voor planmatige verandering, analyse, verantwoording en rationele afwegingen. William Rouse [4] spreekt over enterprise transformation, en koppelt deze term één op één aan de top-down benadering van structurele veranderingen. De top-down benadering heeft in het verleden veel successen gebracht, maar werkt ook lang niet altijd even goed.

De laatste jaren is een min of meer tegengestelde stroom opgekomen: emergente veranderingen zonder veel sturing en controle waarbij creativiteit, vakmanschap en incrementele verbetering een centrale rol lijken te spelen. Vaak lijkt deze moderne(re) aanpak snel(ler) tot innovaties en resultaat te komen. Er blijkt echter ook aan nadeel aan te zitten: hoe houden we grip op de richting van de organisaties? Met andere woorden, hoe zorgen we dat middelen zo effectief mogelijk ingezet worden?

 AG tekstballon-2 De digitale transformatie; Nog sneller bewegen

Onder invloed van de zogenaamde disruptive technologies (drones, internet of things, wearable technology, etc.) wordt de vraag naar, en het tempo van, verandering alleen maar groter. Op maatschappelijk niveau wordt dit ook wel de digitale transformatie genoemd.

Door disruptive technologie wordt de vraag naar verandering alleen maar groter

Interessant genoeg leidt de digitale transformatie van de maatschappij zowel tot dop-down als bottom-up veranderingen. Cloud services, smart phones en social media, etc, hebben diverse top-down veranderingen teweeggebracht. Tegelijkertijd heeft het gebruik van file-sharing services,social media, smart-phones en tablets, ook veel bottom-up veranderingen teweeg gebracht waar de organisatie geen grip op heeft.

“Niet mee doen” is veelal geen verstandige optie. De klant verwacht op zijn wenken bediend te worden: als het niet op de smart phone geregeld kan worden dan sta je als organisatie meteen met 1-0 achter.

 AG tekstballon-3 Sturen van verandering

Gegeven al die veranderingen, blijft de vraag: hoe ga je daar op verstandige en tijdige wijze invulling aan geven? Tijdig omdat men liefst concurrentievoordeel wil behalen, maar op zijn minst niet achter wenst te lopen op de concurrentie. Verstandig omdat de benodigde veranderingen enerzijds zo diep ingrijpen op bestaande structuren en processen dat een goed inzicht in de consequenties van veranderingen essentieel is. Anderzijds maken de wetgever en de maatschappij het noodzakelijk om transparantie te bieden, en te voldoen aan diverse stelsels van compliance regels.

Een vervolgvraag in dit verband is: hoeveel wil je sturen? Dat kan van heel los (richtinggevend, vertrouwen op je professionaliteit), of wil je ook een vorm van governance toepassen (vinger aan de pols houden) of gaat het toch echt om actief meedoen en zelf aan de knoppen willen zitten?

Bij veel verandertrajecten wordt de inhoudelijke sturing bij architecten belegd. Veelal is de modus hierbij top-down waarbij het sturen draait om het strak voorschrijven van een richting (middels modellen en principes), gecombineerd met een flink stuk governance. Architectuurmethoden zoals TOGAF  zijn heel sterk op zo’n top-down denkwijze geënt. De meer agile aanpakken zoals SAFE laten meer ruimte aan veranderingen om een eigen weg te zoeken.

 AG tekstballon-4 Stuurbaarheid

Het sturen van verandering vergt inzicht in de onderliggend vraagstukken en structuren. Echter, de gedachte dat de wereld analyseerbaar is komt steeds meer onder druk te staan. In toenemende mate wordt onderscheid gemaakt tussen zogenaamde tamme en gemene problemen [3], of ingewikkelde en complexe vraagstukken [5]. In het eerste geval ben je actief in een probleemdomein waarbij aantoonbaar een goede / effectieve oplossing bedacht kan worden. Het kan even duren, maar met voldoende analyses kom je er wel uit. In het tweede geval daarentegen, is dat niet het geval. Dit is de klasse van problemen waarbij het onmogelijk blijkt om het probleem in zijn volledigheid te duiden, laat staan om een ultieme oplossing te vinden. Hier leiden analyses tot hypotheses over acties die zinvol zouden kunnen zijn. Uitsluitend door actie te ondernemen weet je wat wel of niet werkt.

Typische (pure) IT vraagstukken worden veelal als ingewikkeld gezien. Socio-economische (business) vraagstukken zitten meer in de complexe categorie. Met het verdwijnen van de toch al gekunstelde grens tussen business en IT lijken steeds meer vraagstukken deze kant op te verhuizen. Vaak blijkt bij vraagstukken die in eerste instantie een IT vraagstukken leken te zijn, eigenlijk een socio-economisch probleem onder water verstop te zitten. Dat betekent dan ook dat de rol van de architect en de gereedschappen die gebruikt worden mee zullen moeten veranderen.

AG tekstballon-5 Gemengde aanpak

De roep om een “agile” aanpak bij transformaties lijkt steeds luider te worden, vooral uit de hoek van programma’s en projecten zelf. Tegelijkertijd is ook duidelijk geworden dat een pure agile aanpak ook nadelen heeft, hetgeen heeft geleid tot uitbreidingen om ‘governance’ op agile projecten te houden. Het onderliggende dilemma is: grip en controle versus vertrouwen en risico management. In moderne organisaties [1] is zowel de behoefte aan een top-down transformatie aanpak, als de de mogelijkheid om meer emergent / agile aan de slag te gaan met vraagstukken. Vaak wordt dit gekoppeld aan een pace layering strategie, waarbij onderscheid wordt gemaakt tussen de operationele kern van de organisatie enerzijds, innovaties anderzijds, en verschillende niveaus daartussen.

De gedachte dat de wereld analyseerbaar is, komt steeds meer onder druk te staan

Emergente veranderingen gebeuren zonder veel controle of sturing, dat zit in de definitie van emergentie besloten.  Het is vooral zaak om tijdig te onderkennen dát deze veranderingen gebeuren en te beoordelen of het effect gewenst is om al dan niet bij te sturen.  Dit vereist een nieuwe capability in de organisatie, waarbij transparantie en vertrouwen de sleutelwoorden zijn.  Transparantie omdat de feiten over veranderingen en effecten helder moeten zijn, en vertrouwen in elkaars professionaliteit zodat analyses, acties en besluiten worden gerespecteerd en opgevolgd.

Top-down transformatietrajecten worden juist wél bewust ingezet. Hier is het zaak om voldoende scherp te zijn op de aard van het onderliggende vraagstuk: ingewikkeld of juist complex? Dat laatste blijkt nog lastig. Er lijkt een rotsvast vertrouwen te zijn in het maakbaarheidsprincipe. Mogelijk is dit te verklaren vanuit het feit dat bedrijfskunde studenten teveel wordt geleerd om naar de beste oplossing te zoeken in plaats van risico en onzekerheid te omarmen.

In zo’n gemengde methode met veel aandacht voor juist de echt complexe problemen zullen architectuur en architectuurproducten een andere rol krijgen.

AG tekstballon-6 Evolutie van Enterprise Architecture

Dit brengt ons bij de vraag hoe Enterprise Architecture als rol / functie in organisaties zich moet aanpassen aan de bovenstaande ontwikkelingen. In [2] hebben we al eerder bij enkele van de benodigde veranderingen stilgestaan.

Architectuur moet zich minder richten op modellen, maar meer op richtinggevende principes

Het feit dat organisaties continu in beweging zijn, en zeker nu dit nog eens versterkt wordt door de digitale transformatie, maakt het nodig dat architectuur zich minder richt op gedetailleerde beschrijvende modellen, maar meer op richtinggevende en kader zettende modellen / principes.  Hierbij kan middels verschillende, in meer detail uitgewerkte, toekomstscenario’s inzicht geboden worden in de wenselijkheid van de kaders. Tegelijkertijd is het belangrijk om inzicht te hebben in de bestaande situatie en de lopende veranderingen, met name ook de bottom-up veranderingen. Technieken zoals process mining en enterprise cartography kunnen hierbij behulpzaam zijn om deze evolutie in kaart te brengen.

Gericht op het sturen van verandering, is het belangrijk dat architecten en senior management een goed inzicht hebben in hun respectievelijke ambities en strategie om veranderingen te sturen. Denk hierbij aan de keuze tussen het sturen op geld, snelheid, of kwaliteit, maar ook aan het eventueel gebruiken van een multi-speed aanpak.  Fundamenteel is echter ook het goed inschatten, en gemeenschappelijk onderkennen, van de vraag of men opereert in situaties met (slechts) ingewikkelde of complexe vraagstukken.

Referenties

[1]     S. Mingay and M. MEsaglio. How to achieve enterprise agility with a bimodal capability. Technical Report G00276981, Gartner, 2015. 


[2]     H. A. Proper and M. M. Lankhorst. Enterprise Architecture - Towards essential sense-making. Enterprise Modelling and Information Systems Architectures, 9(1):5-21, June 2014. 


[3]     H. W. J. Rittel and M. M. Webber. Dilemmas in a General Theory of Planning. Policy Sciences, 4:155-169, 1973. 


[4]     W.B. Rouse, editor. Enterprise Transformation - Understanding and Enabling Fundamental Change. Wiley Series in Systems Engineering and Management. Wiley Interscience, 2006.

[5]     D.J. Snowden and M.E. Boone. A leader’s framework for decision making. Harvard Business Review, 11:68-76, 2007. 


[6]     R. Wagter, H. A. Proper, and D. Witte. A theory for Enterprise Coherence Governance. In P. Saha, editor, A Systematic Perspective to Managing Complexity with EA. IGI Publishing, Hershey, Pennsylvania, 2013. 


Zie ook Management op AG Connect Intelligence
1
Reacties
Atilla Vigh 16 december 2016 20:28

Leuk artikel, maar wel wat kanttekeningen:
- "Architecten" die nog steeds de term "Business" hanteren schofferen de rest van de gehele organisatie of keten die NIET van de IT is. Het zegt ook wat over deze soort "Architect": het feit dat ze zelf vinden bij de IT horen. Een CFO of COO noemt zich niet de "Business", maar de financiële topman of de verantwoordelijke voor de gehele operatie. Daarom stoppen met die rare "scheiding": een organisatie is een club mensen die met middelen (machines, grondstoffen, kennis (en of data) en geld) een dienst of product maakt/levert. Daarbij komen allemaal disciplines bij kijken en elk van disciplines zijn relevant en hebben hun eigen vaktermen. Maar uiteindelijk gaat het om de samenwerking tussen deze disciplines. EA zou daarover moeten gaan.
- Een top-down architectuur bestaat NIET. Architectuur is een blijvende activiteit. Zowel de beschrijvende architectuur: het samenhangend geheel als de bedrijvende architectuur: inspelen op veranderingen binnen de context.
- Laten we stoppen alles wat met "snelle" veranderingen te maken heeft niet gelijk tot disruptive te noemen. In het algemeen lees ik dat met disruptive (wat letterlijk "verstorend" betekent) dat het business model om zeep wordt geholpen. Ik stoor me werkelijk aan het feit dat het doel van het nieuwe product of dienst vooral disruptive moet zijn? Dus een stel ondernemers of starters zitten dat echt te bedenken: laten we een deel of complete bedrijfstak om zeep helpen? Volgens mij zijn ze met 1 ding bezig: kan ik (mits je het pure kapitalistische gedachtegoed blijft omarmen) winst maken en welke toegevoegde waarde lever ik dan voor mijn klanten.
- Tenslotte de snelheid waarin dit allemaal zou moeten plaats hebben? Ik hoor dit al sinds mensenheugenis. En lijkt wel of we in een jachtiger samenleving leven, maar vaak hoor ik geen onderbouwing. De enige reden om snelheid te maken in het lanceren van een nieuw product/dienst is momentum (is het nog relevant) of duiken er kapers op de kust op. Wat nu blijkbaar vaker gebeurt is dat er door geldschieters snel iets moet komen, anders draait men de geldkraan dicht.
- Ik heb ooit wel eens gedacht of er een "systeem" komt dat elke discipline zodanig "maakbaar" en "model leerbaar" in samenhang kan visualiseren, dat elke gewenste sturing kan worden "doorgemeten". Ik begin daar ook steeds meer aan te twijfelen. Beslissers zoeken naar voorspelbare uitkomsten, maar helaas die bestaan niet. Je zag in een ongelofelijk eenvoudige situatie bij de Amerikaanse verkiezingen: ze vergaten een "vergeten groep" in de peilingen mee te nemen.
- Om EA echt voeten aan de grond te laten krijgen, moeten we van die naam Architectuur af. Deze is "besmet", doordat bijna alle beslissers denken dat Architectuur een IT feestje is EA (zonder IT EA te noemen) is een organisatie overstijgend feestje, dus gaat over alle disciplines. Dat het gebruik maakt van architecturale principes zegt wat meer over de vorm waarin het zich manifesteert. Misschien is het leuk een nieuwe functiebenaming te verzinnen.....

Reactie toevoegen