Artikel

Architectuurvisualisaties maken projecten tot een succes

Veel organisaties werken onder architectuur in projecten, maar nog lang niet altijd borgt dat de slagingskans van deze projecten. Op basis van mijn praktijkervaring van de afgelopen jaren zie ik dat het in projecten veel uitmaakt of er wel of niet een architectuurvisualisatie zoals een blauwdruk (een totaal overkoepelende ontwerptekening) beschikbaar is van het gehele systeem of van de gehele verandering dat in een project wordt vormgegeven. In dit artikel pleit ik voor het op een bepaalde wijze maken van een architectuurvisualisatie voor een systeem of verandering, als bijdrage voor het succes van een project.

Architectuurvisualisaties geven projecten inzicht

Goede architectuurvisualisaties tonen vooral de concepten en principes die onderdeel zijn van de architectuur van een organisatie. Tevens tonen ze de implementatie-impact van de concepten en principes op de organisatie. Ook tonen ze de relatie van de concepten en principes tot de uitgangspunten en doelen van de organisatie.

Stel dat de directie van een organisatie als strategische uitgangspunten heeft:

  • We streven kostenreductie na.
  • We streven verhoging van snelheid van dienstverlening na richting onze klanten.
  • We streven klantgerichtheid na in de wijze waarop we klanten bedienen.
  • We streven het focussen op onze kernactiviteiten na.
  • We streven kostenleiderschap in de niet kernactiviteiten na.

En stel dat er ook in de organisatie vijf projecten zijn opgestart met exotische namen en unieke oplossingen om invulling te geven aan deze strategische uitgangspunten.

Sinds enkele dagen is een ervaren enterprise architect bij de organisatie en heeft goed geluisterd en rondgekeken in de projecten om te begrijpen waarom ze de dingen doen die ze doen ten einde bepaalde doelen te realiseren. In de projecten zijn hier en daar mooie deelarchitectuurplaatjes aanwezig (zeg maar fragmenten van het geheel). Echter hebben deze vijf projecten tot nu toe niet een gemeenschappelijke architectuurvisualisatie, zoals een structuurvisie, ontwerpschets of blauwdruk die zorg draagt voor samenhang en gemeenschappelijk beeld en begrip van de verschillende deeloplossingen die in die vijf projecten worden gerealiseerd. En dat terwijl de organisatie zegt onder architectuur te werken.

De ervaren enterprise architect zal nu bijvoorbeeld denken: “Gezien de strategische uitgangspunten, en als ik kijk naar de identiteit, missie en visie van de organisatie, zouden de concepten self service, klantcontactcentrum, procesintegratie en shared service center, voor zover nog niet aanwezig bij de organisatie, goed onderdeel van de enterprise architectuur kunnen worden gemaakt. Indien deze concepten goed werken in de organisatie, geeft dit ruimte aan het verwezenlijken van de uitgangspunten in de projecten, maar dan met meer structuur en aansturingmogelijkheden door de directie. De oplossingen die nu in verschillende projecten worden gerealiseerd raken allemaal delen van de concepten die ik voor me zie in de enterprise architectuur. Dus de projecten zouden met notie van deze concepten ook met meer resultaat aan hun deeloplossing kunnen werken.”

“Hhmm, denkt de architect, als ik nu eens een visualisatie maak om de directie ervan te overtuigen dat deze concepten passen bij hun uitgangspunten en dat ze in de projecten in feite invulling/vorm geven aan deze concepten. Maar dan moet ik wel laten zien waarom deze concepten passen en de uitgangspunten realiseren. Laat ik maar eerst beginnen met de principes van de concepten te achterhalen.”

Het principe van self service is bijvoorbeeld:

Door de klant de door hem gekozen producten en diensten zelf te laten registeren, zijn gegevens zelf te laten invoeren en wijzigen en ook zelf voor de betaling te laten zorgen, wordt ervoor gezorgd dat de organisatie in staat is met minder inzet of tussenkomst van medewerkers meer klanten te bedienen, waarmee tegen lagere kosten en hogere snelheid meer producten en diensten worden verkocht.

