Gracieus mislukken is oké

Er mislukken veel te weinig IT-projecten. Inderdaad, we zijn in de IT sector – zeker sinds in 1994 het eerste CHAOS rapport van de Standish Group uitkwam – pijnlijk doordrongen geraakt van het besef dat het meerendeel van de projecten mislukt. Sindsdien is het onderzoek regelmatig herhaald, en is het uitkomen van een nieuwe versie van het rapport telkens wel voer voor zure krantenkoppen. “Het gaat beter: nog maar 73% van de IT projecten faalt” - of stellingen van soortgelijke strekking. Vanwaar dan toch de stelling dat er nog te weinig projecten mislukken?

De Kwestie

Eerst maar eens de vraag wie of wat nou eigenlijk bepaalt of een project succesvol is of niet. Een triviale vraag? De Standish Group is er in elk geval heel stellig over. Een project moet binnen de vooraf afgesproken tijdlijnen en binnen het vooraf afgesproken budget de vooraf afgesproken functionaliteit volledig opleveren. Het probleem is dat deze heldere definitie in de praktijk nauwelijks iets te maken heeft met het begrip succes zoals we dat ervaren. Zo zijn er tal van voorbeelden van bedrijven, met Microsoft als lichtend voorbeeld, die in deze termen nog nooit een succesvol project hebben opgeleverd. Hun projecten lopen altijd uit, kosten veel meer dan geraamd, en tot op het allerlaatste moment worden features geschrapt die niet op tijd het gewenste kwaliteitsniveau halen. En dan nog regent het na een marktintroductie van een nieuw product klachten over allerlei gebreken en tekortkomingen. Toch heeft deze praktijk Microsoft bepaald geen windeieren gelegd.

Stel eens dat een project 10% over zijn geplande budget is gegaan, maar ook 30% meer rendement opbrengt, moet je het dan beschouwen als een mislukking? En een project dat veel vroeger dan gepland en tegen veel minder kosten dan geraamd de gevraagde functionaliteit oplevert, dat is toch een daverend succes. Of niet soms?

In het minst ongunstige geval leidt najagen van de vorm van succes die de Standish Group propageert alleen maar tot overdreven defensieve planningen, waarbij alle projecten die ook maar enig risico met zich meebrengen meestal niet eens worden gestart. Een al te defensieve planning is namelijk dermate pessimistisch dat er a priori al een negatieve business case ontstaat. En wordt het project wel gestart, dan is het gevaar levensgroot dat al het toegekende geld ook daadwerkelijk wordt besteed. Het project gaat leven naar zijn rijkdom. Het al te ver doorgevoerde principe van Underpromise en Overdeliver is op die manier een wel erg povere kwaliteitsstrategie.

Een nog minder aantrekkelijk potentieel gevolg is dat projecten van enige omvang worden opgedeeld in een verzameling deelprojecten die elk voor zich zo klein zijn dat ze bijna niet kunnen mislukken. Als iedere simpele activiteit al als een los project wordt georganiseerd, dan is het makkelijk te plannen en de kans op succes wel erg groot. Feitelijk wordt de complexiteit die inherent is aan de gestelde doelen buiten projecten georganiseerd. Er ontstaan vanzelf allerlei formele en informele overlegstructuren en coördinatiemechanismen die formeel niet te boek staan als projectactiviteiten, maar wel degelijk tijd en geld kosten. En de deelprojecten die niet worden gestart omdat de tijd en of het budget voor het product al zijn verbruikt, die tellen in de boekhoudkundige werkelijkheid niet langer als ongerealiseerde functionaliteit. Een dergelijke praktijk doet het waarschijnlijk goed bij de cententellers van de Standish Group, maar zo'n virtuele werkelijkheid zal de reële perceptie van de betrokken stakeholders hoogstwaarschijnlijk op geen enkele manier positief beïnvloeden.

Het komt ook voor dat als gevolg van de drang naar boekhoudkundig succes juist de slimste projectmanagers de meest uitdagende projecten weigeren omdat ze vrezen anders genadeloos afgerekend te worden op het uitblijven van succes. Als het durven te nemen van risico's wordt bestraft in plaats van beloond, dan ligt lafheid op de loer. En het inzetten van minder getalenteerde projectmanagers op de meer uitdagende projecten is zeker geen garantie voor succes.

Waar ging het eigenlijk ook al weer om bij een project als organisatievorm? Zoals zo vaak lopen de definities uiteen. Toch zijn er voldoende overeenkomsten. Een project is tijdelijk, heeft een vooraf gedefinieerd, uniek resultaat als doel en wordt begrensd door afgesproken condities. Een project heeft typisch een multidisciplinaire samenstelling, vaak wordt er over de grenzen van afdelingen samengewerkt, en – heel wezenlijk – een project kent beheersbare risico's. Dit laatste betekent impliciet dat een project geen aangewezen organisatievorm is voor voorspelbare, routinematige, steeds terugkerende activiteiten, ook al gaat het om complexe activiteiten. Het betekent tegelijkertijd ook dat een projectmatige aanpak niet geschikt is voor volstrekt onvoorspelbare, researchmatige of exploratieve activiteiten. Een ontdekkingstocht door ongekarteerd terrein laat zich nou eenmaal lastig plannen. Het vinden van de dader in een moordzaak is ook zoiets. Het maakt niet uit hoe zorgvuldig je het plant, en welke geavanceerde methoden en technieken je hanteert, er is geen enkele garantie te geven dat je binnen tijd en budget met zekerheid de ware dader kunt identificeren.

Projecten hebben dus van nature een gematigd risicoprofiel. Risico's vertalen zich in onzekerheden. Het is dus normaal dat een project niet precies verloopt zoals je van te voren had gepland. Het is ook heel normaal om je dan af te vragen of het wel zinvol is om zo'n project door te zetten. Een organisatie met een laag percentage mislukte projecten moet zich dan ook serieus afvragen of ze wel goed bezig zijn.

Er bestaat ook een heel andere definitie van een succesvol project. Die is misschien wat subjectief, maar sluit wel veel beter aan bij de beleving van de direct betrokkenen. Hij luidt simpelweg dat een project succesvol is als de verwachtingen van de belangrijkste stakeholders nét worden overtroffen. Iedereen voelt wel aan dat verwachtingen lastig te objectiveren zijn. Ze hebben te maken met ervaringen uit het verleden, ze kunnen door allerlei omstandigheden worden beïnvloed, en ze kunnen in de loop van een project bijgesteld worden. Dergelijke argumenten worden door typische pennenlikkers aangevoerd om te onbruikbaarheid van zo'n definitie aan te tonen. In hun simpele, boekhoudkundige werkelijkheid hebben ze ongetwijfeld het gelijk aan hun zijde. Echter, de weerbarstige realiteit van alle behalve de meest simpele projecten toont keer op keer onomstotelijk aan dat indicatoren als “individuele prestaties” en “collectief succes” eenvoudigweg niet in simpele metrieken gevangen kunnen worden. En succesvolle projectmanagers weten dat een actief management van de verwachtingen van stakeholders onmiskenbaar leidt tot een hogere tevredenheid.

Wat te doen?

Er bestaat een krampachtige neiging om eenmaal gestartte projecten koste wat kost tot een goed einde te brengen. Hoe loffelijk doorzettingsvermogen ook is, dit is doorgaans niet in het belang van de organisatie. Alle tijd en resources die in een dergelijk project worden geïnvesteerd blokkeren immers andere, potentieel waardevollere initiatieven.

Gezonde organisaties beschikken over een goed gevulde portefeuille met projectvoorstellen. Het is uitermate wenselijk dat er veel meer goede ideeën zijn, dan er middelen zijn om ze uit te voeren. Dat betekent namelijk dat er scherp gelet moet worden op de kwaliteit van de voorstellen. Een slimme organisatie investeert immers alleen in de allerbeste ideeën.

