Artikel

De NORA en GEMMA architectuurvisualisaties kunnen veel beter!

De architectuurvisualisaties die worden meegeleverd bij de NORA en GEMMA, kunnen veel meer sturing geven aan het werken onder architectuur dan dat ze nu doen. Dit kan bijvoorbeeld door de abstractieniveaus in de visualisaties veel meer van elkaar te scheiden. Maar ook door abstractieniveaus in verschillende visualisaties uit te werken en volledig te maken ten voordele van de herleidbaarheid van keuzes. In de visualisaties zou meer de samenwerking tussen de informatiesystemen terug moeten komen en niet alleen de functionele decompositie van de informatievoorziening in informatiesystemen. Dit verbetert het zien van mogelijke keuzes en het nemen van beslissingen in een ontwerp.

In het artikel van september 2010 ‘Dragon1 Visualisatietips - Effectief de architectuur zichtbaar en stuurbaar maken’, heb ik aangegeven dat veel architectuurvisualisaties in feite samengestelde visualisaties zijn met verschillende abstractieniveaus door elkaar heen. In dit artikel ga ik een paar kleine voorbeelden geven bij een bekende GEMMA architectuurvisualisatie, om de lezer te inspireren ook al dit soort praatplaten nauwkeuriger en veelzeggender te maken.

Architectuur, of het totaalconcept, is volgens Dragon1 altijd te visualiseren 

Architectuur is, in Dragon1, de kunst en kunde van het ontwerpen en realiseren van bouwwerken. Zo ook bij enterprise architectuur en informatie architectuur. Een bouwwerk is op te vatten als een complex van systemen die zorgen voor constructie, operatie en decoratie in het complex. De architectuur, of het totaalconcept, van een bouwwerk is, volgens Dragon1, altijd te visualiseren door de toepassing van concepten in beeld te brengen. In elke architectuurvisualisatie staat daarom wel een bepaald bouwwerk centraal. Een bouwwerk zoals een gehele onderneming, een bedrijfssysteem, een bedrijfsproces, een informatievoorziening, een informatiesysteem of een ICT-infrastructuur. Van een bouwwerk is een architectonische schets, tekening, diagram of fotografisch beeld te maken, allemaal soorten visualisaties. En in die schets, tekening, diagram of fotografisch beeld kunnen we het bouwwerk op conceptueel, logisch danwel fysiek niveau beschouwen en te voorschijn laten komen. 

Op conceptueel niveau worden de gemaakte keuzes in conceptschetsen getoond, nog niet helemaal definitief, en de opdrachtgever heeft dan het gevoel dat grote veranderingen op hoofdlijnen nog te maken zijn.

Op logisch niveau zien we in principetekeningen dat de concepten vertaald zijn in logische functionele entiteiten en gaan we in op de samenwerking van deze entiteiten als een geheel. Belanghebbenden en projectleiders krijgen zo een goed beeld over hoe de oplossing gaat werken en kwalitatieve- en prestatievoordelen gaat opleveren.

Op fysiek niveau zien we in componentdiagrammen hoe de logische functionele elementen zijn doorvertaald in fysieke of digitale technische componenten en objecten. Voor bouwers en engineers ligt er dan een bouwplan klaar waarover geen misverstand kan bestaan.

Op het fysieke implementatieniveau zien we in fotografische technische productbeelden hoe componenten en objecten zijn doorvertaald naar producten en diensten van leveranciers, geplaatst in de omgeving en werkplek van gebruikers. Deze beelden geven sfeer, emotie, gevoel en beleving aan betrokkenen, zoals medewerkers en klanten.

Hoe beter de abstractieniveaus van elkaar zijn gescheiden in visualisaties, des beter dienen de visualisaties hun doel. In de GEMMA architectuurvisualisatie in figuur 3 lopen de abstractieniveaus teveel door elkaar en zijn ze afzonderlijk onvolledig weergegeven. Zie figuur 1 voor een referentiemodel van de hier behandelde visualisatietheorie.

Figuur 1: Dragon1 Model - Visuele Enterprise Architectuur (klik op de afbeelding voor een vergroting)

