architectuur

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. 

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.

Ik werd gewezen op de bijdrage van Niels Klinkenberg aan het LAC 2007 met betrekking tot SOE (de Service geOrienteerde Enterprise). In zijn presentatie wordt de relatie gelegd tussen service orientatie en een network van organisaties, gericht op slimme samenwerking. De presentatie definieert de condities waaronder je succesvol een SOE kunt neerzetten en hoe je hem werkend krijgt.