architect

Projecten en architecten gaan prima samen

joost.lommers 07 Aug 2011

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?

"Ben ik net lekker bezig met een project, komt er een architect langs die zegt dat het anders moet"

Je kent de situatie wel. Je hebt een idee voor een nieuwe dienst en weet dat daar veel behoefte voor is. Gelukkig denken meer mensen binnen je organisatie dat ook, en je start een project om de boel op te zetten. Er moet wel een nieuw stukje website ontwikkeld worden, maar niemand ziet daar veel problemen in. Eind goed, al goed. Alleen, een paar weken later krijg je een telefoontje. Van een architect die even wil bijpraten over je project. Tijdens dat gesprek blijkt dat je mooie webuitbreidingen eigenlijk helemaal niet kunnen. Dat het op deze manier niet binnen het huidige informatie- en ICT-beleid past. Er moet nu fundamenteel opnieuw over het project nagedacht worden. Je staat perplex. Kan dit inderdaad zo maar gebeuren? En kan het niet anders?

Natuurlijk kan zoiets anders. Bovenstaand voorbeeld is een typisch geval van te weinig afstemming tussen de architectuurfunctie en de projectorganisatie. Vaak ontstaat dit hoog in de organisatie. Verschillende managers krijgen dan verschillende doelen mee, die niet op elkaar afgestemd worden. Zo zal de gemiddelde business manager gaan zorgen voor meer omzet, minder kosten of meer marge. En de CIO zorgt ondertussen voor meer kwaliteit in de informatievoorziening, tegen minder kosten. Iedereen blij, natuurlijk.

In projecten blijken deze doelen regelmatig tegenstrijdig. Want meer omzet kan prima lukken met een nieuwe dienst. Die even snel via een nieuwe website in de markt wordt gezet. Als die website echter met nieuwe technologie wordt gemaakt, dan ziet de CIO plotseling extra licenties, extra beheer en extra diversiteit in zijn portfolio opduiken. Iets wat zijn of haar architecten zullen tegenhouden.

De uitweg uit deze impasse in tweeërlei. Zorg ten eerste dan in ieder businessproject zo snel mogelijk een architect betrokken is. Een dooddoener, denk je. Maar ik zie nog steeds legio projecten waar dit niet gebeurt. Aangezien architecten de bedrijfsbrede doelarchitectuur kennen, kunnen zij adviseren over een maakbare, en haalbare oplossing. Ten tweede: architecten mogen geen architectuuroplossingen inbrengen die niet binnen de looptijd van het project te realiseren zijn. Loopt het project een jaar? Dan kan het niet zo zijn dat projectresultaten moeten voldoen aan een doelarchitectuur die pas over drie jaar gaat gelden. Architecten zullen dus, of op projectbasis, of bedrijfsbreed, moeten toewerken naar aan realistisch architectuurdoel. Geen luchtkastelen waarbij alles tegelijkertijd op de schop moet, maar haalbare doelarchitecturen die de kwaliteit van de informatievoorziening telkens een stapje verbeteren.

Architect en architectuurdomeinen

joost.lommers 31 Mei 2011

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.

Domeinen gebruik je om een probleem of oplossing inzichtelijk te kunnen vormgeven. De meeste problemen en oplossingen zijn niet triviaal. Daardoor zijn ze moeilijk in één plaat te presenteren (ook al denken veel managementguru’s dat iets niet bestaat als het niet in een 4-kwadranten model weer te geven is).

Kerncompetenties van een goede architect zijn om te kunnen bepalen welke domeinen nodig zijn het probleem inzichtelijk te presenteren (maak niet de fout om altijd alle domeinen te gebruiken), om te bepalen in welk domein de oplossing primair gevonden gaat worden (soms los je iets op met een betere applicatie, soms met een andere organisatie-inrichting, soms met een verandering van technologie), en hoe de oplossing vanuit haar primaire domein doorwerkt in de andere domeinen (een organisatie met kenniswerkerfuncties heeft niets aan een gedetailleerd werkend workflowmanagement systeem).

Wat doet een architect?

joost.lommers 10 Apr 2011

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

Voor mij is een architect iemand die het globale ontwerp neerzet voor de oplossing. Dat ontwerp is wel precies, maar niet gedetailleerd. Bijvoorbeeld bij een software architect: het is de opdeling in componenten, de definitie van hun samenwerking (via provided en required interfaces) en de definitie van die interfaces. Het is niet de inhoud van componenten (class niveau). Het is dus niet gedetailleerd (geen klasse-opdeling), maar wel precies (interfacespecificaties). En ik zou via stubs de globale werking van het systeem kunnen prototypen. Software is echter maar een deel van de oplossing, en idealiter beschrijft het globale ontwerp de totale oplossing.

In het globale ontwerp zitten beslissingen over hoe de oplossing in elkaar zit, zowel constructief (bv gebruik van één-loket gedachte, gebruik OO paradigma), als functioneel (denk aan de begrenzing van het probleem, maar ook aan XP's metafoor) als technisch (denk aan allerlei gekozen (outsourcing)partners en tools). Hiervoor is het begrip „enterprise architectuur” bedacht. Een enterprise architect is iemand die de oplossingsrichting vorm geeft over allerlei domeinen heen.

Verder geeft de globale oplossing aan, liefst expliciet (maar minstens impliciet) welke detailontwerpen toegestaan zijn (en welke uitgesloten worden). De globale oplossing is een leidraad naar een goede oplossing (eindproduct met vooraf gedefinieerde kwaliteit), en maakt het ook mogelijk om die goede oplossing op een goede manier te bereiken (het stuurt de proces-/projectinrichting).

In de rol van architect zitten nog wel wat onduidelijkheden:

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.

Vervolgens zijn er een aantal uitdagingen die de architect aan mag gaan:

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.

Misschien toch wel een beetje een schaap-met-5-poten-rol, zo’n architect. Ik blijf dus dromen dat het nog eens echt goed wordt gedaan....

Training en Coaching van informatie architecten

rijk.van.vulpen 11 Nov 2009

Training en Coaching van informatie architecten

De toegevoegde waarde van de architect

Enterprise architecten hebben soms moeite om duidelijk te maken welke waarde ze toevoegen in de organisatie. Dat helpt niet om hun rol richting management en in projecten overtuigend te spelen. Ze worden vaak als vertragende ivoren toren denkers gezien. Natuurlijk kan dat heel anders. Bijvoorbeeld met een elevator pitch, waarvan de bijdrage afdruipt.

Persoonlijke vaardigheden

Architect zijn is veelzijdig. Je luistert scherp en open. Je onderhandelt stevig. Je brengt duidelijk over waar je voor staat. Je argumenteert onderbouwd en weloverwogen. Je zoekt het contact met alle belanghebbers. Je weet je gevechten te kiezen, politiek vaardig. Dat vraagt een schaap met vijf poten. Architect coaching brengt je verder.

De botsing tussen projectleider en een architect

De belangen van een projectleider en een architect lijken vaak strijdig. De eerste wil de oplossing realiseren binnen de mogelijkheden, beschikbare resources en tijd. De ander wil een hoog kwalitatieve en sluitende oplossing. De belangen botsen. Maar projectleider en architect kunnen elkaar ook opstuwen naar een prachtig resultaat.

Praktische architectuur

Architectuur is abstract en taai, in de vorm van principes en omvangrijke A3 platen. Maar architectuur kan ook heel concreet en snel zijn. In een duidelijke oplossing voor een project. In heldere keuzes en doorgehakte knopen. In een innovatief ontwerp. In direct antwoord op de vraag. Concreet worden is een kwestie van een paar uitgangspunten in de gaten houden.