Dat maakt de vraag opportuun hoe je het best op voorhand kunt vaststellen welk idee het meest kansrijk is. Hoe kun je uit al die voorstellen de projecten selecteren die het hoogste rendement op zullen brengen? Het antwoord op dergelijke vragen is simpel. Dit is voor iedereen die niet paranormaal begaafd is een onmogelijke opgave. Nauwkeuriger geformuleerd: een grondige analyse van de projectvoorstellen zou zodanig veel tijd en geld kosten, en zoveel risico met zich meebrengen, dat die analyse op zichzelf al een projectmatige aanpak zou vereisen. Waarmee de vraag opportuun wordt welke projectanalyse­projecten voorrang zouden moeten krijgen. Want – het laat zich raden – gezien de beperkte hoeveelheid tijd, mensen en middelen kunnen helaas niet alle voorgestelde projectanalyseprojecten uitgevoerd worden. Maar wie bepaalt dan op basis waarvan welke projecten geanalyseerd mogen worden? Er doemt al snel een netelige analysis paralysis op.

Het is een veel betere tactiek om veel meer projecten te starten dan de beschikbare resources toelaten en een evolutionaire aanpak te kiezen waarbij de sterksten automatisch overleven. Huh? Jazeker! Creëer een gezonde competitie tussen een stel opstartende projecten en beslis na verloop van tijd op basis van de feitelijke vorderingen welke projecten ook echt doorgezet worden. Stel dat er een capaciteit is om van 100 ingediende voorstellen er 10 te realiseren. Het zou wel erg toevallig zijn als van al die 100 voorstellen onmiddellijk duidelijk is welke 10 voorstellen het verdienen om gerealiseerd te worden. Maar het is niet zo moeilijk om er 30 aan te wijzen waar de 10 beste voorstellen met aan zekerheid grenzende waarschijnlijkheid tussen zitten. Geeft die 30 de kans om hun plan een slagje dieper uit te werken, en beslis dan welke 15 er nog een iteratie verder mogen. Tegen die tijd is vast wel duidelijk welke 15 in elk geval niet tot de 10 beste voorstellen behoren. Deze projecten mogen gracieus mislukken. Ze hebben een eerlijke kans gehad, de uitgewerkte plannen zijn ten opzichte van de andere plannen (nog) niet goed genoeg. Iedereen kan inzien dat deze projecten onder de gegeven omstandigheden niet rijp genoeg zijn om echt succesvol te worden. Dat is geen schande, dat is 'all in the game'.

Na nog een iteratie wordt het steeds scherper duidelijk welke 10 projecten echt de besten zijn. De business cases zijn uitgehard, alle risico's zijn geïnventariseerd, de belangrijkste risico's zijn al onschadelijk gemaakt en voor de overblijvende risico's zijn de beheersingsmaatregelen benoemd. Het pad voor succes is geëffend.

Is een dergelijke ogenschijnlijk verkwistende procedure zonde van de verspilling? Denk opnieuw! Het creëren van een gezonde competitie is een elementair economisch principe om de gezondste bedrijven uit een groep uit te selecteren. Het blijkt in de praktijk het meest efficiënte mechanisme dat we kennen. Er is, paradoxaal genoeg, geen betere manier bekend om verspilling juist tegen te gaan. Waarom zou ditzelfde principe bij projecten niet net zo goed kunnen werken? Misschien nog wel het mooiste aspect in deze aanpak is dat er een expliciet belang voor de opdrachtgever c.q initiatiefnemer is om tijdens de opstartfase het maximale te doen om de ideale omstandigheden voor een succesvol project te creëren. En dat gebeurt dus ook. En het project dat na zo'n strenge selectie wordt uitverkoren om te worden gerealiseerd, verkeert vanaf het begin in een winning mood. Dat motiveert enorm! Deze combinatie van de beste plannen en de fitste projecten staat garant voor een maximale return on investment. Gegarandeerd.

In deze kwestie wordt een actueel architectuurthema op een messcherpe manier uiteengerafeld. Het is de 4^de in een reeks kwesties die op dit weblog gepubliceerd zal worden.

Wendbaar ondanks Architectuur

Een gewichtige paradox

Voor organisaties die zich serieus bezighouden met moderne, lichtgewicht ontwikkel­processen zoals eXtreme Programming, Scrum of ook wel het meer gangbare DSDM, is het dilemma ongetwijfeld herkenbaar. Deze op zich sympathieke methodieken zijn bij uitstek bruikbaar voor het oplossen van relatief overzichtelijke problemen. Projecten die je met een stuk of 6 medewerkers kunt realiseren zijn ideaal. Echter, zelfs in zulke betrekkelijk overzichtelijke projecten moet je toch wel over de nodige talenten beschikken om goed met de dynamiek in het project om te kunnen gaan. Je hebt heel wat ervaring nodig om op basis van een beknopte user story in korte tijd een voorspelbaar en bruikbaar deelresultaat op te leveren. Een deelresultaat dat bovendien in de toekomst nog moet passen in het grotere systeem, waarvan aanvankelijk alleen nog maar vage contouren bekend zijn. Want dat is immers de crux van Agile Development: alleen het hoogst noodzakelijke wordt gepland, er wordt liefst vanaf dag 1 met bouwen begonnen en er wordt heel snel productie geleverd. Er wordt wel een intensieve betrokkenheid van de klant verwacht om het project in goede banen te leiden. De klant is idealiter dagelijks aanwezig op de werkvloer, hij bepaalt zelf – op basis van de informatie uit het team – waaraan het team moet werken, en vooral ook waaraan niet. Dus als de klant het nut van formele documentatie niet ziet, geen prioriteit geeft aan stresstesten, of niet bereid is om te investeren in uitwijkprocedures, so be it.

Zo’n wendbaar project kan niet alleen op ieder gewenst moment een andere richting ingestuurd worden, maar het kan ook op ieder gewenst moment gestopt worden en desondanks toch een zinvol resultaat opleveren. In de praktijk wordt er natuurlijk pas gestopt als de opdrachtgever tevreden is of als hij om een andere reden stopt met het sponsoren van het project. Er zijn twee duidelijke voordelen: een opdrachtgever kan de ontwikkeling stoppen op het moment dat het systeem precies goed genoeg is; en het wordt makkelijker om de ontwikkeling van een half af systeem om welke reden dan ook een poosje te bevriezen en daarna zonder al te veel problemen weer op te pakken. Dit principe maakt dit type projecten overigens ook wel eXtreem kwetsbaar voor herprioritering, pardon, bezuinigings­operaties, maar dat terzijde.

Als deze manier van werken goed wordt beoefend, dan levert het volgens ingewijden bovengemiddeld elegante oplossingen op en hebben de bouwers bovendien tijdens het project veel fun gehad. Geen wonder dat de populariteit van deze manier van werken vooral onder geeks zo groot is.

Er is ook een downside. Goed beschouwd is complexiteit dodelijk voor lichtgewicht ontwikkelprocessen – die om die reden ook wel magere processen worden genoemd. Dergelijke processen zijn immers vanuit hun aard beperkt schaalbaar. Als je met meer mensen samen moet werken, dan krijg je vanzelf behoefte aan meer ceremonie – de span-of-control van zelf-sturende teams is immers vrij beperkt. En of je nu kiest voor meerdere parallelle teams, of grotere teams, of allebei, er ontstaat onvermijdelijk meer behoefte aan overleg en coördinatie. Trouwens, als de benodigde investeringen groter worden, dan worden de belangen en reputaties die in het geding zijn navenant groter, en zal er ook vanuit die hoek al gauw behoefte zijn aan meer sturing, control of governance.

Nou is er natuurlijk ook in de Agile methodieken wel nagedacht over het omgaan met afstemmingsproblemen bij het ontwikkelen van complexe systemen. Het basisidee is dat je niet alles van te voren probeert op te lossen, en de software die je maakt is dankzij de gekozen aanpak zo goed onderhoudbaar is dat je voortschrijdend inzicht heel makkelijk kunt verwerken. Op die manier kun je door refactoring de veranderingen doorvoeren om allerhande aansluitingsproblemen en voortschrijdend inzicht te verwerken. Dat klinkt heel goed, maar of je nou op die manier een echt ingewikkeld, bedrijfskritisch project tot een goed einde zou kunnen brengen…?

