It's a Bloody Mess

De gebeurtenis

Laatst was ik, verleid door een intrigerende verwijzing naar een “SOA Maturity Scan”, weer eens op bezoek op de website van IBM. Dat had ik misschien beter niet kunnen doen. Ik begon enthousiast, het leek me interessant om eens te zien hoe zo'n gigant zo'n scan aanpakt. Welke niveaus zouden zij onderkennen, en welke criteria zouden ze hanteren? Zou het lijken op het vertrouwde rijtje “bevreesd, bewust, belegd, beproefd, beleid en begrepen”? En kun je dan, gegeven je huidige situatie, ook een verstandig advies krijgen over de meest effectieve ontwikkelingsstappen? Krijg je een duidelijke roadmap voor de groei naar volwassenheid?

Maar wat een gedoe is dat, zeg. Je moet je om te beginnen aanmelden. Logisch. Nou heb ik dat ongetwijfeld wel eens eerder gedaan; ik heb me tenslotte al jaren geleden verdiept in IBM's patterns for e-Business, en ik heb in de loop van de tijd ook al een hele verzameling IBM Redbooks gespaard, maar helaas, alle pogingen om met oude accounts aan te loggen mislukten jammerlijk. IBM had alle sporen van mijn bestaan in hun digitale wereld blijkbaar volledig gewist. Da's best pijnlijk. We hadden toch een hele constructieve relatie opgebouwd? Maar goed. Dan maar weer een nieuw account aangemaakt.

Jammer toch dat IBM niet gewoon gebruik maakt van de openID standaard. Dan zou je voor goed van al dat proprietary identitygedoe af zijn. Mijn ergernisniveau begon al wat te stijgen...

Uiteraard even snel louter de verplichte gegevens geregistreerd. Jammer genoeg wordt mijn standaard wachtwoord voor dit soort accounts door IBM niet geaccepteerd. En dat terwijl het wel gewoon voldoet aan de enige vermelde eis – minimaal 8 posities lang. Merkwaardig gepruts. Dan maar een ad hoc wachtwoord opgegeven, je moet tenslotte wat.

De ergernismeter stond inmiddels op 2. Toch maar snel teruggebladerd naar de Maturity Scan. Slordig trouwens, dat de site niet gewoon onthoudt waarom je je registeert, en je automatisch terugleidt naar de pagina die je wilde zien. Dat kan toch niet zo moeilijk zijn? Op andere sites werkt dat toch ook?

Oops, da's nou jammer. Ik word vanaf de pagina met de scan meteen weer teruggeleid naar de registratiepagina, met het vriendelijke doch dringende verzoek of ik toch nog maar wat aanvullende gegevens zou willen verstrekken. Dat kan toch niet waar zijn? Moet ik hiermee doorgaan? Oké dan, omdat ik toch nog steeds nieuwsgierig ben mag IBM best weten dat mijn bedrijf gevestigd is aan de Dorpsstraat in Madurodam. Als ze daar nou gelukkig van worden...

Met de meter bijna in het rood heb ik de scan uiteindelijk volbracht. Het is bepaald niet wereldschokkend. Het ziet er gelikt uit, dat wel, en bevat vooral veel verwijzingen naar IBM producten en diensten. Tsja, wat verwacht je ook anders. Maar mijn ergernis was weer dat gedaald. De scan deed het tenminste gewoon zonder haperen.

Uiteindelijk ben ik nog gezwicht voor het advies om vooral de IBM 'SOA newsletter' te gaan bekijken. Misschien dat ik daar nog wat nieuws van zou kunnen leren. Je moet toch bijblijven, niet waar? Maar hé, da's flauw, je moet hier alweer opnieuw aanloggen. Erger nog, het zojuist vers aangemaakte IBM account is hiervoor helemaal niet geldig. Je wordt gedwongen om weer een nieuw account aanmaken. Mijn adrenaline­niveau begint inmiddels gevaarlijk hoge waardes aan te nemen.

