Artikel

Dragon1 Visualisatietips - Effectief de architectuur zichtbaar en stuurbaar maken

Goed kunnen tekenen begint bij goed kunnen kijken. Daarom deze maand meer aandacht voor hoe je door anders te kijken andere zaken ziet en anders gaat tekenen. In deze visualisatietips belichten we hoe in een organisatie een architect, manager of ontwikkelaar dient te kijken naar concepten en principes en hoe hij deze gestructureerd op papier krijgt. Hierbij dient hij ook de vergelijking te maken tussen de theorie en praktijk van concepten en principes en bovenal concepten en principes visueel te kunnen relateren aan bedrijfsdoelstellingen.

Steeds meer architecten, managers en ontwikkelaars willen de architectuur van de organisatie in beeld brengen om deze dan bij te sturen ten faveure van het realiseren van de bedrijfsstrategie. Echter als je de producten, diensten, bedrijfsprocessen, applicaties en servers in beeld hebt gebracht en aan elkaar hebt gerelateerd, dan heb je nog niet de architectuur in beeld. Wat je wel in beeld hebt is de configuratie van de organisatie. Het mooier of beter maken van de configuratie maakt niet dat je je bezig houdt met de principes van de concepten die achter de samenwerkende configuratieitems zitten.

Dragon1 stelt dat als je de architectuur van een organisatie in beeld wilt brengen, je met name de toepassing van een geheel van concepten en hun principes in de organisatie dient te belichten. Bijvoorbeeld een concept als Zaakgericht Werken in combinatie met een concept als Cloud Computing. Bijvoorbeeld een Zaakgericht Werkenprincipe als ‘Geïnformeerde klanten leiden tot tevreden klanten’ in combinatie met een Cloud Computing principe als ‘Een flexible ICT-infrastructuur capaciteit zorgt voor meer concurrerend vermogen’.

Dit vereist allemaal wel dat je kennis van zaken hebt over de theorie van de concepten en hun principes: hoe werkt bijvoorbeeld Cloud Computing in zijn essentie en hoe steekt Zaakgericht Werken in elkaar zodat het voordelen biedt? Maar je dient ook te beschikken over de mogelijkheid (ability) en de kennis om de af/aanwezigheid van concepten en hun principes in de organisatie te zien en ook hoe ze conform de theorie wel of niet zijn toegepast en ingebed in de organisatie: Wij hebben van ons DMS een Zaakgericht-werken-systeem gemaakt, maar je wilt niet weten hoe! Een netwerk bij onze zusterorganisatie, dat is toch ook Cloud Computing?

Laten we ook niet vergeten dat elk concept en principe ook aan bedrijfsdoelstellingen of strategische intenties en uitgangspunten gekoppeld dient te worden, als legitimering van het investeren in een concept of principe. Deze kennis en kunde (ook over de financiële kant) van concepten en principes heeft een architect nodig om de echte architectuur van een organisatie in beeld te kunnen brengen.

In de praktijk hebben we vele samengestelde architectuurvisualisaties

In vele architectuurvisualisaties in de organisatie zien we dat fysieke, logische en conceptuele abstractieniveaus door elkaar heen zijn gevisualiseerd. Door deze visualisaties als het ware uit elkaar te trekken (netter gezegd: de abstractieniveaus gaat scheiden), krijg je met de conceptuele visualisaties de echte architectuur van de organisatie in beeld. Als je een architectuurvisualisatie uit elkaar gaat trekken ontstaan er vanzelfsprekend gaten: Op de plek waar een concept had moeten staan (zoals Customer Relationship Management of eCRM), staat een technisch product (Microsoft Dynamics CRM) , een technisch digitaal component (Open Source CRM Php -webaplicatie) of een logisch functioneel element (beheer, cross-selling en up-selling van zakelijke relaties).

Figuur 1: Voorbeeld van een gecombineerde visualisatie met concepten, elementen en componenten in GEMMA

Figuur 2: Voorbeeld van een gecombineerde visualisatie met concepten, elementen en componenten in NORA

Voorbeeld van het naar voren halen van de echte architectuur op een visualisatie

Neem een willekeurige architectuurvisualisatie, bijvoorbeeld een visualisatie van een referentie- architectuur zoals GEMMA, NORA, CORA of AORTA. Beschouw deze visualisatie als een entiteitenrelatievisualisatie (ERV). De entiteiten gaan we straks toekennen aan soorten entiteiten zoals concept, element, component, object of technisch product. Maar nu zijn het nog alleen entiteiten.