Het minste wat je kunt stellen is dat bovengemiddeld hoog gekwalificeerde, ervaren en gemotiveerde ontwikkelaars vereist zijn om succesvol systemen Agile te ontwikkelen. Ontwikkelaars die al het een en ander hebben meegemaakt, waardoor ze een mate van vakkundigheid hebben ontwikkeld die hen behoedt voor het maken van fundamentele ontwerpfouten. Teamspelers bovendien, die zonder al te veel sturing toch onderling effectief samenwerken - ook met klanten. Eigenlijk meer het type software architecten, die wat ze bedenken zelf bouwen, en wat ze bouwen goed doordenken. Korte lijntjes en zo min mogelijk overdrachtsmomenten, want hoe minder functiescheiding, hoe lichter het gewicht van het proces.

Maar al je daar even over doordenkt, dan betekent dat eigenlijk impliciet dat u uw beste mensen moet inzetten op niet al te complexe projecten! Zwaargewichten inzetten op lichtgewicht uitdagingen. Maar dat ligt niet onmiddellijk voor de hand! Zou u de beste ontwikkelaars die u in huis heeft, echt willen inzetten op eenvoudige klussen, omdat ze daar fun hebben en veel productiever zijn? Maar wie doen dan de complexere, mission critical projecten? Is dat geen schrijnend dilemma?

De uitweg

Gelukkig is er een uitweg uit deze paradox. Agile programmeren kan heel succesvol zijn, mits er een gezonde basis voor is gelegd. Daarmee bedoel ik een rijk platform met generieke enterprise en platform services die het leven van de ontwikkelaars makkelijk maken. En een set van standaarden, richtlijnen en best practices om die servicelaag goed te gebruiken. Minder ervaren ontwikkelaars kunnen zich toeleggen op het realiseren van specifieke functionaliteiten en de enterprise architecten waken over de generieke services. Waar nodig zullen ze deze services pro-actief onderhouden, maar doorgaans begeleiden ze de ontwikkelteams bij het gebruik van deze servicelaag.

De inzet van talent wordt dan overzichtelijk. De zwaargewichten houden zich bezig met de analyse van een complex problemen en de opdeling ervan in een aantal overzichtelijke deelproblemen. Voor de oplossing van deze deelproblemen schetsen ze de contouren en leggen ze principes en regels vast. En binnen zulke duidelijke kaders kunnen minder ervaren of getalenteerde collega’s, uiteraard onder de regie van de enterprise architecten, eXtreem succesvol zijn.

Er is wel een voorwaarde. Het vereist namelijk dat er strategisch geïnvesteerd is in een rijke collectie generieke services. Want alleen dan kan het ontwikkelen van een nieuwe, rijke functionaliteit relatief eenvoudig zijn. Een collectie services die bovendien voortdurend up-to-date gehouden wordt – achterstallig onderhoud in de generieke services zet projecten meteen op achterstand. En dat vereist niet alleen visie, maar ook een masterplan. Een Enterprise Architectuur. Want, om zoveel mogelijk vrijheid te kunnen bieden, moeten nou eenmaal duidelijke lijnen worden gesteld. Enterprise architecten zijn heel goed in staat om het nodige ceremonieel te betrachten in de richting van kritische stakeholders, en tegelijkertijd om op een meer informele manier effectief samen te werken met vakkundige ontwikkelaars en testers. Durf de bouwvergunningen af te schaffen, en schakel in plaats daarvan over op coaching en training-on-the-job.

Kortom: Met de best practices van Agile Development kunt u vooral heel effectief zijn als u ze combineert met de best practices van Werken onder Architectuur. Separation of concerns is het geheim achter de opschaling van lichtgewicht ontwikkelmethoden. En voor ieder viewpoint moet de hoeveelheid ceremonie voortaan afgestemd worden op de daarbij betrokken stakeholders. Logisch toch?

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

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.

Een enterprise architectuur voor het IT domein?

Bespiegeling

Stelt u zich eens voor dat u als business analist de opdracht zou krijgen om de IT-afdeling onder de loep te nemen. Dat u vanuit een bedrijfskundig perspectief zou mogen kijken naar de bedrijfsvoering van de IT. Of dat u als informatieanalist een informatieplan zou moeten maken voor de IT. Dat zou nog eens een uitdaging zijn!

Maar is dat eigenlijk niet merkwaardig? Is het niet opmerkelijk dat het de gewoonste zaak van de wereld is om als IT-afdeling het hele bedrijf te analyseren en plannen te maken voor verbeteringen, behalve voor uw eigen afdeling? Is een IT-afdeling echt zo bijzonder dat je die niet onder architectuur kunt brengen, of is het alleen maar een kronkel in ons denken? Het kan zijn dat er recentelijk iets veranderd is, dat alle IT-afdelingen een spectaculaire groei in maturity hebben doorgemaakt, dat de IT-projecten tegenwoordig over de hele linie goed voorspelbaar zijn, dat de risico's voorbeeldig gemanaged worden en dat de beheer- en exploitatiekosten van software een afgeleide zijn van de waarde voor de gebruikers. Kortom, het zou kunnen dat de huidige implementatie van de IT-processen nauwelijks ruimte voor verbetering laat. Iets zegt mij dat dit nog niet overal het geval is, dat er nog tal van IT-afdelingen zijn die juist volop ruimte voor verbetering hebben. En wat is er dan logischer dan eens te beginnen met een grondige business analyse?

IT-afdelingen worden niet zelden bevolkt door vrijgevochten IT-gebruikers. Waar vrijwel ieder ander in het bedrijf genoegen moet nemen met een standaard desk- of laptop, is er voor de power users op de IT-afdeling altijd wel een speciale regeling. Zij krijgen de snelste systemen, de mooiste beeldschermen en wel onbeperkt toegang tot internet. Goed, ze maken vast ook de meeste muis-kilometers, dus dat is misschien niet helemaal onverdedigbaar. Aan de andere kant, of het nou allemaal bedrijfskundig zo verantwoord is...? En eh, zou je niet juist van een IT-afdeling een voorbeeldgedrag verwachten?

Het is nog tot daar aan toe als er een zekere vrijheid op het gebied van soft- en hardware wordt genomen. Het is in potentie nog een stuk ernstiger als er op het gebied van IT-processen een soort vrijstaat is ontstaan. Als iedere project manager er zo zijn eigen ideeën op nahoudt over welke rollen er in zijn team zijn en voor welke taken zij opgesteld staan, dan ligt een zekere wanorde op de loer. Immers, de mensen die vaak oneerbiedig aangeduid worden met de term “project resources” acteren in de loop van de tijd in allerlei verschillende projecten, werken met allerlei verschillende project managers samen, en moeten zich steeds weer inleven in wat deze project manager onder het mom van Prince2 nou weer eist, verwacht of juist niet toestaat.

De mate van orde in de IT-processen wordt vaak gereflecteerd in de informatiearchitectuur. De informatiearchitectuur??? Oké, in veel gevallen zal dit een groot woord zijn voor de optelsom van de software die wordt gebruikt in de diverse ontwikkelstraten, voor project management en voor de exploitatie en/of support van de software. Maar zou het nou zo'n gek idee zijn? Toegegeven, er zullen hier en daar tussen de diverse teams wel wat muurtjes gesloopt moeten worden, maar zou dat niet eens de hoogste tijd worden?

Laat ik eens een aantal bedrijfsfuncties onder de loep nemen (jazeker, ook IT-ers kunnen gewoon een bedrijfsfunctie vervullen).

• Wat in de ontwikkelcyclus wordt aangeduid als requirements management komt tijdens exploitatie terug als service level management. Heeft u ooit meegemaakt dat er over de hele IT-afdeling gebruik werd gemaakt van een uniform systeem voor het managen van eisen, wensen en afspraken? Een systeem dat iedereen binnen zijn verantwoordelijkheidsgebied inzicht zou kunnen bieden in de optelsom en status van requirements – anders dan wat verspreide Excel sheets?

• Change management, dat is ook een mooi voorbeeld. Het bestaat over de hele levenscyclus van IT-systemen, je komt het tegen op het niveau van processen, software, middleware, hardware; de afhandeling is misschien niet altijd en overal even geformaliseerd, maar de wijzigingsverzoeken zijn wijdverbreid. Ook hier varieert de gebruikte tooling vaak enorm.

