special beheerarchitectuur
Beheerarchitectuur heeft nog een lange weg te gaan Onderzoek bij 12 organisaties naar beheren onder architectuur Beheerarchitectuur is een begrip waar elke architect wel een eigen beeld bij heeft. In IT Beheer Magazine nummer 51,82 en dit nummer zijn artikelen over beheerarchitectuur gepubliceerd om dit begrip duidelijker op de landkaart te zetten. Op basis van deze beeldvorming heeft Bart de Best de afgelopen drie maanden een onderzoek bij twaalf Nederlandse organisaties gedaan naar de mate waarin zij beheren onder architectuur. Dit artikel
De doelstelling van het beheerarchitec‑ tuuronderzoek is om inzicht te krijgen of Nederlandse beheerorganisaties beheren onder architectuur en wat daar dan de volwassenheid van is. Hierbij omvat de scope van beheerarchitectuur zowel de beheerorganisatie (ITBM nr. 5) als de pro‑ jectorganisatie (ITBM nr. 8). Het onder‑ zoek is gehouden bij twaalf organisaties uit verschillende branches van verschil‑ lende omvang. In het interview is een uit‑ leg gegeven van het beheerarchitectuurframework. Daarna heeft iedere orga‑ nisatie een beeld geschetst van de wijze waarop zij onder architectuur beheren. Vervolgens is aan de hand van een vra‑ genlijst de volwassenheid bepaald. Het onderzoek duurde gemiddeld vier uur. Dit artikel beschrijft de meetlat die is gebruikt, de resultaten en de antwoor‑ den op een aantal open vragen.
geeft de onderzoeksresultaten.
Bart de Best
De meetlat Het onderzoek is verricht op basis van een vragenlijst. Hierbij is beheerarchitec‑ tuur als een proces beschouwd waarin alle twaalf stappen van het gepubli‑ ceerde beheerarchitectuur-raamwerk tot uitdrukking komen. De vragen zijn ont‑
leend aan het self assessment voor ITILbeheerprocessen van het OGC (UK Office of Government Commerce). Dit assess‑ ment bevat per ITIL-beheerproces en per volwassenheidsniveau een aantal vragen. Deze vragen zijn procesonafhankelijk gemaakt en vervolgens vertaald naar het beheerarchitectuurproces. Op deze manier is een voor de doelgroep her‑ kenbaar assessment verkregen. Ook de opbouw van de volwassenheidsniveaus met als einddoel een alignement van de beheerorganisatie met de business past goed bij het gepubliceerde gedachte‑ goed van beheerarchitectuur. In figuur 1 is de meetlat grafisch weer‑ gegeven. De volgende niveaus zijn hierin onderkend: • Niveau 1: prerequisites. Dit niveau is behaald als aan de minimale randvoorwaarden is voldaan om de beheerorganisatie te (gaan) ondersteunen, zoals het hanteren van beheerarchitectuurprincipes en beheerarchitectuurmodellen. • Niveau 1.5: management intent. Dit subniveau vereist dat er commitment is vanuit het management in de vorm
10 — december 2007
ITB07-10_v3.indd 31
31
12-12-2007 10:34:21
special beheerarchitectuur
•
•
•
•
van een sponsor die beheerarchitec‑ tuur omarmt en het bestaansrecht verdedigt, of overeenkomstige inten‑ ties, die het toepassen en naleven van beheerarchitectuur borgen. Niveau 2: beheerarchitectuur capabilities. Dit niveau vereist dat volledig invulling is gegeven aan beheerarchi‑ tectuur en dat dit wordt toegepast in zowel de projectorganisatie als in de beheerorganisatie. Niveau 2.5: internal integration. Dit subniveau geeft aan of de twaalf stappen van het beheerarchitectuurframework elkaar versterken, zodat de doelen van beheerarchitectuur behaald worden. Alle beheerarchitec‑ tuuractiviteiten moeten gericht zijn op het effectueren van het beleid en het borgen van de gekozen richting in de beheerarchitectuurprincipes en de beheerarchitectuurmodellen, zoals de blauwdruk. Niveau 3: products. Dit niveau vereist dat de producten en diensten van beheerarchitectuur voor de project‑ organisatie en de beheerorganisatie duidelijk zijn gedefinieerd en dat de kwaliteit ervan bewaakt wordt. Niveau 3.5: quality control. Dit sub niveau is gehaald als er een feedbackmechanisme is ingeregeld, waarmee de kwaliteit van de producten en
Management Management information 4 Management intent
1.5
3.5
Beheerarchitectuur capabilities Prerequisites
2 3 2.5 Internal integration 4.5
5
Customer interface
External integration Other Architecture areas
Customer
Figuur 1 De meetlat
diensten van beheerarchitectuur bewaakt worden. Dit kan bijvoorbeeld in de zin van een review van de kwa‑ liteitdoelen ten aanzien van beheer‑ architectuur, zoals het percentage van projecten binnen de vastgestelde scope van de beheerarchitectuur dat actief is bewaakt.
Het scheppen van richtinggevende kaders in de vorm van architectuurprincipes en architectuurmodellen (referentiearchitectuur), om te komen tot een consi‑ stente, toekomstvaste en voor de business bruikbare inrichting van de beheer organisatie in termen van methoden, middelen en mensen. Dit kan worden bereikt door deze af te stemmen op de informatievoorzieningsarchitectuur en het van het bedrijfsbeleid afgeleide ICT-beleid. Deze richtinggevendheid beperkt zich niet tot het vormgeven van de beheer‑ organisatie, maar heeft ook betrekking op de beheerbaarheid van de ICT-pro‑ ducten en ICT-diensten die door projecten worden opgeleverd in het kader van de vastgestelde informatievoorzieningsarchitectuur. Hierbij geldt dat de gehan‑ teerde beheerkaders in samenspraak met de informatievoorzieningsarchitecten worden bepaald.
ITB07-10_v3.indd 32
Products
1
Beheren onder architectuur
32
Quality control
• Niveau 4: management information. Op dit niveau is beheerarchitectuur bestuurbaar gemaakt. Het manage‑ ment heeft een stuurwiel om beheer‑ architectuur in te zetten op de wijze waarop zij een optimale toegevoegde waarde heeft voor de organisatie. • Niveau 4.5: external integration. De vragen op dit subniveau zijn gericht op de externe interfaces en relaties tussen beheerarchitectuur en andere architectuuraspectgebieden, zoals het wederzijds raadplegen bij het opstel‑ len van beleiduitgangspunten. Op dit niveau mag van de ICT-organisatie verwacht worden dat aan het beheren en bouwen onder architectuur volle‑ dig invulling is gegeven en dat ze een harmonieus geheel vormen. • Niveau 5: customer interface. Dit niveau is primair gericht op het con‑ tinu extern reviewen en valideren van beheerarchitectuur om te garanderen dat het optimaal is afgestemd op de behoeften van de klant (businessarchitectuur).
10 — december 2007
12-12-2007 10:34:22
Beheerarchitectuurvolwassenheid 2000
Volwassenheid
2,5
2500 2000
1500
2
1500
1,5 1000
1 0,5
220 3
16
380
56
450 200
14
15
500
Aantal ICT medewerkers
3
40
Aantal medewerkers
Financiën (12)
Financiën (11)
Overheid (10)
Financiën (9)
Overheid (8)
Overheid (7)
Overheid (6)
Industrie (5)
Overheid (4)
Financiën (3)
Zorg (2)
0 Dienstverlening (1)
0
Volwassenheidsniveau
Figuur 2 De volwassenheidscope van de beheerorganisaties
Deze meetlat komt in grote lijnen over‑ een met het IT Architecture Maturity Model (AMM) zoals de Metagroup dit in 1998 heeft gepubliceerd in Enterprise Architecture Strategies, File 16 July 28, 19983. De uitslag In figuur 2 zijn de resultaten van het onderzoek grafisch weergegeven. Per organisatie is zowel de branche, de volwassenheid als het aantal ICT-mede‑ werkers weergegeven. Dit aantal betreft het aantal interne medewerkers dat werkzaam is voor functioneel beheer, applicatiebeheer en technisch beheer als de externe medewerkers die aangestuurd worden. Het aantal medewerkers dat werkzaam is voor uitbestede diensten is dus niet meegenomen. Elke organisatie heeft een uniek nummer toegekend gekregen, zodat hieraan in de tekst kan worden gerefereerd. Uit de grafiek is af te lezen dat de vol‑ wassenheid erg divers is. In ieder geval blijkt meer dan de helft van de organi‑ saties in een bepaalde mate invulling te hebben gegeven aan beheerarchitectuur. Er lijkt geen relatie te zijn tussen het aantal medewerkers en de volwassenheid van beheerarchitectuur. Er kan dus niet
geconcludeerd worden dat beheerarchi‑ tectuur voorbehouden is aan de grotere organisaties. Sterker nog, het bedrijf met drie ICT-medewerkers opteert om beheerarchitectuur op te pakken. Door dit praktisch in te vullen hoeft het niet veel tijd te kosten, maar geeft het wel de benefits van risicobeheersing en profes‑ sionalisering. Wel is het natuurlijk een gegeven dat er bij honderden ICT-medewerkers mak‑ kelijker een FTE gewijd kan worden aan beheerarchitectuur en dat de finan ciële belangen bij grote organisaties in absolute zin groter zullen zijn dan bij kleinere organisaties. Hierdoor zal de business case bij grotere organisaties financieel gezien eenvoudiger zijn op te stellen. Alle bedrijven met meer dan 400 ICT-medewerkers hebben een volwas‑ senheidsniveau van één of hoger. In deze categorie vallen overigens slechts drie van de twaalf organisaties. Uit de antwoorden van de vragenlijst is een aantal vermeldenswaardige patro‑ nen naar voren gekomen. • Zo hebben alleen beheerorganisaties nummer 6 en 12 een beheerarchitect aangesteld. De rest van de organi‑
saties die aan de weg timmeren qua beheerarchitectuur onderkennen alleen een beheerarchitectuurrol. De omvang en volwassenheid hoeven dus geen rol te spelen in de keuzen van functie of rol. Wel is het aannemelijk dat er bij een grotere beheerorganisa‑ tie meer mogelijkheden zijn voor een expliciete beheerarchitectfunctie. • Twee organisaties (nummer 10 en 12) hebben op hoog niveau in de orga‑ nisatie commitment gekregen voor beheerarchitectuur en hebben vanuit beheerarchitectuur invloed op de informatieplanning. Hiermee krijgt beheerarchitectuur een financieel belang, namelijk om te voorkomen dat te veel geld wordt uitgegeven. Wellicht is dit een drijfveer geweest om te komen tot een hoge volwassen‑ heid (1,5 resp. 2,5 op de meetlat). • Verder valt op dat er geen standaard‑ definitie is voor de term architectuur‑ principe. Ook worden er nauwelijks kwaliteiteisen gesteld aan de definitie van een architectuurprincipe. In wezen zijn er twee uitersten te onderkennen, te weten: heel abstract, richtinggevend en tijdloos versus concreet, voorschrij‑ vend en tijdgebonden. Het gepubli‑ ceerde beheerarchitectuur-framework maakt hier wel onderscheid in, omdat de laatstgenoemde vorm feitelijk beheerrequirements en daarom niet richtinggevend zijn. • Architectuurmodellen voor beheer zoals een beheerprocessenblauwdruk of een monitorlagenmodel worden alleen toegepast bij de beheerorga‑ nisatie nummer 12. Zo maakt deze organisatie gebruik van een classifi‑ catiemodel van applicatiebeheerom‑ gevingen (generiek, specifiek, uniek) en gebruikt dit als stuurmiddel om te komen tot het uniformeren van de beheeromgevingen. De aangereikte voorbeelden spraken de andere orga‑ nisaties wel erg aan.
10 — december 2007
ITB07-10_v3.indd 33
33
12-12-2007 10:34:23
special beheerarchitectuur Organisatie Dienstverlening (1)
Omvang 3
Business architect
Informatie architect
Applicatie architect
Infrastructuur architect
Beheer architect
Security architect
Overig
Zorg (2)
16
Financiën (3)
56
Ja
Ja
Ja
Overheid (4)
220
Ja
Ja
Ja
Industrie (5)
380
Ja
Overheid (6)
200
Ja
Ja
Ja
Ja
Overheid (7)
1500
Ja
Ja
Als rol
Ja
Overheid (8)
14
Financiën (9)
15
Ja
Ja
Overheid (10)
40
Ja
Ja
Ja
Als rol
Ja
Financiën (11)
450
Ja
Ja
Ja
Ja
Als rol
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Ja
Financiën (12)
2000
Figuur 3 Architectfuncties per beheerorganisatie
• De vraag naar het toepassen van architectuurraamwerken zoals Togaf, IAF en andere, leidt alleen bij drie organisaties tot een antwoord. Organisatie nummer 10 hanteert DYA en Nora, organisatie nummer 11 hanteert DYA en Novius en organi‑ satie nummer 12 past Novius samen met Tapscott – Caston toe. • Het werkgebied van beheerarchi‑ tectuur blijkt bij grote organisaties verschillend te zijn ingericht. De ene organisatie differentieert de mate waarin beheerarchitectuur wordt toe‑
gepast per dienst. Hierbij is dan geen onderscheid gemaakt tussen de rol van beheerarchitectuur in de projectfase of in de beheerfase (nummer 12). Twee andere organisaties passen beheerar‑ chitectuur voornamelijk toe bij grote projecten (nummer 10 en nummer 11). • De organisaties 5, 10 en 12 bestaan uit onafhankelijk opererende onderdelen. Hierbij heeft beheerarchitectuur van de moederorganisatie (nummer 12) en het kerndepartement (nummer 10) geen of weinig grip op deze ‘satellietorganisaties’. Veelal wordt hierbij het
ambitieniveau van beheerarchitec‑ tuur teruggeschroefd tot alleen afspraken op middleware-niveau. De organisaties hebben ook aange‑ geven welke architectuurrollen en/of functies zij onderkennen. De resulta‑ ten staan in figuur 3 uitgebeeld. Naast het vaststellen van de volwas‑ senheid van beheerarchitectuur bij Nederlandse organisaties is in de inter‑ views ook gevraagd wat de zakelijke rechtvaardiging is van beheerarchi‑ tectuur. Dit is vooral interessant voor
Business cases
Kritieke Succesfactoren
• De beheerorganisatie is effectiever door de inrichting af te stemmen op de te leveren producten en diensten. • Hergebruik maken van oplossingen en vermijden van de lappendekens. • Het beheer van de keten is versnipperd. Beheerarchitectuur brengt alles onder één noemer en maakt de keten bestuurbaar. • Verkorting van geschillen in realisatie-projecten. • We willen dat de ICT-ondersteuning van beheer verbetert. • Cultuuraspecten als loyaliteit houden de boel draaiend. Het niet halen van een bepaalde mate van volwassenheid maakt ons niet geloofwaardig en is een risico voor de bedrijfsvoering van deze organisatie. • Complexiteit reduceren en daardoor de kosten en het aantal fouten dat optreedt. • 20% van de kosten zitten in de ontwikkeling en 80% in beheer. Het verdient de aandacht om de verhouding evenwichtiger te maken en dit niet een 10/90-verhouding te laten worden. • Het levert niet zo veel geldbesparing op, maar voorkomt dat er meer wordt uitgegeven.
• Organisatiebreed commitment, beginnend bij de top. • De beheerarchitect moet een zeker mandaat en power krijgen om stand te houden. • Voldoende invloed hebben op het organisatiestuk (structuur en rollen). • Communicatie, het moet bij de beheerders landen. • De principes moeten overruled kunnen worden; er moeten exceptions mogelijk zijn. • Op een gestructureerde manier initiëren van een project, alleen dan kan beheerarchitectuur voorkomen dat er verkeerde investeringen worden gedaan. • In plaats van een kortetermijnfocus een langetermijnfocus hanteren. • Committeren aan de referentie architectuur, voorkomen dat deze omzeild wordt. • Praktische inhoud. • Inspirerende mensen.
34
ITB07-10_v3.indd 34
10 — december 2007
12-12-2007 10:34:24
de beheerorganisaties die nog niet aan de weg timmeren qua beheerarchitec‑ tuur. Daarnaast is ook gevraagd wat bij het toepassen van beheerarchitectuur de belangrijke factoren zijn waar reke‑ ning mee moet worden gehouden, de zogenoemde Kritieke Succesfactoren. De onderstaande tabel geeft een selectie uit de gegeven antwoorden weer. Niet doen Beheerarchitectuur is nog geen com‑ mon sense bij alle beheerorganisaties in Nederland. Sterker nog, veel beheer‑ organisaties blijken een volwassenheid van nul te scoren. De vraag is dan ook gerechtvaardigd of er ook redenen zijn om juist geen invulling te geven aan beheerarchitectuur. Daarom is aan elke beheerorganisatie de gewetensvraag voorgelegd wat een reden zou kunnen zijn om beheerarchitectuur links te laten liggen. Hierbij werden de volgende argu‑ menten genoemd: • Het proces van taakstelling kan leiden tot een grote verandering van de organisatie waardoor het even niet opportuun is. • Het architectuurdenken heeft niet opgeleverd wat men er in het verle‑ den van verwachtte. • Een architectuur is maar een architec‑ tuur, het resultaat moet een succes‑ volle beheerinrichting zijn, het is maar papier. • Het is niet ons grootste probleem. • Drukte in de operationele werkzaam‑ heden. • De gevoelsmatige rigiditeit die het met zich meebrengt. • Gebrek aan calamiteiten. Omdat het ‘goed’ gaat, is er geen geld voor een structurele aanpak van (potentiële) problemen. Hierbij moet aangetekend worden dat alle geïnterviewden het er unaniem over eens zijn dat er eigenlijk géén geldige redenen te bedenken zijn waarom een organisatie géén invulling zou geven aan beheerarchitectuur. Een veel voor‑ komende reden is de onvolwassenheid
Problemen van onvolwassenheid en brandjes blussen vragen om een bottom‑up aanpak
van de beheerorganisatie en de brandjes die eerst geblust moeten worden. Ook deze argumenten snijden geen hout. Wel moet in deze gevallen rekening worden gehouden met een passende aanpak. Je moet in dat geval bottom-up beginnen met de richting aan te geven om de grootste knelpunten op te lossen, in plaats van top-down een ICT-beleid op te stellen en invulling te geven aan een referentie architectuur. Conclusie Resultaat Meer dan de helft van de onderzochte beheerorganisaties geeft invulling aan de randvoorwaarden om te kunnen beheren onder architectuur. Een derde van de beheerorganisaties krijgt com‑ mitment van het management om invul‑ ling te geven aan beheerarchitectuur. Beheerarchitectuur is dus een onderkend aandachtsgebied. Het wordt zelfs door alle deelnemers gezien als een belang‑ rijk richtinggevend middel, ongeacht de branche en de omvang van de organi‑ satie. Slechts één van de twaalf organi‑ saties heeft echter beheerarchitectuur en de rol van beheerarchitect dusdanig vormgegeven dat deze een bijdrage leve‑ ren aan het effectueren van het beleid en het borgen van de gekozen richting
in de referentiearchitectuur (organisatie nummer 12). Standaardisatie Beheerarchitectuur is als begrip nog niet sterk geprofileerd. Ook is er nog geen sprake van een eenduidig begrippen kader en aanpak. Bruikbaarheid Ondanks dit overwegend positieve resultaat is er bij vijf van twaalf bedrij‑ ven géén invulling gegeven aan enige beheerarchitectuuractiviteiten en twee organisaties zitten nog in de initiatie fase (niveau 1). Dit onderzoek geeft deze organisaties een paar handreikingen te weten: • Probeer zo hoog mogelijk in de orga‑ nisatie commitment te krijgen voor beheerarchitectuur. Het financiële perspectief snijdt hierbij hout. • Probeer het ‘Beheren onder architec‑ tuur’ mee te laten liften op het succes van ‘bouwen onder architectuur’, of sla de handen ineen. • Wellicht dat de selectie aan zakelijke rechtvaardigingen die door de deelne‑ mers zijn benoemd helpen om meer gewicht in de weegschaal te leggen voor beheerarchitectuur. De kritieke succesfactoren zijn in ieder geval de waarschuwingen voor de beren die op de weg kunnen liggen.
Dankwoord De auteur dankt alle organisaties die hun medewerking hebben verleend aan het onderzoek en de vele reviewers van dit artikel.
Drs. Ing. B. de Best RI. E-mail:
[email protected]
Noten/literatuur 1 Beheren onder architectuur 2 Beheerarchitectuur in projecten 3 [META 1998] Enterprise Architecture Strategies, File 16 July 28, 1998
10 — december 2007
ITB07-10_v3.indd 35
35
12-12-2007 10:34:24
