Bespiegeling
Is het eigenlijk niet merkwaardig dat IT vaak zo amateuristisch met zijn eigen enterprise architectuur omgaat? 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 2de in een reeks bespiegelingen. Deze is op 31 januari 2008 gepubliceerd op ArchITectuur Bedrijven.
Only registered users can write comments.
Please login or register.
|