Laat beschouwingsniveaus volledig terugkomen, maar in verschillende visualisaties
Een visualisatie is voor een grote groep personen zeer begrijpelijk en duidelijk wanneer er steeds één abstractieniveau tegelijk wordt gehanteerd. Stel je wilt een klanteninformatiesysteem als bouwwerk tonen op conceptueel niveau, met alleen als voorbeeld hoe bepaalde onderdelen aanwezig zijn en samenwerken.

Figuur 2: Conceptschets Klanten Informatiesysteem

Door deze visualisatie te voorzien van een titel als ‘conceptschets van het toekomstige KIS3000’, of bijvoorbeeld ‘concepttekening van het “huis” Klanten Informatie Systeem’, is het direct duidelijk dat het er hier om gaat hoe iets er ongeveer uitziet en niet hoe het daadwerkelijk is of er uit komt te zien. Want een concept is een concept en nog geen daadwerkelijk fysiek systeem.

In figuur 2 wordt overigens een prestatieaspect duidelijk: De inzet van een integraal klantbeeld leidt tot meer verkopen. Het integraal klantbeeld wordt opgebouwd door informatie uit verschillende databases bij elkaar te nemen. De logische functie en technische vorm van aspect van het concept in de schets worden globaal duidelijk: de architectuur van dit systeem is in beeld.

Lastig wordt het wanneer in de conceptschets van dat informatiesysteem ook entiteiten worden gevisualiseerd op fysiek niveau, met productnamen of zelfs een leveranciersnaam. De visualisatie wordt dan verwarrend: Want wat zijn de conceptuele entiteiten die globaal een richting aangeven, wat zijn de logische entiteiten en fysieke entiteiten die letterlijk gevolgd dienen te worden. Staan op de visualisatie alleen maar ideeën, definitieve ontwerpkeuzes of verplichte standaarden? Welke ruimte voor keuzes is er voor de ontwikkelaars of uitvoerenden? Welke prestatie- of kwaliteitsaspecten worden ingevuld door de gekozen entiteiten? Deze onduidelijkheid komt naar voren bij de GEMMA architectuurvisualisatie in figuur 3.

Draag zorg voor herleidbaarheid

Een visualisatie dwarsboomt de herleidbaarheid van gemaakte keuzes als in een visualisatie fysieke entiteiten staan, waarbij nergens duidelijk wordt gemaakt in de visualisatie of in enig document, van welke logisch entiteit het een invulling is, of bij welk concept een bepaalde logisch element behoort. 

Wanneer het gaat om architectuurvisualisaties is herleidbaarheid van het grootste belang. Immers het enige argument om te kiezen voor bepaalde componenten (technische entiteiten) bij bepaalde elementen (logische functionele entiteiten) is dat ze invulling geven aan de concepten die passen bij de uitgangspunten van de opdrachtgever.

Omdat visualisaties veel vaker dan de bijbehorende tekst worden geraadpleegd, gaan visualisaties een eigen leven leiden. Het is dan van belang dat in de visualisatie, ook al is het een praatplaat, zaken correct staan weergegeven in het licht van de boodschap die zij uitdraagt. En dan niet in het licht van hoe je het daadwerkelijk moet gaan bouwen. Het is immers een praatplaat.

Figuur 3: Een GEMMA architectuurvisualisatie met verschillende abstractieniveaus en functionele decompositie (klik op de afbeelding voor een vergroting)

De GEMMA visualisatie nader bekeken

De GEMMA visualisatie in figuur 3 toont entiteiten op verschillende abstractieniveaus. De visualisatie toont concepten (conceptuele entiteiten), elementen (logische entiteiten), componenten (fysieke entiteiten) en technische producten (fysieke entiteiten die afkomstig zijn van een bepaalde leverancier en als product worden aangeboden).

Zo worden op de visualisatie, de entiteiten DigiD en Digimelding getoond. Dit zijn echter technische producten (dus fysieke entiteiten) van een leverancier van overheidsoftwareproducten. We zien in deze GEMMA visualisatie echter niet welke logische functionaliteit achter DigiD-burger of Digimelding schuilgaat, ook al kunnen we daar wel naar raden. Deze GEMMA visualisatie heeft ‘Informatie Architectuur’ in de titel staan, dus je zou op zich geen productnamen of leveranciersafhankelijkheid verwachten.

