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.
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.