Een tijdje terug had ik een gesprek waarin de woorden “experience architectuur” (eXperience Architecture, XA) vielen. Ik was direct geïnteresseerd, want zowel architectuurdenken als user experience zijn al jaren mijn professionele passies. Ik deed zelfs eind 2012 al eens een eerste poging om ze te combineren, en daarmee gebruiksvriendelijkheid een plaats te geven in enterprise architectuurdenken. Maar toen ik de bijbehorende Wikipedia pagina over eXperience Architecture bezocht, was ik toch enigszins teleurgesteld. De auteurs beschrijven daar vooral een user-centered ontwikkelmethode. Natuurlijk is het prima om een beschreven proces te hebben dat helpt om tot uses-centered software te komen. Maar het is geen complete “architectuur”. Dus hieronder mijn beelden over wat eXperience Architecture volgens mij zou kunnen zijn…

Digitale transformatie vraagt om eXperience Architecture

Allereerst, waarom zou je geïnteresseerd zijn in eXperience Architecture? Wel, omdat veel organisaties midden in een digitale transformatie zitten, en dan blijkt zo’n architectuur een goede basis te zijn. Want de essentie van “Digital” is om de klant centraal te stellen, via social media in contact te komen en persoonlijke, informatierijke diensten aan hem of haar te leveren. Waar “traditionele” enterprise architecturen heel intern gericht zijn, hebben we tegenwoordig behoefte aan architectuurdenken dat veel meer ontwerpt van-buiten-naar-binnen.

En omdat de omgeving van een organisatie steeds dynamischer wordt, is het niet alleen voldoende om goede diensten te leveren, je zult ze ook continu moeten verbeteren en aanvullen met nieuwe diensten. Dus inzicht in de zowel processen als tools om dit voor elkaar te krijgen is essentieel. En bepaalde “capabilities” goed ingericht hebben is een must.

Experience architectuur versus experience methode

Voor de buitenwereld lijkt het misschien een beetje spijkers op laag water zoeken, maar er is wel degelijk verschil tussen “een architectuur” en “een methode”. Een methode is namelijk een manier om tot een resultaat te komen. Meestal via beschrijving van een proces, rollen en (tussen)producten. Een architectuur beschrijft hoe een resultaat er generiek uit kan zien, en geeft grenzen waarbinnen mogelijke resultaten kunnen/mogen ontstaan. Dit door principes, gewenste werkwijze(n) en een abstract of generiek resultaat te beschrijven. Methode en architectuur zijn dus niet hetzelfde, maar hebben wel veel met elkaar te maken: een architectuur kan een methode bevatten, en een methode kan naar een architectuur verwijzen.

Echte eXperience Architecture (XA)

In december 2012 deed ik een eerste poging tot een enterprise architectuur voor gebruiksvriendelijkheid. In mijn blog beschreef ik toen de onderstaande onderdelen:

  • In het businessdomein geven we principes voor klantgerichte producten, diensten en processen. En we gebruiken een innovatieproces dat gebruikers centraal zet bij de ontwikkeling van nieuwe diensten.
  • In het applicatiedomein ontwikkelen we applicaties die gebruiksvriendelijk zijn, en geven we de voorkeur aan standaardpakketten die via configuratie optimaal op de beoogde gebruikersgroep zijn in te stellen.
  • In het infrastructuurdomein zorgen we voor voldoende bandbreedte, de inzet van gebruiksvriendelijke, mobiele devices en ondersteunen we een bring-your-own-device (BYOD) beleid.

Maar er is veel gebeurd sinds 2012. En ik kan het bovenstaande ondertussen verder aanscherpen. Daarbij maak ik onderscheid tussen a) het ontwerp van een concrete oplossing, b) de (abstracte) architectuur voor concrete oplossingen die gemaakt kunnen worden (een referentie-architectuur), en c) de architectuur van het proces dat gebruikt wordt om tot concrete oplossingen te komen. B) en c) samen vormen in mijn ogen de eXperience Architecture. Concrete oplossingen hebben natuurlijk hun eigen, unieke ontwerp. Daarnaast delen ze ook het abstracte ontwerp dat onderdeel is van de architectuur. En zijn ze gemaakt volgens het proces en de tools die in de eXperience Architecture zijn beschreven.