Applicaties en voorzieningen die geprojecteerd worden in deze GEMMA architectuurvisualisatie kunnen beter worden voorzien van hun functionele logische naam dan van een productnaam. Dat er op enig moment gekozen is, of moet worden gekozen voor technische producten bij de implementatie van deze informatie architectuur, is evident. Alleen dient er ook altijd een visualisatie of beschrijving te zijn, waaruit blijkt welke functionele logische onderdelen nodig zijn in het geheel en welke afwegingen zijn gemaakt om een bepaald functioneel logisch onderdeel (een element) door te vertalen naar een technisch digitaal of fysiek onderdeel (een component) en vervolgens dat component weer door te vertalen naar een fysieke / digitale implementatie (een technisch product).

Dit geldt ook voor MijnOverheid.nl die in de visualisatie wordt genoemd. Dit lijkt de naam van een website en is dus een technisch product. Maar wat is de functie van deze website? Wat voor een soort website is het? Welke techniek (componenten) dienen te worden gebruikt om invulling te geven aan hoe de website wordt gebruikt? Allemaal vragen die worden op geroepen door op deze wijze in een architectuurvisualisatie technische producten te noemen, zonder dat er een component of element aan ten grondslag ligt.

Bouwkundige architecten gebruiken hiervoor vaak een haallijn om extra informatie toe te voegen, als bijvoorbeeld het symbool van een entiteit onvoldoende duidelijk maakt wat er precies mee wordt bedoeld.

Figuur 4: Verduidelijk de functie van een component

De vraag is: nu wat zou er bij de haallijn van DigiD-burger en Digimelding komen te staan als functie, elementnaam en componentnaam. De ‘blokjes’ als symbool in de GEMMA visualisatie verraden niet veel meer dan dat DigiD-burger een entiteit is van de informatievoorziening van een organisatie. Maar of het een huidige ongewenste of toekomstige noodzakelijke entiteit is, is niet duidelijk.

Geef richting met een architectuurvisualisatie

Zoals het nu gesteld wordt zegt de GEMMA architectuurvisualisatie in feite: Elke CRM, CMS en DMS systeem is goed en is onderdeel van de midoffice. En er wordt gezegd: het is goed dat je EN een CRM EN een CMS EN een DMS systeem hebt. Maar wanneer je als organisatie deze informatie architectuur hebt dan draagt dat niet bij aan het oplossen van problemen in een organisatie, maar juist het in stand houden ervan. Deze plaat zou richting moeten geven, in plaats van te zeggen: laat alle verschillende soorten systemen maar tot in lengte van dagen naast elkaar bestaan. Dus welke soort content wel in het CMS en welke soort content in het DMS? En wat voor soort systeem mag de productencatalogus zijn? In dat betreffende blokje staat geen afkorting van een soort informatiesysteem. Dus zelfs een excelsheet zou hier bij wijze van spreken volstaan.

Geef visuele informatie over samenwerking

In de GEMMA visualisatie staan vele gele blokken die waarschijnlijk informatiesysteem, softwareapplicatie of softwareapplicatiecomponent dienen voor te stellen. Op zich mag dit best in een praatplaat, maar dan dient te kijker wel goed bediend te worden met informatie over de functie en toegevoegde waarde over dat gele blokje ten opzichte van de rest. In figuur 5 wordt echter de kennis van de kijker danig op de proef gesteld. Natuurlijk wordt terecht verondersteld dat de kijker weet wat CRM, CMS en DMS betekent. Maar dan is het niet nodig om die afkorting uit te schrijven zoals nu in de blokjes gebeurt. Wel is het nodig om aan te geven hoe deze soorten informatiesystemen met elkaar samenwerken, gezien de zeer grote overlap in functionaliteit die ze hebben. Ook is het nodig om aan te geven welke soort CRM, CMS en DMS gewenst zijn voor deze informatie architectuur.

Figuur 5: Inconsistentie in naamgeving van entiteiten

