Page 1

hIC 19

Cloud computing, of toch maar niet?

Architecten en beheerders

B

erend-Jan van Maanen: “CIO’s en andere IT-verantwoordelijken zien zichzelf anno 2009 voor complexe uitdagingen gesteld. Op HIC 2009 vinden zij kennis van experts en informatie op maat die hen kan helpen om te bereiken wat zij willen bereiken, ook in een neergaande economie en in tijden van teruglopende budgetten.”

trekken zelden gezamenlijk op. Maar is dat wel terecht? Want uiteindelijk krijgt de beheerder de infrastructuur die een architect heeft ontworpen onder zijn hoede.

Kennis van experts en informatie op maat

Samenwerken lijkt dus voor de hand te liggen. Hoe zou zo’n samenwerking eruit kunnen zien? Tekst: Martin van den Berg • Beeld: iStock

Architectuur en beheer

Ir. Berend-Jan van Maanen is country manager Benelux van Interoute. In zijn lezing Cloud computing: wat doe ik als bedrijf in de cloud? behandelt Van Maanen de afwegingen waar cloud computing bedrijven opdringt. “Momenteel zijn Wide Area Netwerken beschikbaar over meer media en tegen een lagere prijs dan ooit tevoren; en is kennis van ICT-afdelingen een schaars goed, dat ingezet moet worden voor de corebusiness van bedrijven. Daardoor heroverwegen veel grootzakelijke bedrijven wat ze zelf nog moeten doen, en wat ze uitbesteden, en tevens wat de beste plaats hiervoor is.” Van Maanen wil zijn toehoorders handvatten geven om kritisch in de eigen organisatie te bekijken welke intelligentie het beste binnen het LAN van een bedrijf ondergebracht kan worden, en welke zich leent voor plaatsing in ‘in the cloud’.

Van lotgenoten naar bondgenoten

A

rchitecten en beheerders spelen beiden een belangrijke rol in de levenscyclus van IT-componenten zoals systemen, applicaties, services en software en hardware. Deze levenscyclus start met identificatie en loopt via selectie, ontwerp, ontwikkeling, ingebruikname en gebruik tot uitfasering en verwijdering. Architecten bedenken de principes en modellen voor de informatievoorziening en zetten daarmee de kaders neer voor alle toekomstige ITcomponenten. Beheerders hebben tot taak de eenmaal in gebruik genomen IT-componenten te laten blijven voldoen aan de eisen die daar aan zijn gesteld. Architecten zitten dus aan het begin van de levenscyclus en beheerders aan het einde. Om de cyclus sluitend te maken, zou het heel logisch zijn als bij het ontwerp van toekomstige IT-componenten wordt geleerd van de ervaringen met in gebruik zijnde componenten. Tekortkomingen Architecten zouden dus niet om beheerders heen kunnen als zij bezig zijn een nieuwe informatievoorziening te ontwerpen. Sterker nog, zij zouden beheerders als eerste moeten raadplegen. Beheerders weten precies wat de tekortkomingen zijn van de IT-componenten die zij beheren en kennen de eisen die leven bij gebruikers (beheerders hebben verreweg het meeste contact met gebruikers). Daarbij komt dat de fase gebruik verreweg het grootste deel van de levenscyclus bestrijkt en in deze fase het merendeel van het geld wordt uitgegeven aan een IT-component. Van de totale kosten van een IT-component nemen de aanschaf/bouwkosten ongeveer 20 procent en de beheerkosten ongeveer 80 procent voor hun rekening. Meer dan genoeg redenen waarom architecten beheerders serieus moeten nemen, maar ook dat beheerders zich moeten laten gelden tegenover architecten. Beheerders klagen vaak over de enorme diversiteit aan IT-componenten die ze in beheer moeten nemen en soms zelf over de schutting gegooid krijgen. Het zijn de architecten die hun hierbij kunnen helpen. Niet alleen door de diversiteit terug te dringen, maar ook door de beheerders in kennis te stellen van toekomstige IT-compo-

nenten. Op die manier kunnen beheerders zich tijdig voorbereiden. Het lijkt toch evident dat architecten en beheerders elkaars bondgenoten zijn? Toch lijkt het wel alsof er Chinese muren tussen architecten en beheerders staan. Ik zie en hoor architecten zelden praten met beheerders. Beheerders worden zelden door architecten betrokken bij de start van de levenscyclus. Omgekeerd stappen beheerders zelden naar architecten om hun ongenoegen of tevredenheid met IT-componenten te uiten. Wat wel gebeurt, is dat zowel architecten als beheerders klagen over projecten.

