Er zijn ontzettend veel architectuur-frameworksen er is veel discussie over hun waarde: welk framework te gebruiken, hoe ze op maat te maken voor jouw specifieke situatie, do's en don'ts - en deze discussie zal eeuwig doorgaan. De vraag die eigenlijk aan deze discussies ten grondslag ligt, is fundamenteler dan we denken en heeft mogelijk te maken met het vinden van de "toegevoegde waarde" achter het gebruik van Enterprise Architectuur. De belofte van Enterprise Architectuur is zeker inspirerend en kan mogelijk veel voordelen voor het bedrijf opleveren, maar is het ook te realiseren? Waar moet je beginnen en zijn er praktische instrumenten, die klaar zijn voor gebruik, die we direct kunnen inzetten?
Voor veel mensen is de grotere vraaghoe men Enterprise Architectuurdaadwerkelijk in de praktijk toepastop een betekenisvolle manier. Het is een zoektocht op een "meta-niveau", gericht op processen, structuren en mechanismen om Enterprise Architectuur (EA) te laten werken en het te laten passen binnen de dynamiek van een organisatie. Op het niveau van de werkvloer zijn het deze mechanismen waar praktijkmensen in geïnteresseerd zijn. Je zou hun behoeften kunnen verwoorden als: "Geef ons de tools en methoden die ik kan gebruiken om Enterprise Architectuur op zo'n manier toe te passen dat ik er zo snel mogelijk de operationele vruchten van kan plukken, en tegelijkertijd zal ik helpen om het belang van EA te behartigen."
In ons werk bij Digital Innovation zien we veel professionals en organisaties worstelen met dit vraagstuk. Hoe breng ik voldoende waarde in de praktijk? We zien EA-teams worden beschuldigd van het hebben van een "ivoren toren"-mentaliteit en zoveel EA-praktijkmensen krijgen te horen dat ze te ver van de realiteit af staan.
Bovendien worden ze geconfronteerd met belanghebbenden die hen vertellen dat de output van EA te traag wordt geleverd, dat hun werk moeilijk te begrijpen is en dat het niet genoeg aansluit bij de echte uitdagingen. Deze architectuurteams bevinden zich in een vacuüm, min of meer losgekoppeld van de organisatie en uiteindelijk zal de waarde van EA langzaam maar zeker vervagen in "een moedige poging om bedrijfsvoering en IT op één lijn te brengen." Dat is jammer, want EA heeft het potentieel om een organisatie in zijn geheel te verbinden. Niet alleen bedrijfsvoering en IT, maar alle elementen van de organisatie. Horizontaal over de functies en afdelingen en verticaal over de strategie, tactiek en operaties.
Gelukkig hebben we ook enkele organisaties gezien die zeer succesvol zijn in hun EA-inspanningen, ongeacht de context waarin EA wordt toegepast (transformatie of operationeel). Wij van Digital Innovation hebben nagedacht over de redenen voor hun succes, en die delen we natuurlijk graag.
Succes in EA-inspanningen Wat maakt een EA-team nou precies succesvol?
Allereerst lijkt er geen "grijs gebied" van succes te zijn - een Enterprise Architectuur (EA) functie is ofwel succesvol of niet. Wat interessant is, is dat EA-teams bestempeld worden als het "aanspreekpunt bij problemen" (wat een ander probleem met zich meebrengt: namelijk dat allerlei soorten vragen op het bureau van EA terechtkomen, waarvan er meerdere niet echt relevant zijn voor hun functie, maar laten we daar nu niet op ingaan). Succesvolle EA-teams zijn de teams die een breed overzicht hebben en, indien nodig, voldoende inzicht en details kunnen leveren om de verbanden te leggen. Snel resultaat kunnen leveren lijkt zeer belangrijk te zijn. Deze teams zijn pragmatisch, resultaatgericht, meesters in het benoemen van de essentie van een onderwerp of discussie en tonen ook een hoge mate van zakelijk inzicht.
Verder doen succesvolle EA-teams veel "marketing" rond hun werk wat niet alleen het maken van "oogverblindende dia's" inhoud. Hun communicatie is op dusdanige manier verzorgd dat het zakelijke stakeholders aanspreekt– het technische geneuzel is begrijpelijk geworden. Ze praten niet zozeer over technische architectuur of over het kader dat ze gebruiken (denk aan de TOGAF-gecertificeerde markering die aan EA-opleidingen is gekoppeld), maar ze proberen een resonantie te vinden met de zakelijke uitdagingen, zoals hoe ze (top-line) groei denken te gaan verwezenlijken, het verlagen van (IT)-kosten en hoe ze bijvoorbeeld automatisering kunnen implementeren om operationele efficiëntie en bedrijfskosten te optimaliseren.
De meest voorkomende factor voor succesvolle EA-teams is echter het bestaan en gebruik van een “op gebruikers gericht" proces dat goed begrepen wordt, transparant en super-uitvoerbaar is.
Hun proces geeft duidelijk antwoord op de vraag "Hoe doen we dit?" (de stappen die we zullen doorlopen en het resultaat van elk van de stappen) en is gericht op het resoneren met de top-of-mind zakelijke verwachtingen. De belangrijkste reden voor de succesvolle adoptie is dat het proces daadwerkelijk belanghebbenden (gebruikers) betrekt, door een goed uitgebalanceerd proces te gebruiken, dat is gebaseerd op verkennen, interactie, agile werken, en stabiele iteratie.
Dit zetten ons aan het denken, wat is nou eigenlijk een "goed proces"? Kunnen we voorbeelden van een dergelijk proces vinden in andere gebieden? Als we in staat zijn om uit onze (vrij technische) comfortzone te stappen en echt onze ogen openen, wat kunnen we dan zien in de wereld om ons heen? Eén specifieke aanpak wekte onze interesse: Design Thinking, bedacht door David M. Kelley, oprichter van IDEO. Design Thinking is een benadering om onoplosbare menselijke problemen aan te pakken door middel van ontwerp. Omdat dit artikel niet bedoeld is om een studie over Design Thinking te geven, proberen we het kort te houden: in het bedrijfsleven worden problemen meestal opgelost door conventionele analyse (vergelijkbaar met wat je doet tijdens een academisch onderzoek), wat meestal lineair is, terwijl ontwerpers problemen oplossen door synthese, een proces van divergentie, convergentie en prototyping - en weer terug, dus cyclisch (wat je leert op een ontwerpschool).
Ontwerpers hebben een zeer duidelijke focus op de gebruikers van het product of de dienst en zien hen als cruciaal om tot een betekenisvol product (vorm en functie) te komen, zelfs in die mate dat ze de gebruikers betrekken bij het ontwerpproces zelf om zo het resultaat samen te creëren. De ontwerp-denkmethodiek deelt een gemeenschappelijke set van andere kenmerken: creativiteit, dubbelzijdig denken, teamwork, nieuwsgierigheid en optimisme. Als je het aan ons bij Digital Innovation vraagt, is dat nogal het tegenovergestelde van wat je in een gemiddelde EA-praktijk of -workshop kunt ervaren. Dus een ontwerp-denkproces toegepast op EA, hoe ziet dat eruit?
Hoe ziet een ontwerp-denkproces toegepast op EA eruit?
Stel je voor dat je een probleem moet oplossen. Ga ervan uit dat je niet wordt gebombardeerd met oplossingen die al voor je zijn uitgedacht ("Ontwerp alstublieft een document-beheersysteem voor ons"), en dat je in staat bent om over het probleem zelf te praten ("We willen beter kunnen samenwerken"). Hoe zou je dit aanvliegen in termen van aanpak en werkproces?
Bekijk de volgende visual (die tamelijk abstract en holistisch is, maar hopelijk nog steeds voldoende details bevat) en kom erachter of het voor jou zinvol is. We hebben een klassieke definitie van het ontwerp-denkproces genomen en geprobeerd het aan te passen voor gebruik in de context van Enterprise Architectuur.
(Oorspronkelijke visualisatie van het ontwerpdenkproces is met dank aan d.schools.)
Het ontwerpdenkproces heeft conventioneel drie fasen: (1) Inspiratie die we hebben herschreven als de "Inform-fase", omdat het in de EA-context niet zozeer gaat om herhaling van de eisen, maar om een glashelder inzicht in de drijfveren. De (2) Ideate en (3) Implement-fase hebben we ongewijzigd gelaten.
Elke fase heeft drie stappen met enkele terugkoppelingen binnen de fase, evenals cyclische loops en iteraties tussen fasen.
In de Inform-fase hebben we de volgende stappen:
1. Begrijp context en doel
Hier probeert de EA een begrip te krijgen van de context en het doel van de vereisten. Context hier betekent het Business Systeem/grotere zakelijke geheel dat wordt beïnvloed door de vereisten. Dit kan worden gedaan via een netwerkmodel of een oorzaak/gevolg-diagram. Deze analyse levert slechts één "toestand" op - de context is wat het is en kan in de meeste situaties niet worden veranderd. Met doel bedoelen we een verklaring of set van verklaringen die rechtvaardigen waarom een bepaalde oplossing nodig is. Wat moet het opleveren? Een korte alinea, idealiter volgens een SMART-structuur, kan helpen. Er kunnen meerdere verklaringen (doelen) zijn.
2. Definieer gebruikers, drijfveren en doelstellingen
Gebruikers: wie zijn de menselijke actoren die het product zullen gebruiken of beïnvloed zullen worden? Wat zijn hun drijfveren en wat willen ze ermee bereiken? Een belanghebbenden analyse, inclusief een RACI, kan zeer nuttig zijn. Een goede aanpak voor deze stap is om de gebruikers te observeren. Noteer niet alleen wat ze zeggen dat hun drijfveren zijn, maar observeer ze ook in hun dagelijkse werkzaamheden om het ongeziene te zien. Vanuit hun gedrag kun je ook nieuwe doelstellingen definiëren. Het is een goede praktijk om je observaties en inzichten met hen te valideren voordat je verder gaat naar de volgende stap. En het is volkomen normaal om terug te gaan naar stap 1 als dat nodig is.
3. Creëer invalshoeken en (succes)criteria
Op basis van de vorige stap kun je invalshoeken creëren, in ontwerpdenken "Personas" genoemd. In plaats van zware, conventionele architectuurperspectieven, kun je gebruikersperspectieven gebruiken. Deze zullen eerder een verhaal vertellen dan structuren vermelden en matrices tonen. Via de gebruikersperspectieven kun je ook succescriteria opstellen die aangeven wat een product of dienst moet doen om bevredigend te zijn voor een bepaalde gebruiker. In de meeste situaties zul je meerdere gebruikersperspectieven hebben en een uitgebreide lijst van succescriteria (tip: je kunt de criteria samenvoegen tot één geaggregeerde lijst om deze beter toegankelijk te maken - deze succescriteria zijn belangrijke informatie voor de volgende stappen). Het is normaal om terug te gaan naar stap 2 als dat nodig is.
In de Ideate-fase zijn dit de stappen:
1. Ideeën bedenken voor oplossingen
Nu kun je beginnen met het bedenken van mogelijke oplossingen. Probeer er zoveel mogelijk op te noemen, er zijn geen beperkingen, maar probeer je wel aan de succescriteria te houden. Neem minimaal drie ideeën mee naar de volgende stap. Dit is het echte creatieve deel van het werk - brainstormen, proberen buiten de gebande paden te denken, concepttekenen, stemmen en proberen een consensus te bereiken. Bij Digital Innovation hebben ontdekt dat een goede methode om het brainstormproces te ondersteunen een gestructureerde methode is, zoals Lean Coffee.
2. Geselecteerde ideeën prototypen
Probeer je ideeën in de praktijk te brengen en kijk of ze werken. In architectuurjargon zijn dit waarschijnlijk de goede oude proof-of-concept (POC's). Er zijn enkele voorwaarden vereist, als je in de IT-wereld opereert. Je moet een omgeving creëren die veel lijkt op je productieomgeving, maar waar zo min mogelijk governance en procedures omheen zijn die een belemmering kunnen vormen voor je innovatieproces (want dat is waar prototyping eigenlijk voor bedoeld is - innovatie stimuleren door hands-on verkenning). Wat je wel nodig hebt zijn applicaties die verband houden met het nieuwe product, datasets en situaties (integratiegedrag) die zo dicht mogelijk bij de huidige productiestaat liggen, zodat je kunt bewijzen dat je prototype daadwerkelijk zal werken in een echte (of bijna echte) context. Probeer minstens twee prototypes te leveren.
3. Prototypes testen met gebruikers
Tijdens deze stap betrek je je gebruikers opnieuw om de prototypes die je hebt gemaakt in de vorige stappen te testen en te valideren. Een belangrijk document om te gebruiken is de lijst met criteria die tijdens stap 3 zijn gemaakt, omdat deze lijst concreet bepaalt wanneer een prototype succesvol is en wanneer niet. Maak een snelle checklist op basis van de criteria. Het is hierbij heel belangrijk dat je je gebruikers observeert terwijl ze werken met het prototype. Probeer opnieuw te zien wat men normaal niet ziet - de dingen die je niet terugvindt in formele documenten.
In de Implement-fase zijn de volgende stappen aanwezig:
1. Context creëren
Nadat je het beste prototype en de beste oplossing hebt geselecteerd, moet je nadenken over de context rond het product (of de dienst) dat je gaat lanceren. Wat zijn de beperkingen, vereisten en mogelijkheden die je moet beheren om het product daadwerkelijk succesvol in "productie" te kunnen lanceren? Denk aan releaseprocessen, beveiligingsrichtlijnen, integratieregels, eigendom en governance, enz.
Soms stuit je op zoveel belemmeringen dat het project in een normale situatie zou worden stopgezet. Echter, je hebt zoveel steun gekregen van belanghebbenden door het ontwerpproces dat je waarschijnlijk kunt rekenen op voldoende steun om het product verder te ontwikkelen. Als je problemen tegenkomt die onoplosbaar lijken, probeer dan deze problemen in een nieuw ontwerpdenkproces mee te nemen om te ontdekken of er oplossingen zijn voor de problemen in plaats van ze te negeren. Als het product voldoende bedrijfswaarde biedt, kan het ook zijn dat de contextuele beperkingen worden opgelost door uitvoerende macht. Zorg ervoor dat je de impact van deze veranderingen in kaart brengt (combinatorische effecten), omdat ze van invloed kunnen zijn op andere producten en diensten die al in "productie" zijn.
Onthoud dat je als architect besluitvorming en politiek kunt beïnvloeden, maar deze gebieden zijn niet jouw verantwoordelijkheid of zorg - je bent een ontwerper, geen manager, en je doel moet zijn om inhoud te leveren om verandering te ondersteunen en mogelijk te maken, niet om de verandering zelf te doen.
2. Geselecteerde oplossing testen
De pilotfase is min of meer een "pre-productiefase", waarin het product wordt gelanceerd in een afgebakend, gecontroleerd testgebied (een geselecteerde groep gebruikers, een bepaald bedrijf, een bepaalde markt). Hier kun je nu ontdekken of het product daadwerkelijk werkt zoals verwacht en of het product goed past binnen de bedrijfscontext.
3. Oplossing lanceren (in productieve context)
Zodra jij en je gebruikers overtuigd zijn dat het product werkt en iedereen enthousiast is om verder te gaan, kun je het lanceren in de productieomgeving. Houd er rekening mee dat het zeer waarschijnlijk is dat er kort na dit evenement nieuwe eisen zullen opduiken als gevolg hiervan, dus blijf betrokken en blijf de gebruikers observeren.
Laatste tips
Het was niet onze bedoeling om een volledig uitgewerkt kader te leveren over hoe je Design Thinking kunt gebruiken voor Enterprise Architectuur, maar we hopen dat we hiermee een denkproces op gang hebben gebracht over de voordelen die Design Thinking zou kunnen hebben voor Enterprise Architectuur - vooral als antwoord op de vraag "Hoe doe je dat?"
We weten dat je nu waarschijnlijk veel verdere vragen hebt over deze aanpak. Misschien over timing-aspecten (we zouden zeggen, tijdbox elke fase tot maximaal twee weken), over het beheer van het proces (denk aan het gebruik van Agile en SCRUM) en misschien over zaken als eigendom (denk aan het toevoegen van product owners, idealiter geselecteerd uit je gebruikersgroep).
Misschien heb je ook vragen over de toepassingsgebieden. We denken dat deze aanpak heel goed kan werken binnen transformatiecontexten, maar we kunnen ons ook voorstellen dat het kan worden aangepast om beter aan te sluiten bij meer operationele omstandigheden, of zelfs op maat kan worden gemaakt voor een specifieke, standaard "EA manier van werken" die een gemeenschappelijk proces kan worden bij het gebruik van Enterprise Architectuur.
Het punt dat we proberen te maken is dat we moeten nadenken over hoe we Enterprise Architectuur meer verkennend, op gebruikers gericht en creatief kunnen maken, verandering omarmen en divergent-convergent denken gebruiken. En dat we door dat te doen tot een meer voorschrijvend proces kunnen komen over hoe we EA daadwerkelijk kunnen laten werken - los van abstracte, moeilijke kaders met over het algemeen een lage waardering door het bedrijfsleven.