Maak van alle visuele items (die een weergave zijn van entiteiten) op de visualisatie een lijst en maak van deze visualisatie vier kopieën.

Op elke kopie gaan we de visualisatie vollediger en consistenter maken: een conceptenrelatievisualisatie (CRV) met alleen concepten, een elementenrelatievisualisatie (LRV) met alleen elementen, een componenten-en-objecten-visualisatie (ORV) met alleen componenten en objecten en een technische productenvisualisatie (TRV) met alleen producten.

Hanteer de volgende criteria om de kopievisualisaties op te schonen:

  • Heeft de entiteit een naam van een leverancier, dienst of product, dan is het waarschijnlijk een technisch product.
  • Heeft de entiteit een naam voor een technologische oplossing of technologie, maar wordt in het midden gelaten welk product of leverancier het betreft, dan is het waarschijnlijk een component.
  • Heeft de entiteit een naam voor een geheel aan gegevens, dan is het waarschijnlijk een object (dat wordt behandeld of gebruikt door een component).
  • Heeft de entiteit een naam die een functie van een systeem aanduidt, waarbij technologie (niet vandaag de dag) meer bekend is, en leverancier of product nog flink in het midden worden gelaten, dan is het waarschijnlijk een element.
  • Heeft de entiteit een naam die een aanpak, werkwijze, abstractie van een implementatie of een idee aanduidt, dan is het waarschijnlijk een concept.

Als je een entiteit op een kopievisualisatie kunt typeren, dan dien je deze entiteit op de andere kopievisualisatie weg te halen. Zo ontstaan er gaten op de visualisaties. Het is nu de bedoeling dat je de gaten op correcte wijze gaat invullen. Dus als op de componentenrelatievisualisatie er een component staat, dien je het achterliggende logische functionele element te benoemen, waarvan de component een implementatie is. Hetzelfde geldt voor de andere kopievisualisaties.

N.B. Een naam van een entiteit kan een concept zijn, maar tevens ook een gangbare naam voor een element, component, object of technisch product. Dit geldt bijvoorbeeld voor het woord ‘server’ en het woord ‘service’. De context (de soort entiteitenrelatievisualisatie) waarin de entiteit gebruikt wordt maakt dan duidelijk wat het is. Naast het visualiseren behoort het opstellen van een gemeenschappelijk begrippenkader ook tot de taken van de architect. In dit begrippenkader wordt dan ook duidelijk gemaakt of bepaalde woorden soms concept, element, component of product zijn.

Leveranciers van technische producten maken gebruik van concept- en componentnamen om hun product zo algemeen bruikbaar mogelijk te maken. Zo zijn er organisaties die hun product Enterprise Service Bus noemen of Cloud Computing 2.0. Architecten dienen zoveel mogelijk duidelijk te maken aan opdrachtgevers in de visualisaties wanneer men te maken heeft met een concept , component of product los van een leverancier of gekoppeld aan een leverancier.

Concepten en principes: theorie versus praktijk in beeld brengen

Nu op de kopievisualisaties de concepten zoals die in de organisatie zijn geïmplementeerd (in elkaar steken, werken en voordelen produceren) zichtbaar worden, is het ook zaak dat de architect in beeld brengt hoe de concepten conform de theorie in elkaar steken, werken en voordelen produceren.

Als de architectuurvisualisaties nog geen helder beeld geven van de concepten en principes die aanwezig zijn of zouden moeten komen in de organisatie, verdient het aanbeveling om naar trends en ontwikkelingen door de jaren heen in verschillende bedrijfsfuncties te kijken voor de branche van de organisatie. De bedrijfsfuncties inkoop, verkoop, productontwikkeling hebben de afgelopen jaren overal vernieuwingen doorgemaakt, waar de architect uit kan putten om op concepten en principes te komen.

In de organisatie werken mensen en (ICT)middelen op een bepaalde wijze samen. Er is een aanpak, er zit een idee achter. Al dit soort zaken zijn concepten. Het is de kunst en kunde van de architect om deze concepten en wijze van werken te achterhalen. Op de architectuurvisualisaties willen we uiteindelijk ook dat (samen)werken terug zien.