• Een ander voorbeeld is defect tracking. Ontwikkelaars zijn verknocht aan Bugzilla of iets dergelijks, terwijl de beheerderafdeling werkt met een incident management systeem. Er is geen integratie tussen die systemen, dus worden tickets gewoon overgetypt, of gebruiken de medewerkers meerdere verschillende systemen voor in essentie precies hetzelfde werk.

Trouwens, hoeveel verschillende WIKI's worden er op een gemiddelde IT-afdeling niet gebruikt voor kennismanagement. Is deze informatie eigenlijk wel voldoende actueel en betrouwbaar? En hoe consistent is bij u het versiebeheer geregeld? Is er echt één repository met alle laatste versies, ongeacht de leverancier of de gebruikte technologie? Hoeveel ontwikkelaars zouden er zijn, die voor hun ontwikkeltaken een andere workflowpakket moeten gebruiken dan voor hun derde-lijns beheertaken? Maar hoe kun je dan een fatsoenlijke planning verwachten, als er niet eens een overzicht is over de lopende activiteiten?

Misschien zou dit allemaal nog niet zo erg zijn als al die verschillende software tenminste allemaal prettig zou werken, of op z'n minst een beetje eenduidig zou zijn. Als het bijvoorbeeld – net als voor andere doelgroepen – netjes in een enterprise portal geïntegreerd zou zijn, als de ondersteuning gewoon geregeld zou zijn, en de licenties netjes beheerd zouden worden, als je na één keer inloggen meteen overal bij zou kunnen waarvoor je geautoriseerd bent. En er zijn ongetwijfeld nog tal van redenen te bedenken waarom het echt niet zo gek zou zijn om een robuuste enterprise architectuur voor de IT-afdeling te hebben.

Om over te peinzen

Het zou toch niet zo moeilijk moeten zijn om voor al dit werk – en de activiteiten die nog niet aan de orde zijn geweest – een flexibele en toch robuuste service georiënteerde architectuur te ontwerpen. Een verzameling Enterprise IT Services voor de veelvoorkomende bedrijfsfuncties, een Portaal waarin iedereen zijn favoriete IDE mag selecteren, zolang deze maar gebruik maakt van de achterliggende enterprise services voor taakbeheer, versiebeheer, incidentbeheer, modellenbeheer en wat dies meer zij. Qua processen is er natuurlijk een Business Process Management Systeem, waarin alle ontwikkel- en beheerprocessen ondergebracht zijn. Dit biedt overzicht en houvast. Het is misschien wat teveel gevraagd om voor alle ontwikkelprojecten eenzelfde proces in te richten. Maar heeft u zich wel eens afgevraagd of u er echt meer dan – zeg – drie verschillende nodig heeft? Bijvoorbeeld eentje voor grote projecten, eentje voor kleine, eenvoudige projecten en eentje voor kleine, innovatieve projecten. Het zou toch best kunnen om de rollen en taken te standaardiseren voor drie van dergelijke modelprojecten? Dat zou toch ook het advies zijn voor willekeurig welke andere afdeling in het bedrijf?

Je kunt je natuurlijk afvragen of je zelf een dergelijk wiel zou moeten willen uitvinden. De verschillen tussen verschillende IT-afdelingen bij verschillende bedrijven zijn niet zo groot dat je mag verwachten dat er een compleet andere enterprise architectuur opgetuigd zou moeten worden – even daargelaten de weinige bedrijven die het aanbieden van software producten of diensten tot hun core business rekenen.

Er zijn op zich voldoende best practices beschikbaar om een degelijk enterprise IT-systeem te ontwerpen. Denk maar aan ITIL, aan RUP, aan DSDM, aan SDM, aan COBIT en aan Prince2. Zou het dan geen gat in de markt zijn om zo'n enterprise IT-systeem te ontwikkelen? Een geïntegreerde werkomgeving voor IT-ers, die hen daadwerkelijk ondersteunt in hun dagelijks werk? Zou de productiviteit op de IT-afdelingen geen enorme boost kunnen krijgen, als er een gemeenschappelijk informatiesysteem voor de hele afdeling beschikbaar zou zijn? Zou de flexibiliteit van IT-ers niet enorm gebaat zijn bij zo'n gemeenschappelijk werkomgeving?

Er moeten vanzelfsprekend wel standaarden ontwikkeld worden, om een willekeurige repository van een willekeurige leverancier probleemloos als een service in de enterprise IT-architectuur op te kunnen nemen en om een vendor lock-in te voorkomen. En het moet natuurlijk zodanig geïntegreerd zijn, dat de oplossing van een probleem in de defectsservice gemakkelijk als een known error in de kennisservice gepubliceerd kan worden – ongeacht of het probleem is opgelost tijdens het testen of in productie. Dat is misschien best ingewikkeld, maar is dat nou juist niet waar IT-ers zo goed in zijn als het om andere probleemdomeinen gaat?

Het moet een weldaad zijn om in een bedrijf te mogen werken die zijn enterprise IT-architectuur zo op orde heeft. Bij de huidige schaarste aan IT-personeel moet daar dan toch ook een business case voor te maken zijn? Als nou eens iedereen zou beginnen om zijn leveranciers te melden dat het binnenkort afgelopen is met het kopen van gespecialiseerde utilities voor IT-problemen. Misschien moeten we zelfs wel een halt toeroepen aan al die goedbedoelde initiatieven om de laatste, hipste open source tooltjes te implementeren. Als we nou eens allemaal de komende maanden een RFI zouden opstellen voor het leveren van een volledig geïntegreerde werkomgeving voor alle IT-ers. Een enterprise systeem voor de bedrijfsvoering voor IT-afdelingen. Koppel het bijvoorbeeld aan een initiatief voor IT-Governance – dat is inhoudelijk goed te verdedigen en populair investeringsdoel. Stel tenslotte als eis dat een oplossing gebaseerd moet zijn op open standaarden. En dan maar afwachten of er leveranciers zijn die het voortouw durven te nemen. Zo niet, dan wordt dit toch gewoon een prachtig nieuw open source project. Doet u mee?

Since, my friend, you have revealed your deepest fear.
I sentence you to be exposed before your peers.
Tear down the wall, tear down the wall, tear down the wall...

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

Ontwikkelen zonder Architectuur

«Ontwikkelen onder architectuur» is een mooie, beeldende, typisch Nederlandse uitdrukking die zich jammer genoeg moeilijk in het Engels laat vertalen. Het appelleert aan een gevoel van doordachte, kwalitatief hoogwaardige resultaten. Het wordt geassocieerd met een architect die, als rechterhand van de opdrachtgever, een ingewikkeld bouwproces in goede banen weet te leiden. Een architect met verstand van zaken, die weet wat er op de markt te koop is, en die dat kan vertalen naar de dromen en verlangens van de opdrachtgever. Iemand die niet alleen maar praatjes verkoopt, maar ook verantwoordelijkheid neemt voor een succesvolle realisatie. Prachtig, toch?

Voor zover ik heb kunnen nagaan is het begrip «Ontwikkelen zonder Architectuur» voor het eerst geïntroduceerd in het alleszins lezenswaardige boekje van Sogeti, getiteld: “DYA – Snelheid en samen­hang in business- en ICT-architectuur”. Maar als het begrip «Ontwikkelen onder Architectuur» zulke warme gevoelens oproept, wat is dan «Ontwikkelen zonder Architectuur», in welke situatie zou je dat dan willen praktiseren en waarom is het eigenlijk überhaupt nodig?

Het genoemde boekje stelt dat er gegronde redenen kunnen zijn om zonder architectuur te willen ontwikkelen; bijvoorbeeld als je een oplossing heel snel moet realiseren – een korte time-to-market – of als je innovatieve technologie wilt toepassen. Het lijkt bedoeld als een soort ingebouwde escape in het architectuurproces, een escape die dient om managers die bang zijn voor een papieren tijger hun belangrijkste argumenten tegen «Ontwikkelen onder Architectuur» bij voorbaat uit handen te slaan.

