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.