Ja, de site mag op basis van mijn klikgedrag suggesties doen en voorkeuren onthouden. Meer over cookies.
Opslaan

Van artiest naar ingenieur!?

  • Johan Heuvelman
  • 11 mei 2016
Johan

Architecten zien zichzelf doorgaans als de hoeders van de Enterprise Architectuur en formuleren daarvoor mooie en scherpe principes en standaarden waar iedereen zich aan moet houden. Maar doen die architecten dat zelf op een begrijpelijke en gestandaardiseerde manier? Helaas blijkt in de praktijk dat architecten zich nogal eens wat artistieke vrijheden veroorloven, die ten koste gaan van de helderheid en eenduidigheid van de boodschap. Diagrammen zonder legenda, netvlies pijnigend kleurgebruik, ad hoc methodes en niet transparante besluiten zijn helaas schering en inslag. Soms wordt dit zelfs gecombineerd met te laat leveren en frustratie dat de afnemer (stakeholder) de boodschap niet begrijpt. Het kan en moet beter. Hier een praktische voorzet.

Dit vraagstuk is niet nieuw. Als we kijken naar de bouwwereld, dan zijn er raakvlakken en met een paar honderd jaar ervaring is dit een mooie bron van inspiratie. Onze collega architecten uit de bouw zijn een stuk beter instaat dit vraagstuk op te lossen. Bouwtekeningen [1] worden al jaar en dag op een eenduidige manier gecreëerd en gebruikt. Dit is niet voor niets: de bouwwereld heeft net als Enterprise architectuur te maken met diverse stakeholders die allen een goed beeld moeten krijgen van de gewenste oplossing. Of het nu gaat om de projectontwikkelaar, de binnenhuisarchitect, de loodgieter enz. ze moeten allen een specifieke bijdrage leveren aan het totaal plaatje. Om het plaatje compleet te krijgen moeten de verschillende werkzaamheden exact op elkaar aansluiten. Zo dient bijvoorbeeld een zwarte lijn in een bouwtekening eenduidig te kunnen worden geïnterpreteerd. De loodgieter moet op basis van de tekening kunnen zien dat een zwarte lijn een afvoerleiding is en geen muur. Dit geldt eveneens voor de metselaar en alle andere specialisten.

[1] Voorbeeld van een Bouwtekening

Bouwtekeningen zijn over de jaren heen goed gestandaardiseerd. Als we kijken naar IT landschapsschetsen, dan zijn deze overzichten een stuk minder volwassen. Even googelen op de term ‘IT landscape’ en je vind talloze hits met dit soort afbeeldingen [2]:

[2] Voorbeeld IT landschap schets

Het gebrek aan volwassenheid van dit soort landschapsschetsen zal ik duidelijk maken aan de hand van een drietal fragmenten uit deze afbeelding [2]. Het eerste fragment heeft betrekking op de linkerzijde van de plaat [3]. Aan de linkerzijde van de afbeelding [3] staan een aantal devices getekend die verbonden zijn met een viertal wolken. De techneuten onder ons zullen begrijpen dat een device gekoppeld dient te zijn aan een netwerk, bijvoorbeeld intranet, om enige content of functionaliteit te kunnen tonen (native functionaliteit buiten beschouwing gelaten). Dit mechanisme is wat lastig te tekenen, dus met een wolk zal het voor een techneut wellicht voldoende duidelijk zijn. Echter als je heel letterlijk naar de afbeelding kijkt, dan kan je de lijn tussen de mobiele telefoon en de wolk zien als een fysiek verbindingslijn. Hierbij kan de vraag gesteld worden waarom er een draad aan een mobiele telefoon zit. De vaste telefoon zit immers ook met een vergelijkbare lijn vast aan een wolk. Ten tweede wordt uit deze afbeelding ook niet duidelijk wat de verschillende kleuren van de wolken betekenen. Voor niet-technische stakeholders is het totaal niet duidelijk wat het verschil tussen een rood-blauwe een oranje-blauwe, een donderwolk en een witblauwe wolk is. Goed nieuws is het vast niet.

[3] Verbinding tussen devices en netwerken

Het tweede fragment wat opvallend is aan deze is plaat is het gebruik van kleuren [4]. Zo is er in het midden een grote roze/rode cirkel te zien die overlappend is met een gele kolom. Vervolgens wordt de gele kolom weer onderbroken door een paar groene blokken. Zonder legenda of enige uitleg zal het de toeschouwer niet duidelijk worden wat hier de achterliggende gedachte bij is.

[4] Gebruik van kleurvlakken

Tot slot heeft het 3e fragment betrekking op het gebruik van verschillende pijlen en verbindingen tussen componenten. Zo is er rechts bovenin [5] een grote geel/oranje pijl te zien van een soort desktop achtig device richting de grootste server component in dit stukje IT landschap. Ook hier ontbreekt een toelichting op de pijl, dus wat de exacte betekenis is blijft gissen.

[5] Gebruik van pijlen

Bij Deloitte vinden we het erg belangrijk dat Enterprise architectuur goed wordt begrepen. Daarom hebben we als Deloitte een bibliotheek aangelegd van gestandaardiseerde en bewezen templates om architectuur te beschrijven (artefacten). Deze set voorkomt niet alleen flink wat misverstanden, deze set verhoogt ook de productiviteit van de architecten. Deze combinatie van grotere begrijpelijkheid en sneller leveren verhoogt vervolgens de waardering van de architecten en business stakeholders.

De ervaring die wij hebben opgedaan bij onze klanten is dat zij deze insteek waarderen en door deze aanpak meer rendement weten te behalen uit de Enterprise architectuur practice.

Om hier een vervolg aan te geven; de bouw biedt ook inspiratie voor constructie standaardisatie. Vaak zo succesvol dat we ons zelf hier niet van bewust zijn. De warmwaterknop van een kraan zit te allen tijde op dezelfde positie en heeft een eenduidige draairichting. In een volgende blog vanuit de Deloitte EA practice zal worden ingegaan op de manier waarop Enterprise Architectuur hiervan kan leren. 

Johan Heuvelman

Enterprise Architecture

Na 4,5 jaar bij een system integrator te hebben gewerkt met een focus op zaakgericht werken, werkt Johan inmiddels als consultant in de service line Enterprise Architecture (EA) wat deel uit maakt van Deloitte Technology Consulting. Momenteel adviseert Johan clients over hoe men bedrijfsprocessen, informatie, applicatie en integratie technologie op elkaar kan afstemmen.

Workshop Personal Impact - een leerzame ochtend

  • Dominique Rieken
  • 03 mei 2016
Naar boven