Op het eerste gezicht lijken dit allemaal zeer valide argumenten. Waarom is het bij nader inzien dan toch je reinste

Flauwekul?

Het zou flauw zijn om er alleen maar op te wijzen dat het per definitie onmogelijk is om een systeem te ontwikkelen dat geen architectuur heeft. Immers, ieder systeem van enige complexiteit is opgebouwd uit onderdelen met onderlinge interacties, heeft wel enige interactie met de buitenwereld, en is conform bepaalde ontwerpprincipes gebouwd. Zelfs spaghetti heeft een bepaalde architectuur. Maar dat is ongetwijfeld niet wat de auteurs bedoeld hebben met hun, eh, woordgrapje. Ze hebben vermoedelijk bedoeld dat een bedrijf binnen haar enterprise architectuur bewust gekozen heeft voor het toepassen van bepaalde principes en standaarden, maar dat het desondanks soms toch wenselijk kan zijn om – al is het maar tijdelijk – systemen te accepteren die niet aan die zelfgekozen principes en standaarden voldoen.

Evengoed is de woordkeus op z'n minst ongelukkig te noemen. Het suggereert immers dat je maar twee mogelijkheden hebt: je ontwikkelt ofwel onder, ofwel zonder architectuur. Er lijkt geen tussenweg mogelijk te zijn. En dát is precies wat er zo wringt aan het begrip «Ontwikkelen zonder Architectuur». Het creëert een tegenstelling die er niet zou mogen zijn. Denk even mee.

Een uitgewerkt stelsel van principes en standaarden is zonder twijfel hartstikke nuttig. Tegelijkertijd is het in niemands belang dat zoiets een keurslijf wordt. Met andere woorden: in de praktijk heb je als architect soms behoefte om een afweging te maken van het belang van het toepassen van een specifiek principe of een standaard tegenover het toestaan van een afwijking. En als de nadelen van het toepassen van een standaard – in termen van ontwikkelkosten, exploitatiekosten en ontwikkeltijd – overduidelijk niet opwegen tegen de voordelen van een alternatief, dan valt het toch moeilijk te verkopen dat de enterprise architectuur principes onder alle omstandigheden onverkort moeten worden toegepast? Ontwikkelen onder architectuur zou toch juist moeten draaien om het maken van een evenwichtige afweging tussen alle concerns van alle stakeholders?

Dan nog iets. In de pure vorm van ontwikkelen zonder architectuur zou er sprake zijn van een architectuur die op geen enkele manier past in de bestaande enterprise architectuur. Dat houdt dus in dat de bedrijfsprocessen op een volstrekt andere leest zijn geschoeid dan de rest van de processen binnen de organisatie; dat een informatiesysteem op geen enkele manier past in de bestaande informatiearchitectuur en dat er van compleet andere technologiestack gebruik wordt gemaakt. Er zijn vast tal van praktijkvoorbeelden te bedenken waar zo'n totale breuk met de bestaande situatie heeft plaatsgevonden. Een aparte organisatie, met een aparte boekhouding, eigen gebouwen, een eigen manier van werken, een eigen website, een apart data warehouse en eigen informatiesystemen. Maar wacht even. Dan hebben we het in dat geval eigenlijk over een apart bedrijf, met een aparte identiteit, dat over de hele linie zelf zijn eigen keuzes maakt en ook zelf beslist over de inrichting van zijn eigen enterprise architectuur. Een nieuwe enterprise architectuur, naast een bestaande. Ook dat kun je toch heus niet betitelen als «Ontwikkelen zonder Architectuur»?

Dan was er ook nog het sympathieke argument dat het toepassen van nieuwe technologie in het algemeen nieuwe ontwerpprincipes en standaarden vereist. Principes en standaarden die je niet vooraf kunt vaststellen, althans als je niet helderziende bent. Het toepassen van nieuwe technologie vraagt typisch om een experiment, met als doel om in de praktijk te onderzoeken welke nieuwe principes en standaarden zinvol zouden zijn. Op zichzelf is dat toch geen flauwekul? En toch is er met dit argument iets raars aan de hand. Om te beginnen geldt ook hier dat het niet zonder meer logisch is dat een technologische vernieuwing een enterprise over de hele linie op z'n kop zet. Werkelijk alles tegelijkertijd proberen te veranderen is immers een riskante strategie die je in de praktijk gelukkig niet zo vaak tegenkomt. Maar stel je even voor dat er een project loopt dat erop gericht is om een nieuwe architectuur in te voeren. Een project dat begint met het opstellen van eisen en wensen, op basis daarvan een leverancier selecteert, een proof-of-concept met de technologie uitvoert om te bewijzen dat de goede richting gekozen is, vervolgens een pilot uitvoert om te bewijzen dat het ook in de praktijk gebracht kan worden en dan de lessen trekt voor vervolgprojecten. Een project dat de fundamenten legt voor de nieuwe architectuur. Zou je niet bij uitstek in zo'n innovatief project een prominente inbreng van architecten verwachten? Zou je dan werkelijk een project, dat een nieuwe architectuur als de belangrijkste deliverable heeft, willen uitvoeren onder het label «Ontwikkelen zonder Architectuur»?

De architectuuragenda

Ontwikkelen onder architectuur is een balanceeract. Er zijn doorgaans een heleboel stakeholders bij een ontwikkeling betrokken. Niet zelden hebben deze stakeholders op onderdelen tegenstrijdige belangen. Als architect moet je daarvoor gevoelig zijn en je moet in staat zijn om tussen dergelijke klippen door te laveren. In de praktijk werkt het vaak erg goed om de discussie over het toepassen van principes en standaarden tegelijkertijd te voeren met de discussie over de eisen en wensen van de stakeholders in een scenario workshop. In zo'n workshop worden de voor- en nadelen van de verschillende oplossingsscenario's op een rijtje gezet. Het gaat dan om realistische oplossingsscenario's die door de betrokken architect zorgvuldig zijn gekozen. Zulke oplossingsscenario's kunnen in principe het hele kleurenspectrum tussen wit – geheel conform de geldende architectuur – en zwart – geheel afwijkend van de geldende architectuur – afdekken. Een dergelijke integrale belangenafweging aan de hand van concrete scenario's werkt vaak veel effectiever dan een geisoleerde discussie over het honoreren van een specifiek requirement, principe of standaard.

Als enterprise architect zou je na moeten denken over een formele procedure voor het accepteren van afwijkingen van de geldende principes en standaarden. Dan houd je tenminste grip op de projecten. Het is uiteraard zaak dat beslissingen over het al of niet toestaan van uitzonderingen op het juiste niveau worden genomen. Je kunt je daarvoor eens laten inspireren door de vrijstellings­procedure die bij de regelgeving in bestemmingsplannen gebruikelijk is. Het meest bekend is de zogenaamde artikel-19 procedure, die het afhandelen van aanvragen voor vrijstellingen regelt. Minder bekend is de artikel-17 procedure, die voor tijdelijke vrijstellingen gebruikt kan worden. Denk in elk geval ook na over de rol die een orgaan als de architectuurraad bij het al dan niet verlenen van vrijstellingen zou kunnen spelen.

«Ontwikkelen zonder Architectuur» is onmiskenbaar een flauwekulbegrip. Als je «Ontwikkelen onder Architectuur» op een professionele manier praktiseert, dan is «Ontwikkelen zonder Architectuur» volstrekt nutteloos en overbodig. Het wordt de hoogste tijd dat we als architecten stoppen met ons vakgebied te diskwalificeren met dit soort verwarrende begrippen. Wij staan er immers voor om in het complexe krachtenveld van alle stakeholders, evenwichtige ontwerpkeuzes maken die rekening houden met het hele spektrum aan belangen. De enterprise architectuur is best belangrijk, maar als het puntje bij paaltje komt, dan staat het belang van de business toch voorop. Een enterprise architect moet sowieso oppassen voor het stigma van de principeneuker. Het onverzettelijk vasthouden aan principes schiet uiteindelijk altijd zijn doel voorbij. Het is veel effectiever om constructief mee te werken aan just-enough en just-in-time architectuur. Dat is overigens ook veel uitdagender. Er zijn immers nog zoveel andere kleuren behalve zwart en wit.

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

