Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Architectuurprincipes moet je visualiseren

 

Computable Expert

Mark Paauwe
Chief Technology Office, Dragon1 Inc.. Expert van Computable voor het topic Infrastructuur.

Wil je fundamentele strategische veranderingen succesvol doorvoeren in een organisatie, dan is het van groot belang om letterlijk in beeld te hebben welke systematieken en mechanismen in de business (met andere woorden de business architectuurprincipes) van de organisatie de dragende muren vormen die soms moeilijk te verplaatsen zijn.

Huidige business architectuurprincipes van de organisatie vormen de dragende muren bij strategische veranderingen in de organisatie.  En dragende muren vormen altijd weerstand bij verandering.

Een voorbeeld van een bedrijfskundig concept dat we allemaal kennen is het concept van verkoper-gebaseerde verkoop. In dat businessconcept is er altijd wel een interne resource (verkoopmedewerker) die een rol speelt in het verkoopproces aan de klant  (of het inkoopproces bij de klant). En die persoon, omdat het een mens is, beperkt altijd, hoe je het ook wendt of keert het maximum aantal mogelijke verkooptransacties per tijdseenheid. Stel nu dat er geen enkele verkoop in de hele organisatie tot stand kan komen zonder dat er een verkoopmedewerker bij betrokken is, dan is het niet alleen maar een business conceptprincipe, maar dan kan dat effectieve werkingmechanisme in de organisatie met recht een huidig geldend en effectief business architectuurprincipe worden genoemd.

Maar dan nu: stel dat de organisatie met een selfservice webshop aan de gang wil gaan: zeg maar geld en tijd uitsparen of winnen, door de tussenkomst van de verkoopmedewerkers uit te schakelen. Dat is ten opzichte van de huidige praktijk in de organisatie een gigantische verandering. Maar ook een prachtig vooruitzicht: geen beperkingen meer op het maximaal aantal verkooptransacties per tijdseenheid.

Maak principes visueel

Als je nu succesvol een dergelijke verandering wil doorvoeren naar selfservice waarbij de organisatie ook echt een veel hoger transactievolume realiseert en aan kan en dus echt rendement gaat zien van het nieuwe concept, dan is het uiterst slim om een overzicht, gevisualiseerd met posters, te hebben van de business architectuurprincipes. Bijvoorbeeld; wat houden de twee verschillende businessconcepten en businessconcept-principes visueel in en hoe werken ze? En wat is de impact van het toepassen van de nieuwe concepten op de organisatie: waar in welke producten, diensten, processen, contracten, afdelingen gaat het pijn doen? Zonder visualisaties, en alleen maar met tekstdocumenten, is het heel lastig om gecontroleerd en beheerst met succesgarantie binnen tijd en budget het nieuwe concept selfservice voor elkaar te krijgen.


Ongeacht branche of bedrijfsgrootte, managers in organisaties geven nog altijd aan dat het moeilijk is om veranderingen onder controle te krijgen en te houden. Het gaat daarbij om veel geld en een tijdige inzet van de benodigde resources. Het vraagstuk van vandaag is: Waarom zou een directeur nu wel of geen geld in bepaalde projecten moeten blijven pompen? En het gaat hierbij niet alleen om ict-projecten, maar ook om innovatieprojecten (zoals nieuwe medicijnen), beveiligingsprojecten (zoals cybercriminaliteit), of financieel-economische projecten (wel of niet banken nationaliseren door de overheid).

Ambities van ondernemingen

Projecten en met name veranderprojecten worden vaak gestart om de ambities van een onderneming te kunnen verwezenlijken. Wil de onderneming als dienstverlenend in de markt bekend staan, dan is ‘de Klant is Koning' een veel voorkomend geformuleerd business architectuurprincipe dat in menig jaarverslag te vinden is of bij de missie staat op de corporate website. Maar hoe zorg je ervoor nu als bestuurder of general manager dat je dit ook kan waarmaken naar de klanten?

Business architecten zijn de aangewezen personen binnen organisaties die als taak hebben om business architectuurprincipes zodanig te formuleren dat ze ook gaan werken voor de organisatie. Een te nemen stap hierbij is om businessconcept-principes (de wijze waarop bedrijfskundige concepten werken en resultaten produceren te visualiseren, zodat zichtbaar wordt wat de werkingsmechanismen zijn die in de organisatie ingericht dienen te worden om de principes ook te kunnen laten werken.

Maar wie zijn dan de echte business architecten in de organisatie die dit kunnen doen? Misschien wel de beleidsmakers en beslissers. Zij hebben immers het overzicht van het geheel en weten in grote lijnen hoe alle samenhangt en van elkaar afhankelijk is.

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4686919). © Jaarbeurs IT Media.

