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

Enterprise architect heeft recht op eigen webtool

 

Computable Expert

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

Neemt u een verkoper serieus die geen crm-tool heeft? Neemt u een it-manager serieus die geen cmdb-tool heeft? Deze blog laat zeven argumenten zien waarom het in mijn ogen verstandig is om van meet af aan een webbased enterprise architectuurtool in de organisatie in te zetten. Zeker wanneer het werken onder enterprise architectuur een speerpunt is op de agenda!

Elk door mij beschreven argument laat zien hoe ik de praktijk als visual enterprise architect met Dragon1 heb ervaren en heb vertaald naar pragmatische oplossingen.

1. Management. Als we enterprise architectuur zien als een instrument dat serieus gemanaged moet worden net zoals verkoop en inkoop, dan is het verstandig om een professionele architectuurtool te gebruiken. Professioneel aan verkoop doen, zoals crosselling of upselling, het werken met een integraal klantbeeld of slim aan inkoop doen, zoals eProcurement en Maverick buying is niet mogelijk en wordt door niemand in de organisatie gedaan zonder crm-tool of Purschasing-tool. Het beheer van medewerkerdossiers bij hrm en de boekhouding bij financiën wordt ook nergens meer gedaan zonder specialistische tooling. Om enterprise architecten goed hun werk te kunnen laten doen en het aantal handmatig geproduceerde architectuurdocumenten in de hand te houden is het verstandig om vanaf de start van het werken onder architectuur met een architectuurtool aan de slag te gaan.

2. Consistentie. Wanneer in de organisatie eerst met verschillende methoden en technieken het werken onder architectuur wordt verkend is de kans groot dat deze stukken architectuur niet goed op elkaar passen of aansluiten. Door een architectuurtool te gebruiken en het aanwezige architectuurvoorbeeld aan te passen op de eigen situatie, weet je zeker dat de architectuur als een consistent geheel wordt geadministreerd.

3. Hergebruik. Elke organisatie heeft een bestaande huidige architectuur (as-is). Alle werkuitvoering en veranderprojecten in de organisatie worden mogelijk gemaakt dan wel beperkt in hun vrijheid door de as-is-architectuur van de organisatie. Met een architectuurtool is het eenvoudig om samen te werken met een team waarbij ieder een eigen deel van de huidige architectuur in beeld brengt daar waar het geheel consistent is. De bouwblokken die de ene architect onderkent kunnen worden hergebruikt door de andere architect om zijn gedeelte van de organisatie goed in kaart te brengen. De aanwezigheid van een architectuurtool in organisaties alleen al zorgt er soms spontaan voor dat de huidige architectuur van de organisatie geheel of gedeeltelijk in kaart wordt gebracht. Zonder architectuurtool is de kans veel lager dat de huidige architectuur spontaan, dan wel gepland in kaart wordt gebracht.

4. Taakverdeling. Met een architectuurtool kun je van meet af aan taken verdelen: het ene lid van een architectuurteam focust zich op definities van begrippen, een ander lid maakt de praatplaten, iemand anders zorgt voor de onderliggende (meta)modellen en weer iemand anders doet onderzoek naar de juiste concepten en principes. Wanneer de organisatie ervoor kiest om een web based architectuurtool te gebruiken, komen ook direct de voordelen van samenwerken in een repository naar voren. Op elk moment en op elk plek kunnen leden van het architectuurteam en belanghebbenden daarom heen samenwerken aan architectuur in één en dezelfde tool.

5. Beheer. De wereld veranderd snel en dus ook de informatiehuishouding van een organisatie. Als architectuurdocumenten met kantoorautomatiseringssoftware zijn gemaakt, zoals een tekstverwerker, spreadsheet programma of presentatiesoftware, dan vergt het veel handmatig werk en tijd om steeds voor de volle 100 procent alle wijzigingen in alle losse documenten door te voeren. Met een architectuurtool kun je van de geadministreerde bouwstenen en samengestelde bouwblokken complete Word-documenten, Powerpoint-presentaties en Excelsheets genereren en wordt automatisch een wijziging in de data van een model doorverwerkt in de visualisaties en documenten in de database over dat model.

6. Kosten/baten verhouding. Een investering in een architectuurtool is altijd zeer legitiem in het licht van de productiviteitsverhoging per gebruiker; sneller kunnen doorvoeren van wijzigingen, geen tijd meer kwijt zijn aan het consistent maken van een document en het voorkomen van steeds opnieuw het wiel uitvinden als gebruiker door eenvoudig hergebruik van architectuur bouwstenen via de tool. Als een medewerker met een architectuurtool het kan voorkomen dat hij of zij een dag lang naar een document moet zoeken met bepaalde informatie of een document maakt dat er eigenlijk al is, is de architectuurtool al meer dan terugverdient.