In figuur 5 zien we vier haallijnen die een mogelijke functie aangeven bij elk van de systemen. In deze systemen staat op inconsistente wijze veelal een soort informatiesysteem weergeven zonder dat duidelijk wordt voor welke soort betekenisvolle gemeentelijke-gegevens deze systemen bedoeld zijn. Figuur 5 maakt duidelijk dat deze GEMMA visualisatie weinig tot geen richting geeft bij het oplossen van ontwerpvraagstukken die liggen op het terrein van: welke systeem is voor welke gegevens het beste te kiezen als bron en hoe werken de systemen het beste samen?

Een architectuurplaat hoort eigenlijk niet alleen maar een functionele decompositie aan te duiden. Het geeft weinig informatie wanneer een architectuurplaat alleen maar zegt welke soort informatiesystemen onderdeel zijn van een midoffice. Dan krijg je al gauw de opmerkingen: ‘Ja, dit weet iedereen al.’ ‘Wat is nu de toegevoegde waarde van deze architectuurplaat?’

Informatie die je wellicht zou verwachten is bijvoorbeeld: hoe werken deze verschillende soorten informatiesystemen harmonieus samen? Welke systeem is voor bepaalde type entiteiten de bron, en welke soort berichten worden door het ene systeem aan het andere gestuurd? Een voorbeeld van een dergelijke visualisatie over samenwerking en bron staat in figuur 6 weergegeven.

In de visualisatie in figuur 6 staat als voorbeeld, en dit is puur een voorbeeldvisualisatie, welke soort systemen voor welk soort beheer van informatie wordt gebruikt. En voor welke gegevens deze systemen de bron vormen binnen de gehele organisatie, waarover en met welke technologie deze systemen met elkaar communiceren en uit welke technologie deze systemen bestaan. Deze visualisatie geeft ten opzichte van de GEMMA visualisatie veel meer architectuurinformatie in de zin van dat het laat zien hoe bepaalde vraagstukken zijn opgelost: in dit geval van samenwerking tussen de systemen aangaande bepaalde gegevens.

Figuur 6: Dragon1 visualisatie die samenwerking tussen systemen en gegevensbronnen toont

Samenvatting en conclusie

Een praatplaat, zoals de GEMMA architectuurvisualisatie, zendt boodschappen uit. De boodschappen mogen nooit de verkeerde boodschappen zijn of verwarrend zijn. De GEMMA visualisatie in figuur 3, zendt boodschappen uit die eenvoudig verkeerd kunnen worden opgevat of verkeerd worden uitgelegd.
Daarom zou ook deze praatplaat zich beter (impliciete) aan de spelregels kunnen houden.

Wees je ervan bewust dat je met een architectuurvisualisatie al snel zegt hoe goed iets is of hoe iets hoort. Als je dit niet bedoelt, maak dat dan heel goed duidelijk.

Zorg altijd voor een visuele of tekstuele herleidbaarheid van de keuzes voor technische producten, terugvertaald naar componenten en van componenten naar elementen en van elementen naar concepten. Immers met je keuze voor oplossingen, heb je een architectuur (of totaalconcept) ontworpen waarmee de organisatie in staat is haar strategische uitgangspunten, bedrijfsdoelen, randvoorwaarden en eisen te kunnen realiseren.

Welke symbolen je gebruikt in de visualisatie is veel minder belangrijk dan dat je de werking of het pattern visualiseert dat op gang dient te worden geholpen of te worden gerealiseerd. Het gaat er bij architectuur om dat je succesvol een constructie, operatie en decoratie in het bouwwerk voor elkaar krijgt die bepaalde kwaliteiten en prestaties levert. Dus bij alles wat je van de architectuur visualiseert moet je qua te realiseren functie en techniek kunnen onderbouwen; dat bepaalde kwaliteit en prestaties worden geleverd en hoe dat dan gebeurt, anders is het geen architectuurvisualisatie.

Een goede architectuurvisualisatie laat zien hoe noodzakelijke logische functies zijn vertaald in duurzame en toekomstvaste technische vormen. Het is die vertaalslag die maakt dat een architect geen knip-en-plak werk heeft gedaan van theorie uit literatuur en daarmee een architectuurdocument heeft gemaakt. Een vertaalslag maken van functie naar vorm en van logisch naar technisch, vraagt om het maken van ontwerpbeslissingen. En dat is het werk van de architect: het maken van een ontwerp.

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.

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.