enterprise architectuur

Projecten en allerlei vormen van ICT-architecten vormen in de praktijk vaak een wat onhandige combinatie. Er wordt in ieder geval veel over geklaagd in mijn omgeving. Zou daar wat aan te doen zijn?

Ieder zichzelf respecterend architectuuraamwerk kent architectuurdomeinen. TOGAF houdt het bij business, application, data en technology architecturen. DYA gebruik Product, Proces, Organisatie, Gegevens, Applicatie, Middleware, Platform en Netwerk. Zachman gebruikt Data, Function, Network, People, Time en Motivation.

Architect is in de digitale wereld een nogal „overloaded" begrip. Het betekent voor verschillende mensen verschillende dingen. Daarom hier mijn beeld.

• Het verschil tussen ontwerper en architect: is mijnerzijds een kwestie van schaal, zoals de RUP software architect ook gewoon een senior ontwerper genoemd zou kunnen worden.
• Het verschil van aandachtsgebied: je kunt een probleem oplossen door een keten, een bedrijfsinrichting, een informatievoorziening of technologie te veranderen. En meestal verandert alles tegelijkertijd. Wie houdt er overzicht over of al die veranderingen passen binnen de gekozen globale oplossingsrichting? Is dat de enige echte architect??
• Het verschil in scope: ben je al architect als je het globale ontwerp van een systeem neerzet, of ben je pas architect als je het globale ontwerp voor een familie van systemen neerzet?
• De balans tussen abstract en concreet: hoe meer je architectuur iets generiekers moet zeggen, hoe minder concreet het wordt, en hoe minder makkelijk de architectuur te vertalen valt naar een concrete oplossing in een project. Vanuit de gegevensgerichte "wereld" spreken we over het "datamodel voor alles" probleem: er is een datamodel te maken met twee entiteiten en twee relaties waarin de hele wereld te modelleren valt. Alleen heb je daar dus niets meer aan, want het levert geen overzicht, samenhang, et cetera meer op.

• Veel mensen weten niet hoe een goed eisenpakket er uit ziet. Vaak wordt eisenpakket verward met functionele eisen. Maar niet-functionele eisen (zie bijvoorbeeld ISO 9126) en allerlei constraints (tijd, geld, kennis, capaciteit, middelen) bepalen ook hoe de oplossing er uit kan zien. Als je maar een deel van de eisen kent, kun je nooit tot een goede oplossing komen.
• Veel mensen kunnen alleen maar concreet denken, en niet abstract. Dus een geïmplementeerde applicatie met zichtbare schermen snapt men, maar een domeinmodel van waar het in de organisatie om gaat snapt men niet. Denk bijvoorbeeld aan een opleidingsorganisatie waar de cursusadminstratie, de projectenadministratie, de financiële administratie en de agenda van trainers allemaal over dezelfde domeinconcepten gaan, maar deels verschillend geïmplementeerd zijn, (deels) niet-synchroon lopen, en in feite allemaal onbeheersbare kopieën bevatten van in essentie dezelfde domeinconcepten (cursist, factuur, cursusuitvoering, trainer, materiaal, budget, realisatie).
• Veel mensen kunnen niet omgaan met onzekerheid en durven geen keuzes te maken op onvolledige informatie. Dit fenomeen wordt versterkt door het watervaldenken, waarachter de filosofie zit dat als je maar genoeg details hebt, je alles in één keer goed kunt doen. Een architect probeert wel zo snel mogelijk tot een oplossingsrichting te komen, maar zal onderweg moeten bijsturen. Dat laatste wordt a) meestal vergeten b) als onelegant beschouwd en c) dus liever niet gedaan want daar score je niet mee. En bij wijzigingen in je huidige implementatie, zouden alle bestaande implementaties ook gewijzigd moeten worden, om synchroon te blijven met het betere begrepen domeinmodel. 

Vorige week kwam ik weer in de geijkte discussie terecht: we hadden het over het maken van een doelarchitectuur, en direct was er iemand die "geen tijd wilde besteden aan het zinloos uitwerken van een hele architectuur". Ik snap zo'n reactie niet. Waarom zou een doelarchitectuur een "hele" architectuur zijn? Wat is "heel" eigenlijk? Het klinkt als veel werk, in ieder geval. En dat bedoelt de spreker ook vaak: architecturen kosten te veel werk! En dan is het uitwerken er van ook nog "zinloos"! Goh, denk ik dan, hoeveel architecten zouden graag veel tijd steken in iets wat door hun omgeving als zinloos wordt gezien?

Steeds meer organisaties hebben aandacht voor enterprise architectuur. En daardoor kiezen ook steeds meer organisaties voor ArchiMate als taal voor het visualiseren van hun enterprise architectuurmodellen. ArchiMate is hier zonder twijfel uitermate geschikt voor. ArchiMate is namelijk de enige taal die het mogelijk maakt om in één visualisatie alle aspecten van zo'n architectuur te laten zien, en die daarbij toch een formele basis heeft. En als zodanig overstijgt ArchiMate duidelijk het niveau van "rechthoeken en pijltjes" in PowerPoint.

Maar alleen kiezen voor ArchiMate is niet voldoende. Want ArchiMate geeft wel voorschriften voor *hoe* er gemodelleerd kan worden, maar geeft geen richtlijnen voor *wat* er gemodelleerd moet worden. En dat laatste is het startpunt voor een goede visualisatie (en het achterliggende model).