Uitgewerkt in het eerdere raamwerk met business-, applicatie- en infrastructuurdomeinen, denk ik aan de volgende onderdelen voor een eXperience Architecture:  

  • In het business domein hebben we een set met gedetailleerde persona beschrijvingen voor de belangrijkste klantgroepen en andere (indirecte) betrokkenen zoals interne gebruikers en regelgevende autoriteiten. Deze beschrijvingen helpen om producten en diensten te leveren die de behoeften invullen van de beschreven doelgroepen. Opgenomen in een referentie-architectuur, zorgen ze dat innovatie- en delivery teams snel aan de slag kunnen. Als innovatieteams tot nieuwe persona’s komen, dan worden deze opgenomen in de referentieset. We hebben ook een overzicht van de kanalen die onze klanten gebruiken. We weten welke het meest gebruikt worden en we weten welke het goedkoopst gebruikt kunnen worden. We monitoren de evolutie van nieuwe kanalen en nemen ze op in onze set als dat opportuun is. De primaire processen zijn klant- of gebruikersgericht ontworpen: ze worden geoptimaliseerd op basis van de persoon die contact zoekt en de context waarin dat contact plaatsvindt. Innovatie- en optimalisatieprocessen zijn ingebed in de organisatie, opgebouwd uit een geïntegreerde combinatie van (Service) Design Thinking, Lean Startup en Agile DevOps.Hiermee borgen we dat we niet alleen vandaag de juiste producten leveren, maar ook in de toekomst. Continu verbeteren en veranderen is een core competentie van de organisatie.
  • Naast gebruikersgerichte applicaties hebben we in het applicatiedomein de beschikking over een bibliotheek met standaard bouwblokken. Deze bevat zowel front-end componenten als proces- en back-end componenten. De standaard componenten zorgen dat ontwikkelaars eenvoudig kunnen voldoen aan Corporate Image / Corporate Design richtlijnen voor een goede merkbeleving. De proces- en back-end componenten voldoen aan corporate principes, richtlijnen en veiligheidsvoorschriften en ondersteunen de privacywetgeving. Kanalen en back-end componenten kunnen onafhankelijk ontwikkeld en ingezet worden. Ze zijn onderdeel van een omni-channel opzet die enerzijds dezelfde (digitale) diensten via verschillende kanalen mogelijk maakt, en anderzijds een klant of andere gebruiker herkent als h/zij via een bepaald kanaal contact zoekt. Op basis van de laatst bekende status in andere kanalen wordt de dienstverlening persoonlijk en relevant gemaakt. Daartoe zetten we big data, analytics en machine learning systemen in. Functionaliteit is gemaakt als microservices en wordt beschikbaar gesteld via een “API-first” strategie. De ontwikkelstraat is volledig geautomatiseerd zodat er vaak en in kleine releases opgeleverd kan worden. Deploymentplatformen registreren uitgebreide (geanonimiseerde) gegevens over gedrag van gebruikers op basis waarvan de dienstverlening gepersonifieerd en geoptimaliseerd kan worden. A/B testing faciliteiten zijn een integraal onderdeel hiervan. Voor medewerkers en partners zijn er tools waarmee makkelijk en veilig een samenwerkingsomgeving voor een virtueel team opgezet kan worden. End-user computing tools ondersteunen business users bij het snel automatiseren van simpele processen. Hierbij hebben zij – na autorisatie – eenvoudig toegang tot verzamelde gegevens.
  • Op infrastructuur niveau maken we gebruik van automatisch schaalbare (cq. elastische) cloud platformen waarmee vooral gewaarborgd wordt dat de eindgebruiker altijd een snel reagerend systeem ervaart. Identity & Access management zijn integraal onderdeel van alle platformen die gebruikt worden. Omgevingen zijn gevirtualiseerd en het beheer is volledig geautomatiseerd. Software wordt gedeployed op basis van immutable container technologie waardoor ongedocumenteerde productiesituaties worden uitgebannen. In-memory databases zorgen dat data snel beschikbaar is. We houden rekening met alle devices die onze klantgroepen gebruiken, inclusief digitale assistenten op mobile devices en smart appliances. Wearables en IoT sensoren en actuatoren worden gebruikt waar nuttig.