Het principe van procesintegratie is bijvoorbeeld: Door activiteiten binnen een organisatorische eenheid zo goed mogelijk op elkaar af te stemmen in werkprocessen en activiteiten over eenheden op elkaar af te stemmen in bedrijfsprocessen, wordt ervoor gezorgd dat men in een organisatie efficiënter en effectiever het werk kan uitvoeren waarmee kosten worden verlaagd.

Het principe van een klantencontactcentrum is bijvoorbeeld: Door het bundelen van alle klantcontacten in één punt in de organisatie, met integratie van alle contactkanalen, wordt er voor gezorgd dat er meer zicht is op alle contacten met een klant, zodat de klant door de organisatie, beter, sneller, efficiënter, consistenter en rechtmatiger kan worden bediend.

Het principe van een shared service center is bijvoorbeeld: Door het bieden aan verschillende (interne) klanten van specialistische ondersteunende diensten, zoals HR, inkoop, ICT en financiële administratie tegen een verrekenprijs, wordt ervoor gezorgd dat de klanten kunnen genieten van schaalvoordeel en zich kunnen focussen op hun kerntaken.

Beelden verkopen een oplossing

Je ziet nu als lezer de architectuurvisualisatie al voor je… (de werking van de echte principes van deze concepten bij elkaar).

Self service, procesintegratie, shared service center en klantcontactcentrum zouden belangrijke concepten kunnen worden die onderdeel zijn van de enterprise architectuur van de organisatie. Met het visualiseren van deze concepten en de wijze waarop ze worden toegepast in de organisatie, laat de architect op begrijpelijk wijze de architectuurprincipes (van deze concepten) en hun impact op de organisatie zien. Het is voor de directie nu eenvoudig om ja of nee te zeggen tegen de implementatie van de concepten in de organisatie en om deze concepten en hun principes richtinggevend te laten zijn voor ontwikkelingen in projecten.

Onze ervaren enterprise architect heeft nu alle principes en concepten gevisualiseerd op elementen- en componentenniveau in een architectuurvisualisatie die de toekomstige organisatie toont. Deze TO-BE enterprise blueprint toont het eindresultaat van alle projecten bij elkaar. De projecten hebben nu in de vorm van een A0-formaat een gemeenschappelijk beeld en begrip van de nieuwe organisatie. Alle mijlpalen en deliverables van de projecten zijn te linken aan elementen en componenten op de A0-poster.

Een andere manier van kijken als randvoorwaarde

Om op de hiervoor beschreven wijze met architectuur te kunnen omgaan is een ander begrip van enterprise architectuur, architectuur, concept en principes nodig dan nu in de huidige praktijk bij organisaties wordt gebruikt. Daarbij hanteer ik de open methode Dragon1 voor het werken met architectuur, om tot dergelijke hiervoor genoemde architectuurvisualisaties te komen. Dit vergt wel een andere manier van kijken. En dan een manier van kijken die ook al in andere vakgebieden wordt gehanteerd.

Een architectuur is volgens Dragon1 het samenhangend geheel van toegepaste concepten en principes op een bouwwerk. Waarbij een onderneming (enterprise) als bouwwerk mag worden beschouwd omdat het constructieve, operatieve en decoratieve dimensies heeft.

Een concept is volgens Dragon1 een aanpak, werkwijze, idee of abstractie. Bijvoorbeeld het concept ‘Klantvraaggericht werken’.

Een principe is volgens Dragon1, anders dan veel architectuuraanpakken doen vermoeden, de gehandhaafde wijze waarop een entiteit, zoals een systeem, concept of fenomeen, werkt, in elkaar steekt of plaatsvindt met een bepaald geproduceerd resultaat tot gevolg.

Bijvoorbeeld het principe van klantvraaggericht werken zou kunnen zijn: door in de organisatie altijd de klantvraag centraal te stellen bij het samenstellen, aanbieden en leveren van producten en diensten aan klanten vanuit een continu proces van meten, analyseren en herontwerpen van het assortiment, wordt ervoor gezorgd dat de klanten de producten en diensten meer en beter zullen herkennen waarmee de organisatie meer producten en diensten zal verkopen aan een hoger aantal klanten.