Denken in levenscyclus van IT-componenten is sleutel tot succes Architecten klagen dat projecten zich weinig gelegen laten liggen aan de architectuur. Beheerders klagen dat ze IT-componenten over de schutting gegooid krijgen vanuit projecten. Zo beschouwd zijn ze meer lotgenoten dan bondgenoten! Levenscyclusdenken Waarom trekken architecten en beheerders zo weinig met elkaar op? Het kan te maken hebben met de natuurlijke volgorde in de levenscyclus. Tussen architecten en beheerders zitten namelijk allerlei andere disciplines zoals projectmanagers, analisten, ontwerpers en ontwikkelaars. Zo hebben architecten wel veel contact met projectmanagers en praten beheerders vaak met ontwikkelaars. Het kan ook te maken hebben met het gebrek aan levenscyclusdenken. De ITindustrie is enorm gefocust op het creëren van IT-componenten. Er is relatief weinig aandacht voor het opruimen van IT-componenten. Een andere mogelijke reden is dat beheerders vaak zijn verknocht aan de IT-componenten die ze beheren en weinig aandrang voelen om mee te denken over vervanging van die IT-componenten.

Tot slot is het niet ondenkbaar dat er een soort van statuskloof is tussen architecten en beheerders. Disciplines in het begin van de levenscyclus ontlenen veel status aan het feit dat ze meedenken over strategie en investeringen. Disciplines aan het einde van de levenscyclus hoeven er alleen maar voor te zorgen dat de boel draait en staan dientengevolge een stuk lager in de pikorde. IT-governance Waarschijnlijk zijn er nog meer redenen. Goed om ze te kennen en te begrijpen, maar vooral ook om op te zoek te gaan naar redenen waarom samenwerking zo waardevol is. Wat mij betreft, is het levenscyclusdenken een belangrijke sleutel voor succes. Als het besef er is dat IT-componenten een levenscyclus hebben, dan kan het niet anders of architecten en beheerders moeten met elkaar samenwerken. De toenemende aandacht voor het vakgebied IT-governance helpt hierbij aanzienlijk. Maar los daarvan vind ik dat architecten en beheerders elkaar moeten opzoeken en samen aan de slag moeten gaan. Wat enorm helpt, is dat er een groot gemeenschappelijk belang is, namelijk een ordentelijk landschap van IT-componenten dat niet verstoord mag worden door projecten die maar hun eigen gang gaan. Hoe zouden architecten en beheerders met elkaar kunnen samenwerken? Heel concreet door aan de ene kant beheerders een IT-component pas in beheer te laten nemen wanneer zij gecontroleerd of getest hebben dat die IT-component voldoet aan de architectuur. Aan de andere kant door architecten regelmatig met beheerders te laten overleggen over de status van ITcomponenten en bovendien de eisen vanuit Beheer mee te nemen bij het ontwerpen van de Architectuur. Kortom, genoeg redenen en mogelijkheden voor architecten en beheerders om als bondgenoten door het leven te gaan in plaats van als lotgenoten. Begin eens met een praatje bij de koffieautomaat!

Mogelijkheden van cloud computing

H

arold Nelissen: “ICT en ICTinfrastructuur worden steeds dynamischer en vluchtiger. Diensten kunnen per maand of per gebruiker worden afgenomen en zijn daarmee zeer flexibel. Daarnaast moet ICT echter ook steeds controleerbaarder zijn, om compliance- en securityredenen. Deze paradox is een uitstekende reden om naar HIC 2009 te gaan, omdat daar kennis en middelen worden geboden die je leren het dynamische en het controleerbare te combineren, ook zonder eigen middelen.”

Infrastructuur steeds dynamischer en vluchtiger

Harold Nelissen is global practise manager bij Getronics. Nelissen houdt samen met een collega – enterprise architect Henk Simons – een verhandeling over cloud computing voor de corporate market.

Martin van den Berg is ICT-docent bij Pro Education. Hij is werkzaam als servicelinemanager Architectuur bij Sogeti Nederland en is voorzitter van de Afdeling Architectuur van het Ngi. E-mail: martin.vanden.berg@sogeti.nl

13 maart 2009

Ag architectuur en beheer  
Read more
Read more
Similar to
Popular now
Just for you