?


Lees meer over


 

Reacties

Ik denk dat je je verhaal ook beter kunt visualiseren. Mensen hebben verschillende percepties bij deze term.
Bedoel je plaatjes met structuren en pijltjes? Of een animatie waarin de stappen tijdvolordelijk worden weergegeven? Of een voorbeeldfilm?

Belangrijk is dat degenen die iets moeten uitleggen aan anderen díe hulpmiddelen gebruiken en díe vorm toepassen die aanslaat bij de doelgroep. Voor de één is dat een finaciële onderbouwing (rapport), voor de ander is het werken met b.v. maquettes. Voor een IT-er vaak PowerPoint-slides....

Leen,
Je hebt helemaal gelijk. Ik ga op korte termijn een visualisatie bij dit verhaal maken en hier plaatsen. En dan ben ik benieuwd naar je reactie!

En ik zou je willen aanvullen dat je ook vooral altijd het principe (de werking en het geprouceerde resultaat) van hetgeen dat je wil uitleggen goed in beeld moet brengen. Want als iemand begrijpt hoe iets werkt, dan ...

Wat bedoel ik met visualisaties?

Met visualisaties bedoel ik: 'een visuele weergave' . In de open methode Dragon1 die ik heb ontwikkeld (www.dragon1.org) onderken ik vier hoofdsoorten visualisaties: schetsen, tekeningen, diagrammen en fotografische beelden.

Schetsen (informele visualisaties) van totaalconcepten, situaties en dynamiek lenen zich uitermate goed voor beslissers en beleidsmakers.

Tekeningen (informele visualisaties) van concepten en principes lenen zich uitermate goed voor gebruik door architecten, beleidsmedewerkers en managers.

Diagrammen (formele visualisaties) van systemen, structuren etc.. lelen zich uitermate goed voor gebruik door engineers/ techneuten/ analisten/ ontwerpers.

Fotografische beelden (informele visualisaties) van te realiseren oplossingen lenen zich het beste voor gebruik door belanghebbenden en gebruikers (klanten en medewerkers).

Voeg je een tijds-as toe aan schetsen, tekeningen, diagrammen en beelden, dan worden het de filmpjes zoals je dat noemt.

Hieronder heb ik een aantal links naar voorbeelden van soorten schetsen, tekeningen, diagrammen en beelden uit de Dragon1 aanpak om principes te visualiseren:

Ontwerpschets van een totaalconcept voor een Verzekeraar: http://wiki.dragon1.org/images/thumb/Ontwerpschets.jpg/600px-Ontwerpschets.jpg

Ontwerpschets van een digitale gemeente:
http://wiki.dragon1.org/images/thumb/Dragon1-voorbeeld-ontwerpschets-gemeente-veluweloo.png/600px-Dragon1-voorbeeld-ontwerpschets-gemeente-veluweloo.png

Archigraphic Bibliotheek: http://www.hanvanroosmalen.nl/sites/default/files/images/Kentallenkaart%20BNL.preview.png

Structuurvisie: http://www.dragon1.com/images/dragon1-voorbeeld-eisen-ict.png

Applicatielandschapsposter: http://www.dragon1.com/images/dragon1-applicatie-landschap-1.jpg

Enterprise Architectuur Blauwdruk: http://wiki.dragon1.org/images/Dragon1-enterprise-architecture-blueprint-my-bank.gif

ICT-Architectuur blauwdruk: http://www.xr-magazine.nl/afbeeldingen/dragon1-ict-landschap

Artist Impression eDienstverlening: http://www.dragon1.com/images/ai-gem-large.png

Volgens mij bedoeld Mark, koop een boek over UML.
Unified Modeling Language ;D

Jurgen,

Bijna... Ik zeg: verdiep jezelf in de open methode Dragon1 om vraagstukken en oplossingen beslisbaar te visualiseren.

Mark,

Principes visualiseren lijkt me vooral een 'Donald Duck' verhaaltje op te leveren omdat je principes in de eerste plaats na moet leven, de overdracht hiervan is uiteindelijk alleen maar het communicatiemiddel en niet het doel zelf. Principes zijn tenslotte ook nogal abstract, net als veel van de architectuurtekeningen maar dat terzijde.