Risico’s op het spoor

De kwestie

Arme, arme NS. Na de Betuwelijn en de HSL-zuid is er weer een mega-project dat dreigt te ontsporen. Dit keer gaat het om de OV-Chipcard. Wederom is het project bijna afgerond en komen er te elfder ure ernstige gebreken aan het licht. En opnieuw heeft het te maken met de beveiliging. Is hier sprake van een patroon?

Het is even amateuristisch als schrijnend dat om te zien dat Tans Link Systems, de projectontwikkelaar van de OV-Chipcard, met sussende woorden probeert om de gekozen Mifare RFID chip nog voor de schier onafwendbare afgang te behoeden.

“Suggesties dat de OV-chipkaart hiermee fraudegevoelig is zijn onjuist. Er is geen enkele aanleiding om de huidige kaarten in de markt te vervangen en de uitrol in Nederland te vertragen.”

Nee, nee. Deskundigen van naam en faam kunnen beweren wat zij willen, dat zijn slechts “suggesties”. Onze kaart is gewoon veilig en daarmee basta. Geen paniek! Wij zeggen toch dat-ie veilig is? Vertrouwt u ons maar!

Helaas voor Trans Link Systems, ook zij zullen de onafwendbare les in nederigheid gaan leren. Let maar op. En dan is er weer een OV-project waarin al honderden miljoenen zijn geïnvesteerd dat voorlopig niet in gebruik genomen wordt. Na de miljardenaffaires rondom braakliggend nieuw spoor, opnieuw een aderlating.

Bij een normaal bedrijf zou bij zo’n opeenstapeling van financiële rampen de continuïteit in gevaar komen. Als de balans het al aan zou kunnen, dan is het imago wel dusdanig geschonden dat een zelfstandige toekomst erg lastig wordt. Er zouden ook zeker koppen zijn gerold. Maar zou dat ook betekenen dat zo’n bedrijf wel effectieve voorzorgsmaatregelen had genomen?

Het valt niet te ontkennen dat het makkelijk is om achteraf problemen te voorspellen. Het is ook waar dat de NS dit soort dingen bepaald niet in z’n eentje kan beslissen, maar afhankelijk is van het complexe krachtenveld waarin de OV-partners en de politiek hun invloed doen gelden. Maar er valt toch ook niet aan de indruk te ontkomen dat de risico’s in alle drie deze projecten niet effectief gemanaged zijn. We weten natuurlijk als buitenstaanders niet precies of de risico’s die zich nu manifesteren vooraf op het juiste niveau onderkend zijn of niet. Zo niet, dan heeft de risico analyse alvast ernstig tekort geschoten. De “beslissers” zijn dan niet goed of niet volledig geïnformeerd en kunnen zich afvragen wat zij in de toekomst anders zouden moeten doen om wel tijdig de juiste informatie onder ogen te krijgen.

Aan de andere kant, als de informatie wel op het juiste moment op de juiste tafel lag, zou er dan ook iets mee gedaan zijn? Zijn er passende maatregelen bedacht om de onderkende risico’s te beheersen? Het heeft er alle schijn van dat dit niet het geval is geweest. Ga maar na. De HSL-zuid ligt stil omdat er gekozen is voor een nieuw beveiligingssysteem.

“Het is zo slecht gesteld met het ERTMS-beveiligingssysteem voor de hsl-zuid dat NS Hispeed de lijn tussen Amsterdam en de Belgische grens voorlopig niet in gebruik neemt. ‘De resultaten van de testen in Frankrijk zijn dramatisch slecht’, zegt commercieel directeur Jan-Willem Siebers in NRC Handelsblad. Het spoorwegbedrijf vertrouwt de nieuwe computergestuurde technologie onvoldoende en omdat de regering heeft afgezien van een back-upsysteem, rijden de treinen tot nader order over oud spoor en op conventionele snelheid.”

De lijn is in april 2007 opgeleverd, en blijft nu naar verwachting tot 2009 ongebruikt liggen. Een “back-upsysteem” had deze problemen kunnen voorkomen. Als architect denk ik dan: zou je bij de toepassing van nieuwe, onbewezen, maar cruciale beveiligingstechnologie niet sowieso een back-upsysteem willen installeren? Wat als er straks echt een ramp gebeurt omdat het nieuwe systeem een bugje heeft? Zijn ze in andere Europese landen net zo optimistisch? Ik voorspel alvast een parlementaire enquête.

De Betuwelijn rijdt ook nog niet. Volgens een brief van de minister uit begin 2007 duurt het nog minstens tot 1 juli 2008 totdat de problemen met de nieuwe beveiliging zijn opgelost. Volgens een bericht van 1 augustus 2007 kampt

“De anderhalve maand geleden geopende Betuwelijn […] opnieuw met problemen. De afgelopen twee weken hebben er geen commerciële goederentreinen meer gereden vanwege een te hoog aantal storingen met het veiligheidssysteem European Train Control System (ETCS).”

ETCS blijkt bij nadere bestudering onderdeel van hetzelfde Europese beveiligingssysteem als ERTMS. De eerste is onderdeel van de trein, de tweede van het baanvak. Ik concludeer voorzichtig dat ook de Betuwelijn zonder back-upsysteem is uitgevoerd. Nou rijdt de trein niet zo hard door de Betuwe als een HSL, maar aan de andere kant, hij rijdt wel met gevaarlijke stoffen. Wat zou zo’n back-upsysteem eigenlijk kosten?

Terug naar de OV-Chipcard. Een chipknip, maar dan contactloos te gebruiken. Je hebt in een flits betaald. Men heeft gekozen voor het toepassen van bewezen chiptechnologie. Hoewel, in een wereld waarin de rekenkracht iedere anderhalf jaar verdubbelt, mag je tien jaar oud misschien best ‘op leeftijd’ noemen. En in de wereld van de cryptografie is tien jaar oud misschien wel hopeloos verouderd. Het is immers slechts een kwestie van tijd voordat beveiliging wordt gekraakt. Het is vanuit het oogpunt van beveiliging verstandig om tijdig over te stappen op een nieuwere technologie. Je mag hopen dat ook Trans Link dit wist dat de levensduur van de Mifare op z’n einde loopt en de migratie naar een betere chip in het geheim al aan het voorbereiden is. In dat geval hoeft die overgang nu misschien niet zo erg veel extra tijd te kosten.

Er waren in alle drie gevallen voor de hand liggende risico-beheersende maatregelen voor handen. Die maatregelen hadden natuurlijk wel extra geld gekost. Ze waren dat achteraf wel waard geweest . Maar ja… het gaat meestal om de vraag: Hoeveel is veiligheid je vooraf waard?

Wat te doen?

Hoe kijk je als architect tegen dit soort vraagstukken aan? Vertrouw je ooit op stoere uitlatingen die beweren dat met de beveiliging geen risico’s gemoeid zijn?

Uit eigen ervaring weet ik dat beveiligingsrisico’s regelmatig onderschat worden. Er is vaak een enorm vertrouwen in het technisch vernuft van specialisten. Misschien is er bij sommigen ook wel een sterke weerzin om zichzelf in de netelige materie te verdiepen. Liefst ‘managen’ ze het buiten de scope van het project. “Kunnen we er niet beter een apart project van maken?” “Dan kunnen wij ons tenminste op de hoofdzaken richten.” Op zo’n moment wordt het tijd om op je tellen te gaan passen.

Als architect kun je gewoon niet om risico's heen. Verdiep je daarom altijd in het risicoperspectief. Het risico van het toepassen van een nieuwe technologie kun je kwalitatief en kwantitatief afwegen tegen de opbrengsten. Het risico van het toepassen van een verouderde technologie kun je afwegen tegen de besparingen. Risico’s kun je beheersen door maatregelen te nemen. Maatregelen kosten extra geld, als ware het een verzekeringspremie, en introduceren soms nieuwe risico’s. Het gaat uiteindelijk om de balans. En die balans mag je meenemen bij het maken van de fundamentele ontwerpkeuzes. Dan zul je zien dat je in de praktijk vaker gaat kiezen voor een minder riskant scenario.