Maar wacht, het kan kennelijk altijd nog bizarder. Het ad-hoc wachtwoord dat IBM zojuist nog zonder mankeren accepteerde voldoet nu helaas niet aan de eisen van, eh, IBM. En het wachtwoord dat IBM zojuist nog weigerde, wordt gek genoeg nu ineens weer wel zonder enig probleem geaccepteerd. Is dat geen prachtig voorbeeld van ergerniswekkende SOA immaturity? Heeft de globally integrated company soms nog nooit van een enterprise directory service gehoord?

Overigens heb ik de hele newsletter uiteindelijk nooit gezien. Ik geef het eerlijk toe, ik ben volkomen verdwaald in het doolhof van de IBM website. Toch heb ik naar mijn idee, terwijl de stoom nog uit mijn oren spoot, nog behoorlijk mijn best gedaan. Ik geef niet zo snel op, en al helemaal niet als ik al een heleboel tijd heb verspild. Maar de zoekengine geeft simpelweg veel te veel hits en voornamelijk heel veel ruis. Dat is toch echt niet meer van deze tijd. Als dit representatief is voor de enterprise search service van IBM, dan is dat ver beneden het niveau dat ik vandaag de dag gewend ben. Ik heb al surfend tot vervelens toe nog meer nieuwe aanlogpagina's gekregen, allerlei onbegrijpelijke foutmeldingen te zien gekregen, en heb uiteindelijk met het oog op mijn bloeddruk de moed maar opgegeven.

Mijn gevoel over de website van IBM? It's a Bloody Mess.

Om over te peinzen

Noblesse oblige. Als je je als leverancier profileert als visionair op het gebied van enterprise architectuur, dan wekt dat bepaalde verwachtingen. Je kunt allerlei verzachtende omstandigheden aanvoeren. Natuurlijk is het dak bij de loodgieter altijd lek, en is het bij de concurrenten vast niet veel beter gesteld. Het is gewoon de zoveelste illustratie van de onvolwassenheid van de IT industrie. Allemaal 100% waar, maar het neemt de irritatie bij bezoekers en klanten echt niet weg.

Tegelijkertijd doet het je denken, wat je er van kunt leren. Het hele geval is in zichzelf in elk geval een prachtige illustratie van de noodzaak om meer onder architectuur te gaan werken. Minder chaos en meer eenheid.

Maar hoe zou je nou een complexe informatieruimte, zoals die zonder enige twijfel achter de website van IBM schuil gaat, een beetje snugger kunnen organiseren? En dat, want laten we wel realistisch zijn, onder de randvoorwaarde dat het geen volkomen verstarde, trage, onwerkbare bureaucratie oplevert. Enig idee?

Zoals zo vaak wijst de architecturele benadering de weg naar de oplossing. Wie zijn de belangrijkste belanghebbenden bij de website? De content managers? De verkopers van producten en diensten? De service managers? Nee natuurlijk niet! De website is er primair voor de klanten. Zonder klanten geen verkopen, en zonder verkopen geen inkomsten. Ook bij IBM geldt de aloude wijsheid dat de salarisketen begint bij klanten die bestellingen plaatsen en facturen betalen. Klanten zijn uiteindelijk de moeder van alle stakeholders.

En dus?

Stel dat IBM zijn website zou organiseren rondom zijn klanten en prospects. Dat de totale informatieruimte ingedeeld werd in regio's die zich op specifieke klantpopulaties zouden richten. En dat die regio's misschien nog verder gedifferentieerd zouden worden in rayons, die nog specifieker getarget zouden zijn op concrete klantgroepen. Stel dat de website zo vormgegeven zou worden dat u, als bezoeker, voortdurend de beleving zou hebben alsof u bij een bepaalde klantgroep zou horen. Dan zou het ineens niet meer zo gek zijn dat u, als u er bewust voor zou kiezen om een grens te passeren, op dat moment uw identiteitsbewijs zou moeten tonen.