Een voorbeeld: in ArchiMate kan de gegevensuitwisseling tussen applicaties op een aantal manieren getoond worden. Zo kan het via data flows tussen applicaties, via access relaties met een gedeeld data object, of via afhankelijkheden tussen services en/of interfaces. De data flow is hierbij het meest eenvoudig te modelleren, maar laat een aantal zaken onduidelijk. Zoals hoe de gegevens precies uitgewisseld worden. Ook blijft onduidelijk welke applicatie de gegevensuitwisseling initieert, of hoe de afhankelijkheden tussen de applicaties precies in elkaar zitten. Zaken die bij het maken van een roadmap voor opschoning van een applicatielandschap wel interessant zijn, maar voor toelichting aan gebruikers en/of managers vaak weer niet.

Een andere voorbeeld: ArchiMate zegt niet welke gegevens je over de elementen op een diagram vastlegt. En ook mist het een aantal elementen. Zo is eigenaarschap, van bedrijfsprocessen of applicaties, niet standaard te modelleren. En ook kent ArchiMate geen principes, knelpunten of veranderprojecten.

Een goede ArchiMate implementatie lost bovenstaande zaken op, en meer. In zo'n implementatie is er aandacht voor het maken van een pragmatische modelleeraanpak en het opstellen van handige modelleerrichtlijnen. Niet omdat het leuk is, maar omdat het nodig is om gericht de juiste modellen te maken.

Er is momenteel geen open standaard voor de vastlegging van architectuurprincipes. TOGAF 9 beschrijft een sjabloon voor vastlegging van individuele principes, maar biedt geen structuur voor het vastleggen van een verzameling principes in relatie tot elkaar en in relatie tot andere architectuurproducten. ArchiMate kent, als taal voor het vastleggen van architectuurproducten, momenteel geen architectuurprincipes in haar metamodel.

In juni 2010 heb ik met hulp van Ben Binnendijk van Cap Gemini en Eric Roovers van IDS Scheer een artikel gepubliceerd over het gestructureerd vastleggen van architectuurprincipes. Deze structuur kan in architectuurrepository’s gebruikt worden als aanvulling op het TOGAF Architecture Content Model (ACM) of het ArchiMate metamodel.

Kijk op Via Nova Architectura voor een html-versie van het artikel. Of download de PDF van het artikel.

De invoering van een gemeenschappelijk taal is niet makkelijk. Dat geldt ook voor ArchiMate als taal voor het modelleren en visualiseren van enterprise architectuur beschrijvingen. Bij de Dienst Justitiële Inrichtingen (o.a. gevangenissen en vreemdelingendetentie) zijn we hier zo'n 2 jaar mee bezig geweest. Afgelopen week heb ik samen met Ben Binnendijk hierover een presentatie gegeven op het Landelijk Architectuur Congres (LAC 2010, 24 november).

Op de site van het LAC 2010 kun je de volledige presentatie over de invoering van ArchiMate terugvinden 

Een paar hoofdpunten:

• Een gemeenschappelijk taal leidt tot minder discussies binnen het team
• ArchiMate kent een afgebakend toepassingsgebied - architectuurplaten op hoofdlijnen - voor minder gedetailleerde "praatplaten" blijft PowerPoint beter, voor gedetailleerdere diagrammen zijn bijvoorbeeld BPMN en UML weer beter
• ArchiMate is goed toepasbaar, alleen kunnen bepaalde concepten lastig of niet uitgedrukt worden. Iedere gebruiker zal moeten kijken in welke mate hij/zij ArchiMate op een pragmatische manier uitbreidt

   

De presentatie laat een goed beeld zien van de stappen die zijn gezet. Daarnaast krijg je ook een beeld van het soort diagrammen dat we hebben gemaakt. Door de tijdsrestrictie van een half uur zijn er ook onderwerpen weggelaten. Zoals de inrichting en het beheer van de repository, of regels voor het goed visualiseren van ideeën in het algemeen. Mocht je daar vragen over hebben, neem dan contact op.

Als ik als enterprise architect bij klanten actief ben, wordt de vraag vroeger of later gesteld: “wat is nu eigenlijk het nut van die Enterprise Architectuur (EA) van jou?” Of ook wel botweg: “Gaat dit nu ook nog iets bijdragen?” Geen onterechte vraag van pragmatici als projectleiders of COO’s, die vooral voor het resultaat gaan.

Welkom bij de Caerleon Enterprise Architectuur Podcast nummer 1 van maart 2006. Uw gastheer vandaag is Rijk van Vulpen. Caerleon is een Enterprise Architect adviesbedrijf in Nederland. Als u contact wenst op de tenemen met ons of feedback te geven op deze podcast, gebruik dan ons e-mail adres info@caerleon.nl.

In onze podcast delen we kennis met u over informatie architectuur en innovatieve ontwikkelingen in informatieland. Het richt zich op CIO's, business en informatie managers, die actuele informatie wensen met betrekking tot informatiemanagement en informatie architectuur. Iedere consultant van Caerleon heeft zijn of haar eigen focus en meningen, dus iedere podcast zal vanuit een eigen invalshoek kijken. En omdat de praktijk van informatie/enterprise architectuur nog steeds in ontwikkeling is, brengen we verschillende, soms conflicterende en zich ontwikkelende meningen.

Hoe komt het toch dat informatie in organisations niet veel innovatiever, consistenter en effectiever wordt toegepast?

Dat is de vraag die me nu voor jaren intrigeert. Ik zocht de antwoorden in disciplines zoals enterprise architectuur en informatie architectuur. Hoewel ik in dergelijke beta-wetenschap begon heb ik mijn blik verruimt naar de kunst, de veranderkunde, de semantiek en de filosofie.

In deze blog zal ik gaan zoeken hoe we informatie anders kunnen gaan gebruiken, om de informatiewerker optimaal te bedienen.