Moet je als architect zelf zo’n risico analyse uitvoeren? Een diepgravende risico-analyse uitvoeren is al gauw veel en gespecialiseerd werk. Daar kun je dus het best een specialist voor inhuren. Een architect zal zelf de regie in handen willen nemen, bijvoorbeeld door de verschillende risicoscenario’s op te stellen, door de resultaten vanuit het perspectief van de opdrachtgever te interpreteren, en door uiteindelijk een goed onderbouwde aanbeveling te doen van het voorkeursscenario.

Dan blijft er nog één kwestie over. Stel dat je als architect de faalkans van een project zo hoog inschat dat wat jou betreft absoluut tegenmaatregelen geboden zijn, maar je kunt je opdrachtgever er niet van overtuigen daarvoor geld vrij te maken. Hij zegt heel stellig: “Ik neem dat risico wel”. Wat doe je dan?

Als je verantwoordelijkheid wilt claimen voor het succes, dan moet je ook verantwoordelijk durven zijn voor het falen. “Ik raad het af, maar het is jouw verantwoordelijkheid”, zou een zwaktebod zijn. Jij bent tenslotte de professional. Jouw reputatie staat op het spel… Ik voel alweer een nuchtere risicoanalyse aankomen. Misschien moet je díe maar eens wél zelf uitvoeren…

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

SOA is een modegril

De weg naar een service georiënteerde architectuur ligt bezaaid met wrakken. Tal van organisaties hebben SOA-initiatieven zien mislukken, of vroegtijdig “geherprioriteerd”. En wat is er nou eigenlijk zo nieuw onder de zon? Services zijn toch ziet wezenlijk anders dan wat eerder componenten werd genoemd in “component based development?” Je zult zien, over een paar jaar dan hoor je niets meer over SOA. Dan heet het al lang SOB of SOZ. Zelfs steeds meer architecten zeggen jeuk te krijgen van de term SOA (no pun intended). Dus kunnen we onze tijd nu maar beter aan iets nuttigers besteden.

Flauwekul!

Iedereen die zegt dat SOA een hype is die wel weer overwaait, heeft niet echt begrepen waar SOA in essentie om gaat. SOA gaat namelijk om ontzuiling. Om het bestrijden van de aderverkalking die zoveel organisaties in zijn verstarrende greep houdt. SOA draait om het moderniseren van bedrijfsmodellen. SOA draait om flexibel kunnen meebewegen met een organisatie die niet langer meer in staat is om jaren vooruit te voorspellen welke kant de ontwikkelingen op zullen gaan. SOA is Serving your Organization with Agility.

Maar SOA was toch niets nieuws?

Dat is grotendeels waar. De aloude AMRO bank had al ruim voor de fusie met ABN een centrale contacten- en contractendatabase die je tegenwoordig zonder blikken of blozen een “customer relationship service” zou noemen. Zij waren erin geslaagd om die functionaliteit uit alle achterliggende systemen te halen en op een centrale plek te implementeren. Dat creëert overzicht en biedt allerlei mogelijkheden voor strategisch verkopen van diensten. Zij kregen dat voor elkaar op een klassiek mainframe platform, zelfs lang voordat het begrip EAI was uitgevonden. Voor ABNAMRO was dit naar verluidt een belangrijke reden om na de fusie voor de AMRO backofficesystemen te kiezen.

Van UBS is bekend dat zij heel ver zijn gekomen met het ontwikkelen van enterprise services op hun CORBA platform. En er zijn ongetwijfeld vele andere voorbeelden te noemen. Zo bezien zijn moderne hulpmiddelen als ESB en webservices helemaal niet voorwaardelijk om de SOA ontwerpprincipes toe te passen. Ze maken het hoogstens wat makkelijker.

In het recente verleden zijn er al eerder aanvallen gedaan op de traditionele, verzuilde manier van werken, bijvoorbeeld onder de koppen

• Business Process Redesign
• Business Process Innovation
• Customer Relationship Management
• Multi-Channel Management

Dat dit niet 1-2-3 succesvol is, valt best te begrijpen. Generaties bedrijfskundigen zijn opgevoed in de school van Porter. Een waardeketen bestaat uit een serie winst-creërende eenheden. Iedere schakel in de keten heeft een aantal kernfuncties, met name inkomende en uitgaande logistiek, productie, marketing & verkoop en nazorg. Hieruit zijn de horizontale silo’s in organisaties ontstaan. De door Porter benoemde ondersteunende functies, bijvoorbeeld HRM, ICT, Inkoop, Juridische zaken en Boekhouding, zijn traditioneel buiten de silo’s met kernsystemen gehouden en in de verticale systemen terecht gekomen. In die bedrijfsfuncties zit, volgens het gedachtegoed van Porter, het synergiepotentieel voor organisaties met meerdere winst-creërende eenheden. Logischerwijs zijn die dus doorgaans op enterprise niveau georganiseerd. De dominantie van dit referentiemodel verklaart waarom het zoveel makkelijker is om in een organisatie een centraal HRM systeem in te voeren, dan een centraal CRM systeem.

De architectuuragenda

Het is een fascinerende tijd om als enterprise architect te werken. De vraagkant is volop in beweging met innovatieve business modellen als drijvende kracht. Netwerken nemen de plaats in ketens, dynamische landschappen komen in plaats van starre zuilenstelsels. De zakelijke belofte van het internet begint eindelijk tot wasdom te komen. “Blown to Bits” wordt alsnog realiteit.

Tegelijkertijd is de technologie enorm in beweging. Je ziet dat het internet nu echt breed geaccepteerd wordt als volwassen distributiekanaal, met “Web 2.0” als drijvende kracht. Daar heb je te maken met een golf aan nieuwe technieken en ontwikkelingen. Er komt steeds meer interactiviteit tussen een aanbieder en een afnemer, maar ook tussen de afnemers onderling. Hoe kun je dat in goede banen leiden?

Business georiënteerde hulpmiddelen als Business Rules Engines en Business Process Management Systemen, maar ook technologieën als ESB en AJAX zullen daarbij een rol spelen. Het is immers ruimschoots aangetoond dat business analisten in staat zijn om met deze hulpmiddelen de dynamiek in de business op eigen kracht te vertalen naar gewijzigde bedrijfsregels en procesmodellen. De techniek zorgt er dan voor dat die wijzigingen zonder tussenkomst van hard-core IT-ers doorgevoerd worden in de systemen.

In de praktijk valt het echter nog niet mee om deze technieken goed toe te passen; zeker niet in onderlinge samenhang – wat uiteindelijk de kracht van een SOA is. Het is makkelijk gezegd om de proceslogica te isoleren, de integratielogica te isoleren en de beslislogica te isoleren, om uiteindelijk de klassieke kernsystemen te reduceren tot een stabiel, betrouwbaar maar dom register. Maar welke logica beschouw je precies als proceslogica, en welke als besluitvorming? Waar houdt proceslogica op, en begint integratielogica? Welke kerngegevens horen in een register, en welke feiten kun je beter in een business rules engine vastleggen? Wie mag eigenlijk op welk moment beslissen over het doorvoeren van welk soort wijzigingen? En hoe kun je in zo’n gedistribueerde wereld toch robuuste compliancy waarborgen inbouwen? Stuk voor stuk lastige vraagstukken. Maar zo lastig dat je ze maar beter aan een opvolger kunt overlaten?

De omslag in het denken over organisaties is gaande. Er is nog geen nieuw, dominant paradigma ontstaan. Dat zal ook nog wel 1 of 2 managementgeneraties duren. Het zou mij niet verbazen als er nooit meer zo’n breed geaccepteerd model als dat van Porter zou ontstaan. Het beste dat je als enterprise architect op dit moment kunt doen is ervaring opdoen met ontzuilen, al was het maar om te voorkomen dat je zelf onderdeel wordt van een legacy probleem. Want als de markt vandaag de dag ergens behoefte aan heeft, dan is het aan enterprise architecten die in staat zijn om de complexiteit te ontrafelen die nodig is om ontzuiling te realiseren.

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

Falende systemen

De Kwestie