7. Volwassenheid. Een vaak gehoorde opmerking uit de praktijk is: we zijn nog maar net bezig met architectuur in de organisatie. Het is voor ons nog te vroeg om een architectuurtool te gaan inzetten. We moeten eerst nog wat ervaring opdoen met het werken onder architectuur, om überhaupt een to-be-architectuur op te kunnen stellen, en nog diverse organisatiewijzigingen doorvoeren om architectuur goed in te bedden. Met een professionele architectuurtool kun je echter gefaseerd beginnen. De collega van verkoop begint ook eerst met het invoeren van klantgegevens voordat hij of zij ingewikkelde queries in de crm-tool maakt om klantgroepen te analyseren en de markt optimaler te bewerken.

Kortom, uit het oogpunt van proactief management, hogere consistentie, meer hergebruik, betere taakverdeling, realistisch beheer en een juiste kosten/baten-analyse hebben enterprise architecten het recht zoals hun collega’s op een professionele architectuur tool.

Voldoende

Je begrijpt zeker wel dat lang niet elke architectuurtool in voldoende mate voorziet in de boven genoemde argumenten. Een web based EA-tool voorziet echter wel in al deze argumenten. Zaak is dat je EA-tool hebt die niet een modelleertool is voor het maken van entiteit-relatie-diagrammen. Een echte architectuurtool is geschikt voor het ontwerpen van business- en it-totaalconcepten en het realiseren van organisatie-bouwwerken.

Naast het maken van modellen, kunnen met een EA-tool met zorg en aandacht krachtige visualisaties worden gemaakt van deze modellen en kunnen deze visualisaties interactief doorklikbaar worden gemaakt. Met onder andere als doel om het bestuur en directie van de organisatie met architectuurvisualisaties te ondersteunen in het nemen van strategische beslissingen. Dergelijke interactieve kaarten, atlassen en ontwerpboeken blijken een effectief middel te zijn.

Ik adviseer organisaties dan ook om op elk moment te beginnen met het in beeld brengen van de huidige architectuur van de organisatie omdat deze continu van invloed is op de werkuitvoering en veranderprojecten. En richt een proces in om maandelijks of elk kwartaal deze architectuur bij te werken. Eenmaal voldoende in beeld is de architectuur ook beter stuurbaar geworden en kan een pakket aan samenhangende en elkaar versterkende maatregelen worden doorgevoerd. Met een echte architectuurtool kan het succes dan ook niet uitblijven.

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

?


Lees meer over


Partnerinformatie
 

Reacties

Visualisatie van modellen is aardig, maar helemaal niet noodzakelijk voor het bedrijven van enterprise architectuur en enterprise engineering. Ook niet voor de besluitvorming aan de directietafel. Gecodeerde lijstjes werken beter en sneller (althans, dat is mijn ervaring). En volgens mij denkt Moeder Natuur daar qua ontwerp ook zo over (zie RNA/DNA). Juist door het hokje-lijntje-pijltje-denken los te laten en in plaats daarvan gewoon met tekststrings en simpele codes te werken in een spreadsheet kan je veel sneller modelleren én de boel gemakkelijker bij-/onderhouden. Sheet op de beamer knallen en modelleren maar... business én IT gesprekspartners weten niet wat ze meemaken... super interactief en daardoor veeeel leuker om samen de complexiteit te vangen! Hier en daar een aloude GOTO opnemen naar een regeltje wat verderop... en voor detailniveau's die er even niet toe doen, hanteer je verdichtingen met meerdere levels... 1,2,3, klik, volgende abstractieniveau... heerlijk werken zo. Samenwerken en delen is eenvoudig te borgen middels een webbased sheet (bijv. in Google Drive) of een lokale repository (bijv. Excel in Sharepoint). Karakteristieken en relaties toevoegen... no problemo. Kwantitatieve waarden toevoegen voor quick-and-dirty simulaties... no problemo. Verwijzingen opnemen (hyperlinks)... no problemo. Versiebeheer... no problemo. Bedrijfseigen conventies hanteren... no problemo. M.a.w. wat een enterprise architect of enterprise engineer nodig heeft... is zowat overal al in huis. Mijn advies: niet lullen over een gelikte EA-toolset, maar poetsen. Om over onzinnige kosten maar niet te spreken.

Voor het daadwerkelijke succes (dus echt effect) van EA is consistent modelleren wel belangrijk, dus een modelleertool is nuttig. Maar een "EA Tool", laat staan een "webtool" (een item dat in de column verder niet terug komt) is niet de belangrijkste voorwaarde voor succes. Je krijgt toch een beetje "fool with a tool".

Verder krjig ik hier een beetje het "Wij van WC-Eend adviseren WC-Eend" gevoel bij. Het zou overtuigender zijn als niet de leverancier van een tool, maar de gebruikende business aan het woord was.

Gerben je haalt de woorden uit mijn mond. Ik kreeg net als bij het vorige artikel van Mark ook het WC-eend gevoel weer.

Een verkoper zonder CRM luistert vaak beter naar de klant, minder vooringenomen verkooppraatje. Ook dit artikel lijkt hier een euvel te hebben want praatplaten zijn leuk maar als ze de aansluiting missen met genoemde CMDB tools zijn ze erg statisch. Toch onderken ik, in tegenstelling tot Ralf nut en functie van grafische weergaven omdat ellenlange lijsten gewoon niet overzichtelijk zijn. DNA/RNA wordt naar ik meen tenslotte ook gemodelleerd omdat een plaatje uiteindelijk meer zegt dan duizenden regels code.