Daarmee wil ik niet ontkennen dat een plaatje meer zegt dan 1000 woorden, iets dat tegenwoordig inderdaad niet zo gauw meer gelezen zal worden, maar blijft het op die manier nog wel te statisch. Of zoals Godfried Bomans al eens zei: "Een statisticus waadde vol vertrouwen door een rivier die gemiddeld één meter diep was. Hij verdronk."

Je hele verhaal doet me denken aan de slogan van de belastingdienst, beter kunnen we het niet maken maar wel mooier omdat je visualisatie meer weg hebben van marketing dan een (management) oplossing. Leuk om met een INFOGRAPIC beleidsmakers zoals de burgermeester van Haren de werking van sociale media uit te leggen maar niet SMART om dat pas achteraf te doen.

Veel architectuur tekeningen zijn namelijk toch als een sticker die je over je dashboard heen plakt waardoor snelheid is, aantal toeren en hoeveelheid brandstof onbekend blijven. Want weten is namelijk afhankelijk van meten en niet de afdruk van een indruk waardoor er nog te vaak verkeerde beslissingen genomen worden.

Een les die trouwens uit BPM te trekken valt is dat de bedrijfsvoering eerder verstoord dan ondersteund wordt als de abstractie tussen papier en praktijk te groot wordt. De zin:"In principe hebben we of in principe zijn we ...." hoor ik dan ook vaak omdat afspraken misschien in steen gebeiteld zijn maar de mensen zelf nog altijd niet van steen zijn.

Ervaring leert dat bij het inzichtelijk maken van processen er namelijk ook nog weleens om de RUMBA principes heen gedanst wordt, mensen houden namelijk niet zo van 'measurable behavior' waardoor op papier alles mooier lijkt dan het in werkelijkheid is. Afspraken maken en deze uiteindelijk na komen zijn ook twee compleet verschillende dingen waardoor je visualisatie misschien wel kunt gebruiken voor processturing maar ze me ongeschikt lijken voor de projectsturing.

Ewout,

ik gebruik allerlei manieren om zaken/systemen te visualiseren. Systemen waar ik aan werk zijn veelal te complex om de cursor links bovenin te zetten en te gaan typen en dan te verwachten als je drie schermpjes heb vol getikt dat het dan werkt. Vroeger ging dat zo.

Op technisch niveau (dus met de mensen die het "echte" werk doen) gebruik ik UML of misschien Archimate diagrammen om te bepalen hoe iets in elkaar gezet wordt. Deze diagrammen gebruiken om op C-level beslissingen te nemen blijkt niet te werken. De meeste directeuren/managers zijn na drie pijlen de weg al kwijt en zijn dan niet geïnteresseerd om het beter te willen gaan begrijpen. Het meeste succes heb ik met simpele schetsen om daarmee te bepalen welke kant het op zou moeten gaan. Praten over principes, in de trant van, in de wereld van ... gaat het zo, wat zou je er van denken om het ook zo te doen.

Op basis van de simpele schetsen werk ik dan naar een verdieping toe en kom dan vanzelf uit bij UML diagrammen e.d. Ik heb ook gemerkt dat dit traject van abstracte visualisaties (bijvoorbeeld conform de ideeën van Dragon1) naar technische designs (UML/ERD) sneller en effectiever werkt dan rond malen in een design methode en daarmee iets proberen te maken dat niet afgestemd is met een CEO-er (slecht voor je budgettering).

Het verbaast mij nog steeds dat er weinig (software/enterprise) architecten zijn die zonder een architectuuropdracht werken die gegeven is door een C-level manager. Of die met dingen bezig zijn waarvan je je afvraagd of dat wel een duidelijke bijdrage heeft.

Als jij jouw droomhuis wil laten bouwen dan wil je toch ook dat de architect eerst met voorlopige ontwerpen komt voordat je een definitief design laat maken. Je zult eerst een praatplaat moeten (laten) maken voordat je elkaar begrijpt en de diepte in gaat (of mee wilt de diepte in).

Ik heb ook gemerkt dat het werken op basis van (bestaande) principes erg behulpzaam is. Principes zijn veelal niet gekoppeld aan één domein. Principes zijn voldoende abstract om begrijpbaar te zijn, en op basis hiervan te beslissen of het past (OF JUIST NIET) binnen het ontwerp. Principes bevatten ook voldoende diepgang en regels die nagestreefd moeten worden om ervoor te zorgen dat ze gaan werken. Dat is helder en geeft richting.

