Artikel

Dragon1 Visualisatietips voor PowerPoint

PowerPoint wordt nog steeds door veel architecten gebruikt als architectuurtool. Daarom presenteren we een aantal praktische tips om met meer gemak betere visualisaties te maken.

Tip 1 - Maak gebruik van dezelfde symbolen voor dezelfde soorten elementen en componenten

In een functionele analyse- of ontwerpvisualisatie komt het voor de kijker veel rustiger over als je voor dezelfde elementen en componenten dezelfde symbolen gebruikt. Zie onderstaande voorbeeldvisualisatie.

Figuur 1

In deze visualisatie wordt het echter niet duidelijk of er een vraagstuk dan wel een probleem is (analyse) en of dat het vraagstuk ergens mee wordt opgelost (ontwerp).

Tip 2 - Werken met de haallijn en functie en vorm apart aanduiden

Bij het visualiseren van een technische analyse- of ontwerpvisualisatie kun je ervoor kiezen om de teksten die aanduiden wat de elementen en componenten voorstellen op een tekening, in de elementen of componenten zelf te plaatsen. Door dit te doen, zorg je ervoor dat de kijker meer verschil kan maken tussen wat een onderdeel is, wat een onderdeel doet of waar een onderdeel uit bestaat. In onderstaand figuur wordt de functie van de componenten en hun technisch vorm duidelijk.

Figuur 2

Relaties zijn een (functioneel) element. Met een (technisch) database component wordt invulling gegeven aan het element 'relaties'. In deze visualisatie wordt globaal duidelijk gemaakt welke 'vraagstukken' er zijn, maar het wordt nog niet duidelijk of iets problematisch is. Bijvoorbeeld: Hoeveel mutaties zijn er jaarlijks op de relaties en is de soort database oplossing hier afdoende voor? De oplossingsrichtingen in deze visualisatie zijn zo algemeen dat het op dit niveau altijd goed is.

Tip 3 - De soort functie en de soort vorm expliciet aanduiden

Bij het maken van een architectuurvisualisatie is het nodig om de specifieke soort of technisch vorm van een oplossing (de componenten) te voorzien van hun functionele betekenis (de elementen). We willen weten welke 'ingenieuze' oplossing de architecten in het verleden of voor de toekomst hebben bedacht voor een bepaald vraagstuk met tegenstrijdige eisen. Maar het kan ook zijn dat we met een architectuurvisualisatie juist bloot leggen dat de gekozen oplossing ondeugdelijk is voor bepaalde situaties.

De symbolen die we voor de componenten in de visualisatie gebruiken moeten eigenlijk aangeven wat de soort is. In onderstaand figuur staan nu processen, applicaties en databases, maar de symbolen zijn nu zo gekozen dat we duidelijk laten zien welke processen geautomatiseerde processen, handmatige processen of semigeautomatiseerde processen zijn.

Figuur 3

We laten in de onderste laag van de visualisatie zien dat we een relationele database hebben die wel of niet ANSI-2 SQL compliant is. We laten zien dat we een excellijst hebben.

In de middelste laag van de visualisatie laten we zien dat we met een monolithische applicatie te maken hebben, met een 3-lagen applicatie en een RIA (een rich internet application).

Door op deze wijze aan te geven hoeveel verschillende soorten van (technische) componenten we hebben, wordt de complexiteit ook echt duidelijk gemaakt. In figuur 1 en figuur 2 komt dat absoluut niet aan de orde. De toekomstvastheid en duurzaamheid van de geschetste oplossing dus ook niet. Verschillende soorten elementen en componenten vragen namelijk ook verschillende kennis, ervaring en kunde. En dat kost dus meer geld bij ontwikkeling, gebruik en beheer. Dus door een goede architectuurvisualisatie te maken wordt gelijk duidelijk hoe complex en moeilijk beheer(s)baar de situatie is.

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.