Je zou je heel goed kunnen voorstellen dat er een content manager verantwoordelijk zou zijn voor het beheer van een rayon. Omdat zo´n persoon in beginsel binnen zijn rayon de vrijheid geniet om alles te doen wat zijn klanten en bezoekers tevreden zou kunnen stemmen, is er geen enkele reden waarom dat niet soepel, daadkrachtig en effectief zou kunnen zijn. Uiteraard geldt dat de overgang tussen de regio´s aan speciale voorwaarden verbonden is, en de overgang tussen gebieden aan nog strengere voorwaarden. Het herindelen van de regio´s is niet zo makkelijk, en de indeling in gebieden is nog lastiger te wijzigen. Flexibiliteit binnen de grenzen, en stabiliteit van de grenzen zelf. Is dat niet net zoiets als `separation of concerns´? Lijkt dat niet heel erg op 'high cohesion and low coupling'? Is dat niet waar je een goede architectuur aan herkent?

Die enterprise directory, die moet er natuurlijk gewoon komen. Dat is een kwestie van organisatie. Het vrije verkeer van personen vereist gewoon dat er een gemeenschappelijk identificatie­systeem bestaat. Dat kun je iedereen uitleggen. Dan blijft er nog maar één te kraken noot over. Hoe kun je op zo'n website je weg vinden? Hoe kun je voorkomen dat je een overstelpende hoeveelheid irrelevante hits krijgt? Een standaard zoekengine heeft geen idee van een indeling van de ruimte en geeft gewoon alles wat mogelijkerwijs relevant zou kunnen zijn. Maar waarom kent zo'n engine de geografische context eigenlijk niet? Waarom zou je niet, net als in een telefoongids, kunnen zoeken naar lokale items, intelokale items en internationale items? Dat is toch eerder vertoond? Een wereldkaart heeft een andere resolutie dan een stafkaart. En zelfs het domeinnamensysteem op internet is gelaagd. Waarom, zo vraag ik mij af, zou dit dan niet de geëigende zoekstrategie voor searchengines zijn?

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 3^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

Duivelse details

Architecten moeten zich niet met details bemoeien. Architecten zijn tenslotte hoog-gekwalificeerde professionals die spaarzaam met hun tijd moeten omgaan en zich dus wel moeten beperken tot hoofdzaken. Dat is althans het heersende inzicht onder veel architecten. Maar is dit ook terecht?

Er zijn veel argumenten aan te voeren die voor deze stelling pleiten. Architectuur gaat tenslotte om fundamentele ontwerpkeuzes die niet, of heel moeilijk achteraf te wijzigen zijn. Allerlei meer oppervlakkige ontwerpkeuzes zijn achteraf altijd nog makkelijk te wijzigen. Een lelijk behangetje vervang je nou eenmaal makkelijker dan een rottende heipaal. En dankzij de moderne technologie, met zaken als business rules, business process management systemen, enterprise service bussen en portals, komen er steeds meer mogelijkheden om het gedrag van applicaties run-time aan te passen aan wijzigende behoeften. Met als logisch gevolg dat architecten zich steeds minder met functionaliteit en steeds meer met ‘agile technology’ bezighouden.

Tegelijkertijd het is een algemeen erkende valkuil dat de architect die zich verliest in een moeras van details als de opper-nerd ervaren wordt. Een harde werker, een ongetwijfeld slimme expert, maar onbegrepen, weinig effectief en al helemaal niet daadkrachtig. Maar het is juist de kern van de functie van een architect dat hij een waardevolle en gewaardeerde gesprekspartner voor een opdrachtgever moet zijn. De gemiddelde opdrachtgever is nou eenmaal meer geïnteresseerd in meetbare resultaten dan in de onderliggende technologie. Dus architecten moeten nadrukkelijk bezig zijn met de tastbare effecten van de structurele aspecten van complexe systeemontwerpen en ze moeten dat op managementniveau uit kunnen leggen. Daar zijn ze tenminste voor ingehuurd. Architecten ontlenen op z’n minst een deel van hun waarde aan het in Jip-en-Janneketaal kunnen vertalen van ingewikkelde verhalen van specialisten. Ze moeten niet voor niets excellente communicatoren zijn. Maar is dat alles? Gaat het meer om de presentatie dan om de inhoud? Zou een goede spindoctor automatisch ook een goede architect zijn?

Microsoft heeft een weinig benijdenswaardige reputatie opgebouwd als het gaat om het ontwikkelen van gebruikersvriendelijke, begrijpelijke applicaties en systemen. Er zijn tal van voorbeelden van – vanuit het perspectief van de gebruiker – volstrekt onlogische constructies, onbegrijpelijke meldingen en inconsistent of op z’n minst weerbarstig gedrag. Microsoft is dan ook nog steeds het archetypische voorbeeld van alles wat er mis is in de digitale wereld. En haast iedereen kan er uit eigen ervaring over meepraten.

Apple toont juist aan dat het ook anders kan. Hun laatste ultra-thin client, de iPod-touch, blinkt volgens vriend en vijand uit door gebruikersgemak. Het ding heeft vast een operating systeem, maar als gebruiker merk je daar eigenlijk niets van. Het blijft volledig op de achtergrond. Toch kun je er ondermeer mee browsen, mailen, YouTube filmpjes bekijken, je eigen foto’s, video’s en muziek meenemen en afspelen, je aandelenportefeuille monitoren en routes plannen. Het apparaatje is niet meer dan 8mm dik, heeft een haarscherp, goed leesbaar touch-screen, het biedt eindelijk een bruikbaar mobiel toetsenbord, en het maakt op innovatieve wijze gebruik van ‘multi-touch’. De hele gebruikershandleiding bestaat uit een videofilmpje van een kwartier en al na een avondje uitproberen voelt alles volkomen vertrouwd aan. Bovendien hebt je er geen systeembeheerder voor nodig. Simpel, sexy en soepel.

De applicaties van Microsoft bieden een overvloed aan functionaliteit. Je kunt er in principe alles mee wat je zou willen, ze zijn tegenwoordig behoorlijk stabiel, de beveiliging is op orde en er valt ook verder weinig aan te merken op de fundamentele ontwerpkeuzes. Sterker nog, qua architectuur zijn ze voorbeeldig. Alle irritante eigenschappen zijn op de keper beschouwd niet meer dan oppervlakkige details. De applicaties op de iPod zijn daarentegen juist erg beperkt in functionaliteit en doordat alle functionele complexiteit zoveel mogelijk is vermeden, is de architectuur ook betrekkelijk eenvoudig. De onderliggende technische complexiteit is ongetwijfeld duizelingwekkend, maar vanuit het perspectief van de doorsnee architect zijn dat nou juist de details die hij graag aan de echte nerds overlaat.

De conclusie moet wel zijn dat Microsoft de beste architecten heeft en Apple juist de beste ingenieurs. Dus goeie architecten maken kennelijk slechte applicaties en voor werkelijk goeie IT-systemen heb je meer aan geniale ingenieurs.

De wereld op z’n kop!

Maar is de stelling dat goede architecten zich beter niet met details kunnen bemoeien op basis van dit ene voorbeeld dan ook te kwalificeren als

Flauwekul?

Het is van belang om je te realiseren dat niet alle details per definitie bijzaken zijn. Er zijn legio voorbeelden van details die over het hoofd zijn, die gezien uiteindelijk funest bleken te zijn. Een goede architect heeft een goed ontwikkeld gevoel voor zulke details. Om niet te zeggen: oog voor detail is een onmiskenbare kernkwaliteit voor architecten.

Soms heb ik wel eens het bange vermoeden dat de architecten die zich met de meeste verve achter de stelling verschuilen "omdat het niet bij hun functie past om zich met details bezig te houden", dat vooral ook beweren omdat ze volkomen vervreemd zijn van de hedendaagse technologie. Soms denk ik dat de stelling vooral populair is onder het type ivoren-toren-architecten die hun gebrek aan materiekennis proberen te verhullen door zoveel mogelijk afstand te creëren van de weerbarstige werkelijkheid. Het kaliber architecten die opmerkelijk vaak hun in wezen geniale architecturen verprutst zien worden door incompetente ontwerpers en ontwikkelaars.

De architectuuragenda

Het is en blijft een feit dat architectuur per definitie niet over details gaat. Het is tegelijkertijd een hardnekkig misverstand dat architecten dus niet voor details verantwoordelijk zouden zijn. Een gemiddelde opdrachtgever verwacht – mijns inziens terecht – van zijn architect dan hij zich namens hem met alle relevante details bezighoudt. Dat wil zeggen, met alle technische, functionele, juridische, sociale of ergonomische aspecten die – hoe futiel ook – het succes in de weg kunnen staan. De opdrachtgever heeft zelf immers niet de benodigde deskundigheid om te kunnen voorzien welke details relevant kunnen zijn, laat staan de tijd om zich er zelf mee bezig te houden. Anders gesteld, als de architect zich niet met de details bezighoudt, wie zou het dan moeten doen? De opdrachtgever zelf? De projectmanager soms?

Pas er als architect overigens wel voor op om al die relevante details ook met je opdrachtgever te bespreken, of, erger nog, de opdrachtgever te overvoeren met voor hem onbegrijpelijke details waarover hij een beslissing moet nemen. Verantwoordelijkheid nemen voor details is volstrekt wat anders dan je indekken door alle keuzes bij iemand anders neer te leggen. Een goede architect voelt haarscherp aan welke details hij zelf kan afhandelen en welke hij aan zijn opdrachtgever moet voorleggen en in dat geval, in welk stadium hij ze moet voorleggen. Een afgepaste dosering schept namelijk het vertrouwen dat de architect het ontwerpproces meester is, terwijl een overvloed aan kwesties – hoe relevant ook – juist twijfel zaait.

Het blote feit dat een architect geacht wordt zich met alle relevante details bezig te houden wil nog niet automatisch zeggen dat hij alles in z’n eentje moet doen. Sterker nog, een grote architect kan juist heel effectief zijn door allerhande specialisten in te schakelen om allerlei aspecten voor hem uit te laten zoeken. Een effectieve architect neemt op zo’n manier de leiding over het totale ontwerpproces, inclusief de detaillering, ook als het om een omvangrijk traject gaat. Dit geldt ongeacht de subdiscipline, dus of het om een businessarchitect, een softwarearchitect, een netwerkarchitect of een enterprise-architect gaat, de ambitie voor succes vereist een passie voor beeldbepalende details.

Architecten moeten als professional nadrukkelijk wel in staat zijn om hoofd- en bijzaken te onderscheiden. Ze houden zich als het goed is zelf intensief met hoofdzaken bezig, terwijl ze de bijzaken managen door ze uit te besteden aan bekwame derden – engineers, ontwerpers, analisten, vakspecialisten of junior architecten. Dat neemt echter niet weg dat ze de bijzaken niet uit het oog verliezen, maar er uitdrukkelijk regie over blijven voeren. Een goede architect laat het succes immers niet aan het toeval over.

Deze flauwekul ontzenuwt een actueel architectuurdebat op een pittige en soms zelfs controversiële manier. Het is de 3^de in een reeks flauwekul die op dit weblog gepubliceerd zal worden.

Ontraad de Architectuurraad

Common Sense

Werken onder Architectuur is werken vanuit een visie op de toekomst. Het start met het in kaart brengen van de huidige enterprise architectuur. Vervolgens wordt de architectuur voor de toekomst in beeld gebracht. Tenslotte wordt ieder ontwikkelingsplan – business zowel als IT – vanuit dat toekomstige enterprise architectuur perspectief beoordeeld. Als het past in de gewenste enterprise architectuur, of nog liever een bijdrage levert aan de gewenste enterprise architectuur, dan wordt een plan goedgekeurd, zo niet, dan moet het eerst bijgesteld worden voordat het de goedkeuring kan wegdragen. Zo simpel is dat (althans; in theorie).

Het belang van een goede enterprise architectuur is groot. Er zijn inmiddels tal van rapporten die aantonen dat bedrijven die architecture-savvy zijn, door de bank genomen veel beter presteren dan bedrijven die niet zo helder sturen op een gemeenschappelijke architectuur. Het feit dat er op een centrale plaats een overzicht wordt gecreëerd over de business- en de IT-dimensies in de enterprise blijkt een waardevolle asset. Het geeft bijvoorbeeld inzicht in de bestaande situatie en zet aan tot nadenken over mogelijke synergievoordelen. Keer op keer blijkt een rationalisatie van de enterprise architectuur – zeker als er gelijktijdig naar de business- en de IT-dimensies wordt gekeken – een verrassend grote bijdrage aan de vitaliteit en de slagkracht van een bedrijf te leveren. In een architecture-savvy organisatie wordt veel minder gediscussieerd voordat er een beslissing wordt genomen, is er veel meer draagvlak voor de genomen beslissingen en wordt er veel minder op eenmaal genomen beslissingen teruggekomen. Werken onder Architectuur en een gestroomlijnde besluitvorming gaan hand in hand.

Het spreekt vanzelf dat het ontwerpen van een enterprise architectuur op zichzelf onvoldoende is om ook daadwerkelijk in de goede richting te sturen. Er moet minstens ook een autoriteit gecreëerd worden die ergens in de besluitvormingsprocessen een – liefst doorslaggevende – stem krijgt. Een autoriteit die beleid kan vaststellen, die ontwikkelingsplannen vooraf moet goedkeuren, die ontwikkelingen die niet vooraf goedgekeurd zijn kan stopzetten en die zonodig vrijstellingen kan verlenen. Zo'n autoriteit moet bestaan uit de cruciale stakeholders in de enterprise. Zo'n autoriteit wordt doorgaans een Architecture Board of architectuurraad genoemd.

De Paradox

Volgens TOGAF is de

“Architecture Board is typically made responsible, and accountable, for achieving some or all of the following goals:

• Consistency between sub-architectures

• Identifying re-usable components

• Flexibility of enterprise architecture:

  • To meet changing business needs

  • To leverage new technologies

• Enforcement of Architecture Compliance

• Improving the maturity level of architecture discipline within the organization

• Ensuring that the discipline of architecture-based development is adopted

• Providing the basis for all decision-making with regard to changes to the architectures

• Supporting a visible escalation capability for out-of-bounds decisions”

Stuk voor stuk zeer nobele doelen. Toch is er een probleem. De “Architecture Board” wordt verantwoordelijk gesteld voor een bepaald soort belangen. In het architectuurjargon is zo'n board een stakeholder met heel specifieke concerns. De Architecture Board dient louter het belang van de Enterprise Architectuur.

Natuurlijk zijn er in de harde realiteit ook andere soorten belangen. Denk maar aan de belangen die georganiseerd zijn in de Project Portfolio Board, de Security Board of de Change Advisory Board, om er maar een paar te noemen. Het vervelende is dat elke Board de missie heeft om de ontwikkelingen in een bepaalde richting te sturen. Een richtingenstrijd ligt dan al snel op de loer.

Een beetje architect is gevoelig voor al die verschillende belangen; en probeert juist om oplossingen te bedenken die de belangentegenstellingen tussen de verschillende partijen kan overbruggen. Dat kan in de praktijk best betekenen dat er – in het belang van de bredere enterprise – concessies gedaan moeten worden aan de Enterprise Architectuur. En gegeven de missie van de Architecture Board is dat niet de meest geëigende plaats om zoiets geloofwaardig te kunnen doen.

Tegelijkertijd is het succes van de Enterprise Architectuur afhankelijk van het draagvlak binnen de enterprise als geheel. Vaak wordt gezegd dat een succesvolle Enterprise Architectuur business driven zou moeten zijn. Als je daarover nadenkt, dan moet je wel tot de conclusie komen dat de beslissingen over het gebruik en de ontwikkeling van de Enterprise Architectuur met álle relevante business belangen rekening moeten houden. Dus ook met rationele zaken als time-to-market, risico's en kosten; en zelfs misschien hier en daar wel met minder grijpbare zaken als reputaties, relaties en primatengedrag¹.

Dus, om te zorgen dat de enterprise architectuur als waardevol in plaats van als een last wordt ervaren, om te voorkomen dat een enterprise architecture board een single issue partij wordt en om te bevorderen dat de enterprise architectuur een business asset en geen IT bedenksel wordt, om zoveel mogelijk draagvlak voor de enterprise architectuur te verwerven, om al die redenen is het beter om een architecture board om te vormen tot, of op te laten gaan in een breder gericht bestuursorgaan. Een architecture-savvy bestuursorgaan, om precies te zijn. In het belang van een succesvolle enterprise architectuur moet je de specialistische architectuurraad ernstig ontraden. Is dat geen mooie paradox?

1Lees daar het boekwerkje “Help! Mijn baas is een aap” van Patrick van Veen maar eens op na.

In deze paradox wordt algemeen aanvaarde best practices ter discussie gesteld. Het is de 1^ste in een reeks 'uncommon sense' die op dit weblog gepubliceerd zal worden.

Dwarse concerns

De kwestie

In stakeholder workshops komt de vraag of een archITect zelf óok een stakeholder is, met enige regelmaat op tafel. Op het eerste gezicht is lijkt die vraag misschien triviaal, maar bij nader inzien is het niet zo eenvoudig om er een eenduidig antwoord op te geven. Wat is er aan de hand?

Veel archITecten ervaren het als hun verantwoordelijkheid om een hoogwaardig systeem te ontwerpen, een systeem dat bijvoorbeeld een zekere duurzaamheid heeft en dat goed past in zijn omgeving. Anders gezegd, zij voelen zich verantwoordelijk om binnen projecten een zeker tegenwicht te bieden tegen een al te sterke korte-termijn focus.

Er zijn allerlei concrete thema's waar archITecten traditioneel veel belang aan hechten. In een workshop dragen zij vaak onderwerpen aan als onderhoudbaarheid, hergebruik, het toepassen van standaarden, beveiliging en betrouwbaarheid. Soms zijn hiervoor – al dan niet na enige discussie – binnen de organisatie andere stakeholders te vinden die de primaire verantwoordelijkheid dragen. Denk maar aan zaken als beheerbaarheid (IT manager), cost-of-ownership (owner) en beveiliging (security officer). Maar er zijn ook punten waarvoor dit niet zo duidelijk ligt. Voorbeelden van dergelijke concerns zijn thema's als toepassen van architectuurprincipes, herbruikbaarheid of consistentie tussen de systemen. Maar zijn zulke architectuurwaarden daarmee dan ook automatisch architectuurconcerns? Dreigen archITecten dan niet de vergaarbak te worden van alle concerns die niet bij andere stakeholders belegd kunnen worden?

Wat te doen?

Sinds de IEEE in 2000 zijn “recommended practice for architectural description of software intensive systems” publiceerde, is er een breed geaccepteerd model (zie figuur) voor het maken van een architectuurbeschrijving. In dit model worden zaken als stakeholders, views, viewpoints, modellen en een architectuur gedefinieerd en met elkaar in verband gebracht. Het aardige is dat dit model impliciet ook een blauwdruk voor het architectuurproces in zich draagt: het daagt archITecten uit om met hun stakeholders in gesprek te gaan over hun concerns, en een architectuurbeschrijving op te splitsen in losse views die specifiek gericht zijn op een (groep) stakeholder(s). Het leidt er als het ware vanzelf toe dat een voorgestelde oplossing wordt besproken in termen van de mate waarin het de verschillende concerns van de verschillende stakeholders adresseert. Uiteraard hebben verschillende mogelijke oplossingen voor verschillende stakeholders verschillende voor- en nadelen. Je mag dan verwachten dat een er alternatief wordt uitverkoren dat het best gebalanceerd is.

De praktijk leert dat dit keuzeproces niet zelden een complex steekspel oplevert. Het hoort bij de rol van de archITect om in dat spel, in de zoektocht naar een voor alle partijen aanvaardbare oplossing, de bemiddelende diplomaat te spelen. Als je tot je door laat dringen wat dat voor consequenties heeft, dan wordt meteen duidelijk waarom een archITect die rol niet kan spelen als hij zelf al te expliciete belangen heeft bij een bepaalde uitkomst. Het is namelijk belangrijk dat je als archITect op zo'n moment boven de partijen staat en zelf geen partij in de onderhandeling wordt. En daarmee ligt de vraag op tafel wie er dan wel moet opkomen voor de typische architectuurconcerns.

Het ingewikkelde van deze kwestie is dat typische architectuurconcerns het karakter van cross-cutting concerns hebben – het zijn concerns die interfereren met de overige concerns. Dat maakt het onderhandelingsproces op zich al ingewikkeld. Een paar voorbeelden.

1. Hoewel iedereen rationeel kan accepteren dat het beter is als een website een hoge mate van consistentie heeft, is het tegelijkertijd lastig – en soms buitengewoon vervelend – dat het je beperkt in de mogelijkheden om je user interface zo goed mogelijk af te stemmen op de functionaliteit die je te bieden hebt, of dat het je dwingt om een terminologie te hanteren die je zelf misschien anders gekozen zou hebben, of dat je moet aansluiten bij een content management systeem dat amper voldoet aan de cruciale requirements.

2. Vanzelfsprekend kan het handig zijn dat de opgeleverde services vanuit verschillende bedrijfsprocessen aangeroepen kunnen worden. Maar om dan in een extra schil om een ingekochte webservice, ten behoeve van een zogenaamde canonicalisatie, een gemeenschappelijke taxonomie te moeten implementeren, dat kost wel een hoop extra tijd, geld, performance en bovendien – die vervelende conversies gaan immers nooit in alle gevallen helemaal goed – is het ook nog eens een extra bron van projectrisico's en incidenten.

3. De gemeenschappelijke corporate user directory bevat net niet die informatie die in het dagelijkse gebruik zo handig zou zijn – en dat terwijl de geselecteerde applicatie zelf al voorziet in een volledig functionele user database. Zonde! Maar ja, eenmalig besparen op een integratie-inspanning in het project zou daarna dan wel structureel extra werk op het gebied van provisioning en user management betekenen. Wat is wijsheid?

De kwestie is duidelijk. Hoe zwaar mag een project-overstijgend belang wegen ten opzichte van een specifiek projectbelang?

De best practices die we kennen onder de term «Werken onder architectuur» vereisen onder meer een duidelijke «separation of concerns» binnen het architectuurproces zelf. Het scheiden van verantwoordelijkheden dus, hetgeen betekent dat de archITect die binnen het project opgesteld staat om de regie te voeren over het totale ontwerpproces – van stakeholder analyse via architectuurschetsen tot detailbeschrijvingen – een andere persoon zou moeten zijn dan de archITect die waakt over de project-overstijgende belangen. Er is in principe niets op tegen dat een enterprise architect als één van de stakeholders betrokken is bij de fundamentele besluitvorming binnen projecten. Er is ook helemaal niets op tegen dat een enterprise architect, net als alle andere stakeholders, de mogelijkheid heeft om een beslissing waarmee hij zich niet kan verenigen voor te leggen aan een architecture board. De architecture board zal dan in zijn wijsheid, rekening houdend met alle belangen, een oordeel moeten vellen. Of die beslissing wel of niet in het voordeel van de enterprise architect uitvalt behoort af te hangen van de kwaliteit van de argumenten.

De project-architect zal zich daarentegen zeer terughoudend op moeten stellen in zijn standpunten over controversiële onderwerpen. Dat kan ook betekenen dat hij niet al te enthousiast de enterprise architectuur kan propageren. Er is uiteraard wel een natuurlijke lijn tussen de enterprise architect en de project-architect – waar mogelijk zal een project-architect zijn voorstellen in harmonie met de enterprise architectuur ontwikkelen. Waar geen keuze gemaakt hoeft te worden, is tenslotte ook geen grond voor een conflict. Slimme project-architecten kunnen dus door hun voorwerk veel lastige discussies voorkomen en ze kunnen door hun bemiddeling draagvlak creëren voor een oplossing. Met een goede stakeholder analyse kan een complex besluitvormingsproces soms verbazingwekkend eenvoudig tot voor iedereen bevredigende resultaten leiden. Daarmee hebben project-architecten in de praktijk toch veel invloed op de besluitvorming, misschien wel meer invloed dan ze gehad zouden hebben als ze zelf formeel verantwoordelijk waren gesteld voor het behartigen van de architectuurbelangen.

Tenslotte een vraag om mee naar huis te nemen. Als enterprise architecten verantwoordelijk gesteld worden voor een categorie van concerns in het bedrijf, zou er dan ook geen mechanisme moeten zijn waarmee wordt vastgesteld hoe succesvol ze daarin zijn, en zou succes niet evenzeer beloond moeten worden als andere stakeholders voor hun successen beloond worden?

In deze kwestie wordt een actueel architectuurthema op een scherpe manier geanalyseerd. Het is de 3^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.