Zo zijn er dus conceptprincipes, ontwerpprincipes, maar ook architectuurprincipes. Als een architectuur het samenhangend geheel is van concepten (zeg maar de architectuurconcepten), dan zijn architectuurprincipes de principes die zijn meegekomen met de concepten (zeg maar de architectuurconcepten-principes). N.B. Dit is dus heel wat anders dan architectuurprincipes als richtinggevende uitspraken. Hier zijn architectuurprincipes harde werkingsgerichte uitspraken waar je op kunt bouwen en vertrouwen.

De enterprise architectuur, de architectuur van een ondernemingsbouwwerk, is dan bijvoorbeeld het samenhangende geheel aan toegepaste besturingconcepten, businessconcepten, informatieconcepten en technologische concepten op die onderneming.

Vanuit dit begrip van architectuur, concepten en principes wordt, als het goed wordt gedaan tenminste, de principes (de werking) van concepten in een bouwwerk gevisualiseerd. En de impact van de principes op een bouwwerk en de noodzakelijkheid van principes in het licht van doelen. Je spreekt dan van een architectuurvisualisatie. Correcte enterprise architectuurvisualisaties tonen daarmee de concepten die onderdeel zijn van de architectuur waarmee de identiteit, missie, visie, strategie en identiteit van een organisatie mogelijk worden gemaakt danwel worden versterkt.

Breng de werking in beeld van toegepaste concepten

Als van een onderneming de enterprise architectuur in beeld wordt gebracht, bijvoorbeeld de wijze waarop concepten zoals self service, procesintegratie, shared service center en klant contact centrum zijn toegepast, worden hiermee, indirect, de architectuurprincipes van die organisatie in beeld gebracht. De werking van de concepten in de organisatie wordt getoond.

Vaak zoomen visualisaties alleen in op logisch en fysiek niveau en worden de elementen en componenten van concepten in een visualisatie los van hun conceptuele samenhang getoond. Deze visualisaties zijn wellicht heel mooi en nuttig, maar zijn echter GEEN architectuurvisualisaties. Je mist de conceptuele samenhang van de elementen en componenten die samenwerken en bepaalde resultaten produceren. Met correcte architectuurvisualisaties zie je welke concepten en principes wel of niet (voldoende) worden toegepast in het ontwerp van een systeemoplossing.

Dit is ook precies waar projecten behoefte aan hebben: de werking van een concept doorvoeren of overbrengen in de oplossing die ze realiseren. Als bijvoorbeeld self service als concept een bepaald voordeel heeft (als je menselijke handelingen op de front office kunt uitsluiten), dan wil je met de gebouwde self serviceoplossing dat voordeel kunnen verzilveren, maar dan is het wel een randvoorwaarde dat de oplossing voldoende conform het self service principe werkt (dus ook echte menselijke handeling op de front office uitsluiten). In feite weet iedereen dit wel, maar zijn er altijd ontwerpschetsen van het concept en ontwerptekeningen van het principe nodig om te toetsen en te zien of dat de oplossing werkt conform het conceptprincipe.

Een architectuurvisualisatie die eigenlijk in elk project onder architectuur onmisbaar is, is de blauwdruk. Toch wordt deze blauwdruk nodig gemist in menig project. De blauwdruk is een ontwerptekening op A0-formaat die toont uit welke elementen (logische functionele entiteiten) en/of componenten en objecten (digitale/fysieke technische entiteiten) de systeemoplossing bestaat en hoe deze entiteiten met elkaar samenwerken en met de entiteiten in de omgeving van de systeemoplossing. Het mooie van een dergelijke blauwdruk is, dat je alle eisen die zijn gesteld aan de systeemoplossing kunt relateren aan de gekozen elementen en componenten en dat je de gehanteerde concepten en principes in de architectuur en gemaakte ontwerpkeuzes in het ontwerp kunt aanwijzen.