Goede platen geven richting en zijn instaat om dingen te veranderen, immers er zijn foto's die zoveel impact hadden dat oorlogen werden gestopt. Waarom zou een architectuurplaat dan zoiets niet kunnen voor een bedrijf?

Han,

Zoals ik je reactie lees gebruik je meerdere middelen/manieren om dingen uit te leggen, iets verduidelijken is echter nog niet gelijk aan sturen. De 'artist impressions' zijn tenslotte zoals je zelf al zegt vooral praatplaten en niet bedoeld voor sturing. En om in je vergelijking met de bouw te blijven, de regenwaterafvoer moet dus wel goed zijn om te voorkomen dat het dak bezwijkt. Een gemis is dus de aansluiting op de techniek, de doorberekening van de constructie waardoor Enterprise Architectuur vaak niet meer dan een 'papieren tijger' is.

Een proces dat misschien wel een richting geeft maar ongeschikt is om mee op koers te blijven omdat beleidsmakers niet meer met hun voeten in de modder staan waardoor sturing dus nog weleens een reus op lemen voeten is. Dit misschien juist wel omdat de 'aap-noot-mies' visualisaties niet bedoeld zijn om te leren lezen of rekenen, niet meer noodzaken om de diepte in te gaan. En juist als dingen te abstract worden gaan ze uit de pas lopen met de werkelijkheid zoals we regelmatig in de krant kunnen lezen.

Want om even terug te komen op mijn eerste reactie: "In principe werken we onder architectuur..." is een contradictio in terminis, een tegenspraak in termen die ik dus nog weleens tegenkom. En dat niet alleen voor de 'ist' waar de afwijkingen misschien voortkomen uit historie maar ook zeer regelmatig in aanbestedingen, de 'soll' die dan ook niet zelden over budget heen gaat bij de uitvoer. Conclusies van auteur lijken me daarom dus in elk geval onvolledig en misschien zelfs wel compleet onjuist.

Oja, en principes zijn ook nog weleens zelfgekozen regels die bepalen hoe dingen en anderen moeten werken maar zelf niet nageleefd worden. Want foto's kunnen tenslotte ook conflicten beginnen omdat SIGINT niet altijd het hele verhaal vertelt zoals we kunnen leren van conflicten waarbij de HUMINT achteraf een ander verhaal onthult. Zeker als blijkt dat de foto's achteraf geretoucheerd zijn, vanuit een strategisch gekozen (stand)punt genomen zijn of gewoon achteraf verdwenen.

Ewout,

Ik denk dat jouw kijk op principes en het wel of geen nut hebben van architectuurvisualisaties door 99% van alle architecten en managers op dit moment ook zo ervaren wordt.

Wat wij volgens mij allemaal niet door hebben is dat wij in het bedrijfsleven met het managen van projecten en het bouwen van systemen totaal achterlopen op de vakgebieden om ons heen.

Ik kan me dus heel goed voorstellen met wat jij nu zegt. Maar het correct visualiseren van architectuurprincipes levert niet altijd of alleen maar eenvoudige plaatjes op.
Het correct visualiseren van echte architectuurprincipes levert vooral altijd inzicht, overzicht, draagvlak, tijd, geld en kwaliteit op.

Denk maar aan het bouwen en ontwerpen van vliegvelden, steden, het bouwen van de hoogste toren van de wereld, het bouwen van een nieuwe Chipmachine en de automotor op elektriciteit.
Zie: http://www.qatarembassy.net/major_projects.asp
Zie: http://en.wikipedia.org/wiki/List_of_tallest_buildings_and_structures_in_the_world
Zie: http://www.patrikschumacher.com/Texts/skyscrapers.htm
Zie: http://www.hhc.rca.ac.uk/resources/publications/CaseStudies/id4222.pdf
Zie Intel EUV: http://www.reram-forum.com/2012/11/09/the-euv-source-and-shot-noise/
Zie: http://auto.howstuffworks.com/electric-car2.htm
Zie: http://www.pinelandsalliance.org/downloads/pinelandsalliance_84.pdf

In alle megastructure-projecten worden normaliter principes globaal en gedetailleerd gevisualiseerd om het ontwerp en de realisatie van de oplossingen te verbeteren. Daar gaan zij namelijk uit van de oorspronkelijke betekenis van principe: dat je het werkingsmechanisme beschrijft van iets en dit visualiseert in een tekening, waardoor het systeem dat je bouwt ook gaat werken en renderen. Zie: http://en.wikipedia.org/wiki/The_Way_Things_Work