Er zijn systemen die fundamenteel fout zijn. Neem nou het verkeer. Het groeit maar door en door. Iedere ochtend moeten er miljoenen medewerkers naar hun werkplek, iedere avond gaan ze weer terug naar huis. Met de steeds toenemende files op de weg en vertragingen op het spoor als schier onvermijdelijk gevolg. Een erkend ’wicked problem’^*.

Er zijn al heel veel mensen die nagedacht hebben over een oplossing van deze problematiek. Meer asfalt, of juist meer spoor. Carpoolstroken, rekeningrijden, beprijzen, spreiden, opzwaaien. Alle trucs wordt ingezet om het probleem maar kleiner te maken. Zodat de files niet met 10-20% per jaar groeien, maar slechts met 5-10%. Maar dat is nog altijd groei! En wie wordt daar nou echt blij van? Dan duurt het misschien nog een paar jaar extra voordat alles tot stilstand komt en de wal het schip gaat keren. Dat is toch geen reële oplossing?

Ja maar, hoor ik beweren, er wordt gewerkt aan intelligente auto’s, die op hele korte afstand van elkaar kunnen rijden, en die toch geen aanrijdingen veroorzaken omdat ze altijd op tijd afremmen om een botsing met een voorganger te vermijden. Cool! Dan gaat de wegcapaciteit met wel 20% omhoog. Dat is te zeggen, zodra alle auto’s zo’n systeem aan boord hebben. Maar dat gaat nog wel 20 jaar duren. Dus, hoe je het ook wendt of keert, het blijft voor de afzienbare termijn gerommel in de marge. En over 20 jaar, dan zul je zien dat die 20% extra capaciteit al lang niet meer voldoende is.

Soms moet je als architect het systeem zelf ter discussie durven te stellen om een oplossing te kunnen bieden. Ja dûh, da’s makkelijk gezegd. Maar er zijn niet voor niets al zoveel verschillende initiatieven in zoveel verschillende landen ondernomen om dit probleem te tackelen. Hoe bedoel je, het systeem veranderen?

Stel eens dat het zou kunnen. Stel dat je zou stoppen met de medewerkers naar hun werk te brengen en zou beginnen met het werk naar de medewerkers te brengen. Stel dat je het systeem als het ware op z’n kop zou zetten. Nee, niet thuiswerken, daar gelooft bijna niemand meer in. Zodra je huis je werkplek wordt, dan ben je nooit meer echt thuis. En trouwens, de meeste medewerkers hebben gewoon behoefte aan hun zakelijke sociale contacten. Even een praatje bij het koffieapparaat schept een band met het bedrijf. En die kun je niet vervangen door email. Nee, het is om allerlei redenen goed om werk en privé te scheiden. Goed voor de werkgever en zeker ook voor de werknemer. Maar zijn er dan geen fundamenteel andere oplossingen denkbaar?

Neem nou een bedrijf als Albert Heijn. Het bedrijf heeft een stuk of 750 vestigingen, mooi gespreid over heel Nederland. Toch moeten meer dan duizend medewerkers iedere dag naar Zaandam afreizen om daar op het hoofdkantoor aldaar achter een computer hun meerendeels administratieve taken uit te voeren. Stel nou dat je in ieder filiaal een kantoor­ruimte zou inrichten. Een ruimte met faciliteiten om samen te werken met collega’s die in andere filialen soortgelijk werk doen. Als we op internet een virtueel 2^nd life kunnen bouwen, met alles erop en eraan, waarom zouden we dan geen virtueel hoofdkantoor kunnen bouwen? Serieus, waarom zou het niet kunnen? Natuurlijk, er zal nog van alles ontwikkeld moeten worden, maar dan werken we in elk geval aan echte oplossingen. En dat is een dankbare taak voor architecten in de IT, niet waar? En dan gaan we tenminste eindelijk de goede kant op, in plaats van minder snel de verkeerde kant op.

Toegegeven, er zijn best nadelen aan een gedistribueerd kantoor. Een team dat moet samenwerken moet elkaar van tijd tot tijd in de ogen kunnen kijken. Aan de andere kant, medewerkers van een hoofdkantoor gaan veel beter functioneren als zij dicht bij de praktijk staan. Zou het niet juist heel productief kunnen zijn als zij in de koffiepauze direct met de gevolgen van hun werk geconfronteerd werden? Zou de sociale controle niet veel beter werken, als medewerkers van een hoofdkantoor dagelijks in direct contact zouden staan met de filialen waar de omzet tenslotte vandaan moet komen? Zou een dergelijk contact met de werkelijkheid niet tot hele nieuwe inzichten kunnen leiden?

En dan nog iets. Wat is er nou mooier dan in je eigen wijk kunnen werken. Dan krijg je een optimale mix tussen sociale en zakelijke contacten. Dat brengt de zakelijke contacten dichter bij huis. Natuurlijk werkt dat beter. Afstand werkt vervreemdend. Precies daarom willen we teams zo graag bij elkaar brengen. Maar dan vergeten we dat de afstand tussen de mensen in de teams en de mensen waarvoor zij werken – hetzij collega’s, hetzij klanten, hetzij partners, hetzij leveranciers – in beginsel net zo vervreemdend werkt. En de vervreemding binnen het team zou met de moderne technische hulpmiddelen wel eens makkelijker op te lossen kunnen zijn dan al die externe vervreemding. En dat terwijl de externe vervreemding waarschijnlijk veel schadelijker is voor het bedrijf.

Trouwens, als je in je eigen wijk kunt werken, dan kun je je privé leven ook veel beter met je werk combineren. Als je dan eens moet overwerken, dan kunnen je kinderen even naar kantoor komen lopen of fietsen. En daar kun je makkelijk een speel- of huiswerkhoek organiseren. Want als afstanden wegvallen, ontstaan mogelijkheden. En zo krijgt Albert Heijn toegang tot een potentieel aan medewerkers dat nu nog onbereikbaar is. Van talent uit Venlo, Goes of Meppel kan je echt niet verwachten dat ze dagelijks naar Zaandam komen. En dat terwijl Albert Heijn wel een vestiging in de buurt heeft. Is dat geen verspilling van talent?

En wat geldt voor Albert Heijn, geldt net zo goed voor AbnAmro, voor UWV, voor Randstad, voor de NS en voor het CWI, om er maar een paar te noemen. Trouwens, waarom zou de overheid zelf niet het goede voorbeeld geven en kantoor gaan houden in elk gemeentehuis in Nederland? Dan kan iedere rijksambtenaar voortaan in zijn eigen gemeente werken. Stel je voor, dat honderdduizenden mensen extra op fietsafstand van hun werkplek zouden wonen. Wat zou dát voor impact hebben op het verkeersprobleem? Toch zou dat best kunnen. Als je het maar goed organiseert.

Maar dan moeten we wel stoppen met het bouwen van al die megalomane kantoren aan de Amsterdamse zuidas. Want zo’n centralistisch systeem is fundamenteel fout en de problemen die het veroorzaakt zijn fundamenteel onoplosbaar. Pogingen om dergelijke systeemfouten op te lossen zijn zonde van de energie. Alleen een gedistribueerd systeem biedt hoop.

Wat te doen?

Als architect moet je af en toe durven om een falende systeem fundamenteel ter discussie te stellen om een oplossing te bieden voor de echte noden van je opdrachtgever. Alleen met een recalcitrante aanpak kunnen we de echte doorbraken verwachten. Iedere industrie heeft zijn falende systeem. Weiger mee te werken aan een kansloze oplossingen. Dat is niet alleen zonde van je tijd, maar uiteindelijk ook fnuikend voor je eigen reputatie. Durf ervoor te pleiten om zo’n systeem op z’n kop te zetten. Neem nou eens rustig de tijd om een fundamentele oplossing te bedenken. En rust vervolgens niet voordat je iedereen in je omgeving overtuigd hebt van de noodzaak van die oplossing. Dan zul je zien dat baanbrekende veranderingen echt mogelijk zijn. Je bent tenslotte niet voor niets een architect?

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

^* Wicked problems laten zich het makkelijkst karakteriseren als complexe problemen waarbij iedere oplossing de oorspronkelijke probleemsituatie op een onvoorspelbare manier verandert.