Een dergelijke blauwdruk is daarmee een praatplaat voor de opdrachtgever en stuurgroep om te sturen en een werkplaat voor de projectmedewerkers om mee te ontwikkelen. Kortom, onmisbaar in elk project. Maar nog belangrijker: ook maakbaar in elk project. Dit omdat het alleen informatie bevat of kan bevatten die is afgesproken, overeengekomen of gaat over wat mensen doen, gaan doen en opleveren. En als deze informatie niet beschikbaar is, is in feite het project op die punten niet in control.

Uit de vele gesprekken met bouwkundige architecten die ik heb gehad is gebleken dat zij met visualisaties ook vaak willen laten zien welke concepten (en onderliggende principes) ze in het architectuurontwerp hebben toegepast. Als bouwkundige architecten hiermee hun toegevoegde waarde laten blijken, waarom zouden enterprise architecten dan die kans laten liggen? Nu we weten dat het werkt, op basis van praktijkervaring, kunnen we deze nieuwe inzichten het beste maar op grote schaal gaan gebruiken: maak als architect voortaan voor projecten architectuurvisualisaties, in de vorm van ontwerpschetsen en ontwerptekeningen, die de werking (principes) tonen van de concepten die ze in projecten met systeemoplossingen vormgeven.

Focus op correcte architectuurvisualisaties, zorgt dus voor het stuurbaar maken van de toepassing van architectuurprincipes. Dus beste lezer, wanneer gaat u een echte architectuurvisualisatie maken voor een project?

Categorie:   
Auteur(s)
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

 
Reacties
Viktor Grgic op donderdag 7 april 2011 15:46

Mark,

Het is vast vloeken in de kerk wat ik ga zeggen, maar ik hoop dat je het kan waarderen. Titel van je artikel is eigenlijk de toppunt van uitspraken gebaseerd op vaagheid en het ontbreken van argumenten. Hoewel ik zeker voor visualisaties ben, wat heeft eigenlijk het succes van een project mee te maken? Je zegt ook verderop, het levert "bijdrage"...
Je noemt voorbeelden van strategische uitgangspunten waarop je onzin-test op los kan laten: Zet iedere zin in negatieve vorm en kijk of het onzin is. Als wel, dan is de uitspraak te vanzelfsprekend en dus te weinig zeggend. Bijv. "We streven kostenverhoging na."

Daarna geef je uitleg van typische enterprise architectuur werk weer. Ofwel: pak een stel strategische vaagheden, ongeveer 4 hype termen (bij minder dan 4 is architectuur niet stoer genoeg en meer wordt het te veel van het goeie en dus helemaal ongeloofwaardig) en koppel die aan de veronderstelde behoefte. De behoefte gaat dan over zeer lange termijn en morgen al net even anders is; en over een jaar totaal anders. Hier is eigenlijk niet veel mis mee omdat we toch iets moeten hebben op langere termijn. Maar, laten we ajb eerlijk zijn over de enorme hoeveelheid aannames die we in dit proces maken en daarmee veranderlijkheid ervan.

Ik heb vooral moeite met uitspraken die op het eerste gezicht goed onderbouwd zijn. Het is een onbewuste deceptie, want argumenten zijn niet om te onderbouwen, maar slechts om diegene te overtuigen die uitvoerbaarheid en business case hoe dan ook niet goed begrijpen. Daarnaast is vast wel nooit gebeurd dat een architect afgerekend wordt op dit soort uitspraken. Dat is door vaagheid namelijk onmogelijk.
Ik heb het over de "principes" die slechts oplossingen zijn.

Nogmaals, ik vind visualisaties heel belangrijk en vooral die in de hoofden van mensen. Welke middelen daarvoor gebruikt worden is slechts / maar wel een interessante bijzaak. De noodzaak voor blauwdrukken zegt iets over vaak onnodige complexiteit en er zijn net zoveel argumenten om ze niet te hebben omdat juist door blauwdrukken projecten mislukken.