Wat wij met z’n allen in de bedrijfs- en informatiekunde nog niet doen, is op basis van de werking van het concept (het conceptprincipe), een tekening / visualisatie maken zodat je ook ziet hoe je het werkingsmechanisme aan de gang krijgt. Met andere woorden wat moet je wel en niet doen binnen je onderneming om de werking aan de gang te krijgen. In de open enterprise architectuur methode Dragon1 is dit ingebed als aanpak voor principes en architectuurprincipes.

Laat ik het uitleggen met een voorbeeld:

De volgende zin is GEEN principe: ‘Gegevens worden in onze organisatie altijd op 1 plaats opgeslagen’. Het is wel een uitgangspunt, kernwaarde, eis, beleidslijn of regel. Het grote punt is: de formulering van het principe in deze zin maakt het ‘eerlijk zijn’ op bepaalde momenten optioneel, ook al staat er ‘altijd’ en het wordt niet duidelijk wat het resultaat is van dit opslaan! Er wordt in deze zin niet aannemelijk gemaakt dat het ‘altijd’ op een bepaalde wijze continu wordt gehandhaafd en waarom je dat 'altijd' zou moeten doen.

De volgende zin is WEL een principe: ‘Door gegevens altijd op 1 plaats op te slaan, gehandhaafd vanuit automatisch toezicht, controle en opschoning, wordt ervoor gezorgd dat een gegeven niet inconsistent kan voorkomen in de organisatie, waardoor de kwaliteit en verwerkingsnelheid van gegevens in de organisatie hoog is.’

Deze zin laat zien dat het niet optioneel is en deze zin laat precies (hier nog globaal) zien wat je moet doen in de organisatie om er voor te zorgen dat het principe zo gaat werken (het voorkomen van inconsistente gegevens). In de praktijk leidt dit tot meer effectiviteit van architectuurprincipes. Dit is in Dragon1 het SMART-maken van een principe. En een SMART-principe is altijd effectief te visualiseren.

Een echt principe is dus een soort werkingmechanisme waar iets of iemand niet (zomaar) onderuit komt. Een echt principe is veel zwaarder dan een stoere richtinggevende uitspraak. Een echt principe is ook niet iets dat even op papier verzonnen is, maar juist bijvoorbeeld in gedegen literatuur staat uitgewerkt.

Zonder een fietsketting is een gewone fiets veel minder effectief in gebruik. Een principetekening van een concept (globaal abstract of technisch gedetailleerd) kan in een project gelijk het beeld opleveren, dat terwijl iedereen druk bezig is, iedereen wel de ketting is vergeten. Vervang Fiets door "Het nieuwe Werken", Self Service, Managed Services, Cloud Computing, Procesmatig Werken, Compliancy, Merger, Big Data, Integraal Klantbeeld of één van de andere honderdduizend bedrijfskundige en informatiekundige concepten en je hebt het lek boven water in een project.

In mijn promotieonderzoek en in de methode Dragon1 ben ik tot het inzicht gekomen dat ‘een architectuurprincipe is de gehandhaafde wijze waarop een concept werkt binnen een bouwwerk met een bepaald geproduceerd resultaat tot gevolg'. Dit is dus een nieuwe definitie voor het woord 'Architectuurprincipe' die veel afstand heeft tot de gangbare definitie van architectuurprincipe in het Enterprise Architectuur vakgebied, maar architectuurprincipes wel veel bruikbaarder maakt voor iedereen.

Er is al Archimate die inmiddels een breed geaccepteerde standaard is wereldwijd dus tenzij Dragon1 iets belangijks kan leveren dat bij Archimate ontbreekt zie ik niet wat de nut ervan is.

Roger,

Ik zal van de Open EA Methode Dragon1 op het gebied van architectuurvisualisatie een paar verschillen noemen:

Dragon1 heeft 150+ gestandaardiseerde generieke symbolen en een gestandaardiseerde aanpak voor het maken van schetsen, tekeningen, diagrammen en fotografische beelden afgestemd op belanghebbenden van oa bouwwerken, systemen, domeinen, concepten, fenomenen, principes en situaties.