De vraag is echter of je dat moet doen met een nieuwe vertikale zuil - in de vorm van een webbased EA tool waar architecten blijkbaar recht op hebben - of door middel van een horizontale brug. Visualiseren van CMDB-tools lijkt me namelijk handiger dan weer een 'stand-alone' oplossing introduceren. Want ik ben het wel met Ralf eens ben is dat het uiteindelijk dus alleen maar om de repository gaat, relationeel of semantic. Nu is een BB natuurlijk geen CI maar er zijn wel degelijk overeenkomsten.

Zo zijn het beide discrete componenten met elk een unieke set van attributen waarbij er gebruik gemaakt wordt van abstracties, composities en decomposities. Sommige Configuratie Management Systemen zijn in staat om huidige en toekomstige situatie weer te geven wat me vergelijkbaar lijkt met EA tools. Indien ook relaties zijn vastgelegd kan er eveneens mee gemodelleerd worden met medeneming van de eigenschappen ten opzichte van andere componenten. Het grootste verschil tussen CI's en BB's is enkel hun context en zolang de Enterprise Architecten niet weten aan te sluiten op service management zullen (technische) wijzigingen in de architectuur tot verstoringen blijven leiden. Het 'onder architectuur werken' is door loshangende tools dan ook vaak meer utopie dan realiteit waardoor EA dezelfde kant op lijkt te gaan als ITIL, meer een proces dan een deugd.

De grafische representatie, zoals kan worden gepresenteerd met Dargon1 heeft een duidelijk meerwaarde voor een organisatie. Het maakt architectuur inzichtelijk en de grafische weergave communiceert prettig met alle stakeholders.
Er zijn echter veel tools en methoden beschikbaar en alle tools hebben hun plus en min. Om een consistente architectuur neer te zetten heb je volgens mij in de eerste plaats een repository nodig om alle bestaande architectuur producten in op te slaan om vanuit deze basis de toekomst op te bouwen. Dragon1 is een goed hulpmiddel om de transitie te visualiseren naar de uiteindelijke doelarchitectuur.
Door het oerwoud aan tools in de beheeromgeving blijft het lastig om een consistent beeld weer te geven en ook de organisatie betrokken te houden.

In de praktijk is het niet handig om de huidige architectuur inzichtelijk te maken, dit kan jaren duren en levert niets op, want de architectuur is in constante transitie door uitvoering van allerlei projecten. Start dus eerst met de opbouw van de repository met de gegevens rijp en groen door elkaar heen en ga van daaruit, liftend op projecten, de architectuur neerzetten die je hebben wilt. Pak de elementen uit Togaf, Dya en andere architectuurmodellen voor de transitie en gebruik in eerste instantie gewoon powerpoint, keynote of visio, bij de bouwblokken kan je vervolgens goed uit de voeten met Dragon, al is dat natuurlijk een keuze op basis van wat het kost en oplevert. Dat het een webtool moet zijn is volgens mij geen doorslaggevend argument.

@Willem
Ben jij ooit weleens dichter bij beheer geweest dan 100 meter?

Dat beheertools niet uitblinken in portabiliteit wil nog niets zeggen over de beheerprotocollen, SNMP is een vrij open standaard waarbij je wel de juiste MIB moet hebben om OID in klare tekst om te zetten. Stellen dat je huidige infrastructuur niet inzichtelijk moet maken lijkt me een structurele denkfout omdat het volgens mij het startpunt is voor elke wijziging.

Misschien dat ping en 'IP fingerprinting' niet altijd werken maar er zijn meer manieren en ik heb al eens wat geschreven over ADDM. Met enige zekerheid kan ik stellen dat webbased tools hier niet werken omdat SNMP en WMI geblokkeerd worden door een firewall. Maar uitspraak dat in kaart brengen van huidige architectuur jaren duurt is gewoon onzin. De snelheid waarop je een IP range kunt scannen is eerder uren dan dagen en dus is je reactie nogal 'disconnected'

Ik zal dan ook maar niet vertellen hoe vaak ik (logische) architectuur platen onderuit heb gehaald met open management protocollen maar het ligt dicht bij de 100%. Toevallig was meeste gebruikte excuus het argument van historie want legacy ontstaat door ontkenning en dus bouw je gewoon luchtkastelen als je historie buiten beschouwing laat en wat mijn vooroordeel betreffende Enterprise Architectuur alleen maar bevestigd.

Prachtig die architectuur platen maar als ik met eenvoudige 'cross scripting' er nog steeds gaten in schiet waar een olifant door heen kan dan stel ik toch wat meer vertrouwen in de Excel sheets van beheer. Misschien niet zo artistiek als M.C. Escher waar water tegen alle natuurwetten in omhoog stroomt en vissen plots vogels worden maar in elk geval wel wat geloofwaardiger.

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

×
×