eXperience Architecture in een agile omgeving

Ik kom heel wat mensen tegen die architecture en agile niet graag in één zin noemen. Architectuur staat dan voor big-design-up-front denken, en het verspillen van tijd, geld en aandacht door het bedenken van dingen die nooit gebruikt gaan worden. En het bovenstaande riekt hier natuurlijk enorm naar. Want ik heb al allerlei dingen bedacht, en misschien zijn ze inderdaad niet nodig. Immers, “the best architectures, requirements, and designs emerge from self-organizing teams”. En dat klopt, natuurlijk. Maar slimme teams leren ook van wat er in andere teams al bedacht is. Want op de schouders van reuzen is het goed doorpakken, met een mooie runway is het sneller opstijgen, en met een handig, al ingericht platform is het sneller leveren.

De adoptie door agile teams neemt toe als een architectuur herkenbaar hun dagelijkse problemen oplost. We moeten de eXperience Architectuur dus vooral praktisch maken. Bijvoorbeeld doordat

  • Er concrete en rijke persona beschrijvingen beschikbaar zijn, zodat een team meer inzicht heeft in de verwachtingen, drijfveren en wensen van de personen waarvoor ze producten maken en verbeteren.
  • Er concrete overzichten van eisen beschikbaar zijn voor stakeholders die op afstand van het team staan, zoals wet- en regelgevers.
  • Er een goed gedocumenteerde componentenbibliotheek aangelegd is met componenten die al aan de architectuur richtlijnen voldoen.
  • Er een volledig functionerend developer portal is ingericht waar het team APIs kan terugvinden. Met documentatie, met voorbeeld- en testdata en met geautomatiseerde testsets.
  • Er een ontwikkelstraat en deployment platform staan die onder architectuur zijn ingericht.
  • Er concrete richtlijnen zijn die afvinkbaar in de definition of done opgenomen kunnen worden.

Kortom: als de architectuur dusdanig is vertaald naar proces, ontwikkelomgeving en deployment platform, dat het gemakkelijker is om aan de architectuur te voldoen dan om er niet aan te voldoen. En natuurlijk lukt dat niet in één keer. Maar inventariseer en prioriteer dan vooral samen met de teams waar behoefte aan is, en in welke volgorde dat opgeleverd gaat worden.

Gebruiksvriendelijkheid, gebruiksgemak en experience

Gebruiksvriendelijkheid, of gebruikersvriendelijkheid (bijna hetzelfde, zie ook het advies van de taalunie), gebruik ik als een combinatie van gebruiksgemak (ook wel bruikbaarheid, usability) en gebruikservaring (user experience). Waren we in het verleden al blij dat we iets bruikbaar wisten te maken, in de huidige Experience Economy gaat het een stap verder: het gebruik moet ook een prettige ervaring opleveren. En afhankelijk van het soort gebruiker, kunnen we het dan hebben over customer experience, partner experience, employee experience of – in het algemeen – user experience.

In het verleden konden we met minder bruikbare software toch nog “succesvol” zijn. Tegenwoordig lukt dat absoluut niet meer. Vroeger was “de software” namelijk een applicatie die alleen door medewerkers werd gebruikt. En die medewerker konden we een uitgebreide training geven, zodat h/zij ondanks alles productief kon worden met de software. Tegenwoordig is “de software” een digitale dienst of product, en “de gebruiker” is een klant of partner van onze organisatie. Die vanwege 24/7 self-service steeds vaker zelf achter de knoppen zit, en verwend is door wat de concurrentie en de grote digitale platformen leveren. Die geen tijd heeft om een uitgebreide handleiding door te nemen. Die keuze heeft uit een steeds groter arsenaal aan vergelijkbare en concurrerende diensten. Gebruiksgemak is een hygiënefactor en een goede experience is van levensbelang.

Tags: , , , ,