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.