Dragon1 maakt onder andere verschil tussen en heeft symbolen voor: strategic starting point, need, concern, issue, decision, performance-requirement, quality-requirement, ability, capability, function, event, trigger, service, service level, capacity, element, component, object, target, goal, objective, action, task, activity, process, role, responsibility, situation, assumption, request, cost, indicator, time, budget, plan, program, project, assignment, resource, channel, segment, proposition, experience, etc...

Dragon1 maakt verschil tussen metamodellen, modellen, aanzichten (views), perspectieven, gezichtspunten (viewpoints), kijkers (viewers) en visualisaties.

Dragon1 definieert andere lijnstijlen voor entiteiten uit het verleden, heden en toekomst.

In Dragon1 is architectuur gedefinieerd als het samenhangend geheel van concepten (een totaalconcept van een bouwwerk.

Een bouwwerk is een systeem met een constructieve, operatieve en decoratieve dimensie.

Een conceptprincipe is gedefinieerd als de gehandhaafde wijze waarop een concept werkt met een bepaald geproduceerd resultaat tot gevolg.

Met Dragon1 kun je met dit alles als een architect krachtig de principes (werking+geproduceerd resultaat) van concepten ontwerpen, visualiseren, communiceren en realiseren. Formeel met diagrammen en informeel met schetsen, tekeningen en fotografische beelden.

Met Dragon1 kun je visualisaties maken van architectuur die door bestuur, directie en management begrepen worden en gebruikt worden ondersteunend aan het nemen van strategische beslissingen.

Mark,
Bedankt voor het uitleg maar wat mij betreft onderschrijft dit alleen maar mijn standpunt.
Jij meldt dat Dragon1 "150+ gestandaardiseerde generieke symbolen" heeft. En dan meld je dat je kan "visualisaties maken van architectuur die door bestuur, directie en management begrepen worden".
Als je daar niet de 'contradictio in terminis' kan inzien dan weet ik niet hoe het je moet uitleggen.

Mark,

Ik blijf - eigenwijs als ik ben - met je oneens dat je de principes zelf kunt visualiseren. Je kunt ze misschien beter specificeren of documenteren maar uiteindelijk is niet alles in plaatjes te vangen. Je hebt net als bij Donald Duck uiteindelijk toch weer tekstballonnetjes nodig om gedachten over te brengen. Om gedachten te vangen zijn trouwens vaak weer andere tools nodig, zoals bijvoorbeeld mindmaps. Een aardige en leuke mindmap is die van Zapthink en vergeet dus niet mijn bijdrage op je eigen site: http://www.xr-magazine.nl/blogs/1418/architectuurraamwerken/loopt-enterprise-architectuur-straks-op-de-rotsen

Daarnaast vind ik dat je wel veel reclame maakt voor je eigen product waardoor je enigszins aan 'beroepsdeformatie' gaat lijden, teveel vanuit een eenzijdige focus kijkt. En mijn ervaring is dat er nog dus weleens een discrepantie kan zitten tussen wat er op papier staat en hoe het werkelijk gaat. Bijvoorbeeld met je voorbeeld om gegevens centraal op te slaan als ik kijk naar de werkelijkheid van configuratie management. Beleidsregels opstellen is dus één en ze naleven twee, een uitdaging die door EA nog teveel aan het implementatieniveau overgelaten wordt.

Ewout,

Ik wil wel even protesteren. Je reactie raakt in mijn ogen kant nog wal. Ik maak geen reclame voor een product. Dragon1 is een open architectuurmethode onder gebracht bij een stichting. Dragon1 is net zoals TOGAF of DYA een methode, maar dan ook open! (zie www.dragon1.org).

Ten tweede: Als je principes definieert zoals in de open architectuurmethode Dragon1 is gedaan, kun je ze altijd visualiseren en heeft het ook altijd zin. Ik snap werkelijk waar niet hoe je dat kunt ontkennen.

Ik stel voor dat je nog eens goed naar definitie kijkt van principe die ik geef en open staat voor een nieuwe visie. Beleidsregels zijn ook bijvoorbeeld iets compleet anders dan principes zoals ik uitleg hierboven.

Ewout, met alle respect, maar je moet wel de tijd nemen om een tekst te lezen.

Roger,

Naast de 150+ formele symbolen (als draadmodel en schets symbool) voegt de open methode Dragon1 onder andere een gestructureerde aanpak toe voor het maken van 1) schetsen, zoals ontwerpschetsen van totaalconcepten en omgevingen, 2)tekeningen zoals structuurvisies, blauwdrukken, situatietekeningen en principetekeningen en 4) beelden zoals archigraphics, persona's en artist impressions.