Ik zou dus visualisaties gebruiken om ideeën over te brengen en complexiteit te bedwingen vooraf. Daarbij is enige bescheidenheid op zijn plaats. Namelijk, we weten immers niet of "afstemming van processen op den duur geldt oplevert", maar we gaan het ontdekken en tijdig leren en bijstellen.

Een overtuigingstocht op basis van visualisaties is dan meer marketing dan architectuur en reclames heb ik nooit leuk gevonden.

gr., Viktor

markpaauwe op donderdag 7 april 2011 19:30

Viktor,

Ja, ik kan je reactie wel waarderen. Alleen door discussie komt de mens verder. En je hoeft het helemaal niet met me eens te zijn. Echter blijkt alleen keer op keer als ik in grote IT-projecten zit, dat het bijna altijd ontbreekt aan architectuurvisualisaties, zoals blauwdruk (een totaal overkoepelende ontwerptekening). Ik zeg vaak: bouwen zonder ontwerptekening is wel het laatste wat je moet doen als je geen geld wilt weggooien. Ook in een agile omgeving!

Met visualisaties leg je keuzes voor aan degene die keuzes moeten maken en met architectuurvisualisaties leg je in alle eenvoud de werking van te kiezen of gekozen concepten en principes uit.

Ik maak altijd mee dat bestuur en directie graag met een architectonische blauwdruk meer sturing willen en kunnen geven aan fundamentele strategische veranderingen. En je geeft harde inhoud aan wat anderen zien als vage kreten.

Wat dacht je hoeveel organisaties wel een concept implementeren (zoals ik schets in het artikel), maar het uiteindelijk niet aan het werken krijgen zodat het echt voordelen gaat opleveren? Een visualisatie die laat zien wat er voor nodig is om het concept te laten werken is (of was) dan goud waard (geweest). De keuze is dan aan jou om wel of niet die echte architectuur visualisatie te maken of er altijd voor te pleiten dat sowieso die visualisatie worden gemaakt.

NB: ik zal ook de blauwdruk die ik hierboven in het artikel beschrijf op korte termijn gaan visualiseren en bijvoegen in het artikel.

Als de complexiteit van een oplossing of een architectuur voor een gewone sterveling in woorden veel te complex is (lees een tekstueel document van honderden pagina's) om te begrijpen, dan is een architectuurvisualisatie die wel overtuigd precies datgene wat je als architect moet inzetten. Dus mijn overtuigingstocht is dan wellicht anders dan die dan van jou, maar ik vind het juist precies waar architectuur over gaat. Want het gaat om het resultaat.

Viktor Grgic op vrijdag 8 april 2011 9:58

Mark,

Ik kan me redelijk vinden in je betoog. Er zijn veel "het is nu eenmaal zo" uitspraken:

"Directie en bestuur graag meer sturing willen"
Er zijn inmiddels steeds meer directies en bestuurders die echt leiden ipv sturen. Dus, ik ben met je eens, maar ik vind dat er te veel control freaks in directies zitten. Als architect is het een zware dillema: Wie dien je eigenlijk? Gebruiker/klant en daarmee organisatie of de managers. Dat is vaak niet hetzelfde, helemaal bij control freaks. Ik vind dat in IT wereld vakmensen op de werkvloer horen te sturen. Ze zijn ook de enige die competent genoeg zijn. Nogmaals, het sturen en leiden zijn voor mij twee totaal verschillende dingen. Helemaal in Agile teams en organisaties is er vaak gebrek aan leiders.

"Visualisatie maken om impact, risico's, voor- en nadelen van architectuur te laten zien"
Helemaal mee eens. Het ging mij meer om de morele kant van zoiets. Zijn we nou echt zo zeker van dat bedachte grote enterprise architectuur daadwerkelijk iets oplevert. Dat geloof ik namelijk niet, helemaal als je die nederlandse dramaprojecten ziet. Die schijnzekerheid heeft enorme consequenties. Denk aan enorme mislukte investeringen als gevolg van die zekerheid. Waarom moeten we altijd grote sommen geld uitgeven voordat we überhaupt iets nuttigs voor terugkrijgen?

gr., Viktor

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.