In literatuur (boeken, artikelen en kennissites) staan vaak beschrijvingen en visualisaties van concepten en hun principes maar dan zonder de context van een specifieke organisatie. Het verdient aanbeveling om voor de concepten en hun principes op de architectuurvisualisaties deze theoretische verhandelingen op te zoeken en in kaart te brengen. Je ziet zo bijvoorbeeld welke soorten en typen van Zaakgericht Werken en Cloud Computing er zijn. De wijze waarop concepten en hun principes in de organisatie aanwezig zijn en resultaat produceren, worden zo meer stuurbaar, verbeterbaar en ontwerpbaar gemaakt.

Voor je het weet heb je een verschil te pakken tussen de wijze waarop enerzijds een concept in theorie voordelen realiseert met een principe en hoe anderzijds het concept is toegepast in de organisatie en weinig voordelen realiseert. Met de twee verschillende tekeningen in de hand is een verschillenanalyse zo gemaakt en zijn verbetermaatregelen zo opgestart. Zonder de tekeningen is dat veel lastiger te communiceren en voor elkaar te krijgen.

Maak van elk concept op de architectuurvisualisatie aparte elementen, componenten en technische producten tekeningen. Je hebt al gauw tien concepten op een architectuurvisualisatie staan, dus het worden veel tekeningen, maar je krijgt er wel veel sturing en kwaliteit voor terug. Ook kun je met deze werkwijze alternatieve implementaties van concepten op verschillende abstractieniveaus duidelijk maken met verschillende voordelen. Na het maken van deze verschillende conceptverkenningen kun je de tekeningen weer samenvoegen tot de vier architectuurvisualisaties.

Let erop dat je op de visualisatie goed de (samen)werking van mensen en middelen laat zien. Want het is dit (samen)werken dat ervoor zorgt dat concepten resultaten produceren.

Werk ook in de branche samen met architecten van andere organisaties. Daar zijn vast ook verkenningen die je kunt hergebruiken of zij zijn anders zeer geïnteresseerd in jouw werk! En bovenal: verdeel het werk.

Ten slotte

Dragon1 is een methode die architecten, manager en ontwikkelaars ondersteunt in het formuleren en visualiseren van concepten en principes, om zo de echte architectuur van de organisatie in beeld te brengen en stuurbaar te maken. Dit levert veel voordelen op voor projecten en maakt innoveren effectiever. Wapens daarbij zijn het zichtbaar maken van de principes (de gehandhaafde werking) van concepten en het duidelijk scheiden van abstractieniveaus in visualisaties (soorten entiteiten netjes scheiden van elkaar).

Al met al heel wat visualisatietips om de echte architectuur van de organisatie in beeld te brengen en meer stuurbaar te maken! Veel succes.

Hoe kan het beter? - het vervolg op dit artikel komt in de volgende editie van XR Magazine

In de volgende edtie van XR Magazine verschijnt een vervolgartikel op dit artikel. De twee visualisaties van NORA en GEMMA die in dit artikel worden getoond, maar ook een praktijkvoorbeeld van een visualisatie bij een gemeente zullen door Mark Paauwe opnieuw worden behandeld en dan worden voorzien van voorbeeldvisualisaties die een meer correcte weergave geven van architectuur. Hierbij wordt dan gebruik gemaakt van de methode Dragon1 en met name het Dragon1-VEA-kernmodel

(zie http://wiki.dragon1.com/index.php?title=Visuele_Enterprise_Architectuurmodel).

In het vervolgartikel staat dan een uitgewerkt voorbeeld van een conceptschets, principetekening (met elementen), componentendiagram en productbeeld. In deze visualisaties zijn dan de verschillende abstractieniveaus consequent en consistent uit elkaar gehaald (per stuk gecompleteerd/volledig gemaakt) en communicatief afgestemd (als aanzicht of perspectief) op verschillende doelgroepen (zodat hun informatie/beslissingsbehoefte optimaal wordt ondersteund).

Heeft u vragen aan Mark Paauwe naar aanleiding van dit artikel of over het maken van correcte weergave van architectuur in visualisaties? Stel deze vragen dan door hem te mailen via mark.paauwe@dragon1.com. Uw vragen worden dan door hem, indien mogelijk, meegenomen in vervolgartikelen op XR Magazine en anders beantwoord op deze website.

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.