Deze hoofdsoorten visualisaties (schetsen, tekeningen, fotografische beelden) zijn voor bestuur, directie en management beter begrijpelijke visualisaties dan alleen maar de formele diagram-visualisaties zoals je die waarschijnlijk van UML en Archimate gewend bent.

Wat ook uniek is aan Dragon1 is om principes van bedrijfskundige concepten en informatiekundige concepten werkingsgericht te benaderen en te visualiseren. En als je dan een schets van een concept maakt, of fotografisch beeld dan zijn er stricte regels om een effectieve informele visualisatie ervan te maken. Zelfs formele diagrammen worden begrijpelijker als je ze werkingsgericht visualiseert met Dragon1.

Het feit dat je veel symbolen hebt in een modelleringstaal betekent nog niet dat je ze allemaal in elke visualisatie moet gebruiken. Als je een pakkende tekst schrijft, gebruik je ook niet alle woorden uit het woordenboek. Alleen heb je wel een goed gevuld woordenboek nodig om je altijd nauwkeurig te kunnen uitdrukken.

Goed verhaal en voorspelbare reacties. Ik heb een cursus bij Paauwe gevolgd en was vooraf zelf ook nogal sceptisch over het gebruik van een methode om architectuur te visualeren (ik maak mijn architectuur toch al in Powerpoint?). Ik ben inmiddels overtuigd van de toegevoegde waarde van de methode en dat is gekomen door twee dingen. Ten eerste de praktijk voorbeelden die Paauwe heeft laten zien maar belangrijker nog mijn eigen eerste pogingen om architectuur te visualiseren (op poster formaat) en daarmee de boer op te gaan. Eigenlijk toch wel tot mijn verbazing kreeg ik daar zeer enthousiaste reacties op en ontstonden er gelijk discussies op het juiste niveau en met de juiste mensen. Dat is ook gelijk het mogelijk probleem met dit artikel zoals in een eerdere reactie ook werd opgemerkt: het is lastig om in een artikel met woorden te beschijven wat het nut en het effect is van visualisaties. Je moet dat gewoon een keer gezien hebben om de kracht ervan te begrijpen.

Ik heb zelf nog nooit met dragon gewerkt maar mij er wel in verdiept en de voorbeelden geanalyseerd. Het levert echt een goede bijdrage aan het vertalen van IT naar business en andersom. Ik heb een paar jaar met archimate gewerkt en daar zie je dat een taal of visualisatie eerst voldoende bekend moet zijn onder de doelgroep anders begrijpt niemand het en sta je iedere keer een cursus archimate te geven. Ik werk met powerpoint en visio of keynote en omnigraffle en dat is iedere keer mijn startpunt voor alles, tekst klop ik pas later in.

Voor Mark is er nog een evangelisatie van Dragon te doen, ook vind ik het prijsniveau een behoorlijke drempel en met mij veel organisaties. Misschien toch ook eens nadenken over een light uitvoering of een gratis app?

En dat het lastig is om een visualisatie te beschrijven heeft mark wel duidelijk gemaakt gezien de reacties en de uitleg...
Het motto van de reageerders is vrij negatief, maar ik weet niet of iemand heeft gekeken wat dragon inhoud, het is echt de moeite waard.

In het begin was ik sceptisch! Methode nummer zoveel. Nu: mijn praktijkervaring heeft laten zien dat visualisaties van grote waarde zijn, juist op het moment dat er gecommuniceerd wordt met management en directies. De methode heeft voor mij dan ook zijn toegevoegde waarde. Het resultaat was namelijk wederzijds begrip en duidelijkheid, een startpunt voor heldere vervolgafspraken. Het is deze kapstok van waaruit een verdere uitwerking van de betreffende voorziening gerealiseerd kan worden. Stem je communicatie af naar gelang je doelgroep. Dragon1 is voor mij en mijn opdrachtgevers heel krachtig gebleken.

Dit is meer een reactie op Willem dan op het hoofdartikel realiseer ik mij, maar voor de marktcontext van belang.

Ik heb al veel kennis genomen van verschillende enterprise architecture tools en de kosten hiervan.
Bij het selecteren van software en methoden probeer ik altijd primair naar de waarde te kijken in plaats van de kosten. En qua waarde staat Dragon1 er heel goed voor.
Ook als we sec naar kosten zouden kijken is Dragon1 ten opzichte van alternatieven in de markt zeer competitief en daardoor zeer toegankelijk om mee te starten.

Mark,

Op zich best een leuk artikel. Alleen neig ik ook een beetje naar het gevoel wat Ewout ook al heeft. Ondanks Dragon1 een open architectuurmethode is, is het er wel 1 die je zelf ontwikkelt hebt en waar je je dagelijkse boterham mee verdiend.

Misschien verdien je je boterham niet met de methode, maar wel degelijk met de trainingen,consultancy en de softwarecomponenten van deze methodiek.

Het komt daarom bij mij wel een beetje over als preken voor eigen parochie. Ook omdat je in 1 van je reacties verwijst naar een link die onderdeel uitmaakt van een site waar men licenties kan aanschaffen.
(Structuurvisie: http://www.dragon1.com/images/dragon1-voorbeeld-eisen-ict.png_)

Op zich niets mis mee hoor. Maar dit ligt er voor wel iets te dik bovenop.




Mark,

Op zich best een leuk artikel. Alleen neig ik ook een beetje naar het gevoel wat Ewout ook al heeft. Ondanks Dragon1 een open architectuurmethode is, is het er wel 1 die je zelf ontwikkelt hebt en waar je je dagelijkse boterham mee verdient.

Misschien verdien je je boterham niet met de methode, maar wel degelijk met de trainingen,consultancy en de softwarecomponenten van deze methodiek.

Het komt daarom bij mij wel een beetje over als preken voor eigen parochie. Ook omdat je in 1 van je reacties verwijst naar een link die onderdeel uitmaakt van een site waar men licenties kan aanschaffen.
(Structuurvisie: http://www.dragon1.com/images/dragon1-voorbeeld-eisen-ict.png_)

Op zich niets mis mee hoor. Maar dit ligt er voor mij wel iets te dik bovenop.

Visualiseren heeft zich meermalen bewezen. Daar is wat mij betreft geen discussie over :-)
Heb je nog nooit het effect ervaren? hang dan eens wat tekeningen (A1 formaat) van een nieuwe of aangepaste architectuur of proces in de gang op en leg er wat stiften en gele briefjes bij. In no time zijn je fouten er uit en barst het van de innovatieve en wellicht onmogelijke aanpassingen. Zeker in de buurt van de koffiemachine!
En je bepaald nog steeds zelf wat je er mee doet en welke tools je daarvoor gebruikt.
Maar bovenstaande ruikt wel een beetje naar reclame wat mij betreft.

Mark,

Hoewel visualisatie ook in mijn optiek een belangrijke rol kan spelen bij het ontwikkelen van enterprise-architecturen kan de open architectuurmethode Dragon1 mijns inziens haar pretenties dienaangaande niet waarmaken. Waar deze methode tekort schiet blijkt heel duidelijk uit jouw eerste, zeer heldere reactie aan Ewout Dekkinga.

In deze reactie ga je ontologisch volledig de mist in als gevolg van een mechanistische, dingmatige opvatting van het concept selfservice. Met name het “self” in de samenstelling “selfservice” is ontologisch – qua zijn - op geen enkele wijze dingmatig of procesmatig op te vatten, maar moet veeleer beschouwd worden als ruimte (en dan in de eerste plaats als werkruimte).

Als gevolg van deze dingmatige opvatting (“Vervang fiets door…. “) blijf je gevangen in een puur voorstellend, oorzakelijk, sequentieel denken in beelden, feiten, regels en processen en kom je niet tot een meer oorspronkelijk ruimtelijk denken.

Een vergelijking met bouwkundige architectuur dringt zich op. Een huis is allereerst een materieel ding dat qua constructie volledig doorgerekend kan worden. Maar een huis is ook een oord dat ruimten verschaft waarin mensen kunnen wonen (conform Heidegger in zijn befaamde lezing Bouwen Wonen Denken die hij ten gehore bracht op 5 augustus 1951 tijdens een congres over Mens en Ruimte).

Met je focus op beelden onderschat je ook het belang van de taal bij het overbruggen van de beruchte kloof tussen business en ICT. Aan informatie gaat altijd kennis (en dus ook taal en dus ook ruimte en dus ook in-de-wereld-zijn) vooraf, en dat is lastig te visualiseren als informatiearchitectuur zowel de aansluiting op de techniek als de aansluiting op de business voor haar rekening moet nemen.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×