Architectuur: brug tussen ontwikkeling en beheer?

De 52Blog is de corporate blog van Andarr. Het hele jaar door schrijven Andarr collega's blog's over uiteenlopende onderwerpen.

Frans Loth, Andarr Consultant en Architect

Het is een groot voorrecht om als extern consultant/architect bij veel verschillende organisaties in de ICT keuken te mogen kijken. Je wordt betaald om kennis te leveren en vaardigheden in te brengen, en tegelijkertijd leer je bij, want elke situatie bevat toch weer nieuwe elementen. De waarde van de consultant neemt toe naarmate hij of zij meer situaties gezien heeft en er effectieve oplossingen voor gevonden heeft.

Voor een consultancy organisatie met de omvang van Andarr betreffen het meestal organisaties die ICT als ondersteunend middel gebruiken in de primaire processen en functies: dit zijn de ICT USERS.  En in een enkel geval zitten we bij organisaties die ICT als doel (dienst, product) hebben,  b.v. bij telco’s en ontwikkelhuizen: dit zijn de ICT PROVIDERS.
Wat valt er te zeggen over de verschillen tussen de users en de providers?

ICT Users: continu zoektocht naar continuïteit
De ICT users zijn gefocust op continuïteit van de primaire bedrijfsfuncties. Dit kent zijn weerslag op de principes van de ICT afdelingen: die zijn heden ten dage vooral operationeel gericht.  Wat een verschil met eind jaren 80 en begin jaren 90 van de vorige eeuw. Toen lag bij alle bedrijven de focus op ontwikkeling en de opgeleverde systemen – op zich al een prestatie als het zo ver kwam, want ook toen mislukte het grootste deel van ICT projecten – gingen letterlijk over de muur. Vol met fouten. En de ICT beheerders moesten het maar uitzoeken. De ‘awareness’ voor beheer is in die periode sterk gegroeid: de ITILisatie van bedrijven kwam op gang. Volkstammen beheerders kochten de boekjes van Pink Elephant of gingen op cursus. Een CMDB moest er komen en de support werd opgedeeld in de Helpdesk en de 2e / 3e lijn. Nog geen Incident- en Problem management of een fatsoenlijk Change management ingericht? Wat een loser!
Zonder gekheid: ITIL was een goede ontwikkeling, want we weten allemaal dat in de beheer- en exploitatiefase van een informatiesysteem de meeste kosten worden gemaakt. En als ICT niet je primaire bedrijfsproces is, dan moet je je wel op continuïteit organiseren en dat heeft ITIL gestimuleerd. Wel oppassen voor over-geITILiseerd-gedrag !

ICT Providers: spanningsveld tussen ICT development en dienstverlening
De ICT Providers zitten met heel andere problemen. Het “lastige” met ICT is de voortdurende stroom van innovatiemogelijkheden. Hoe pas je deze turbulentie in je organisatie, producten en diensten in? Providers richten meestal een sterke projectorganisatie in en geven veel aandacht aan top-down geleide ontwikkeling. Dit type bedrijf heeft meestal een aantal ICT architecten, al of niet georganiseerd in een architectenbureau, architectureboard, of dergelijke. De taak van een dergelijke groep is meestal een strategisch/tactisch-inhoudelijke aansturing van ontwikkelingen.
Naast deze ontwikkelingsprocessen moeten de diensten netjes door blijven draaien. De winkel is open tijdens de verbouwing. En dat levert een enorm spanningsveld op. Intern tussen afdelingen. Met klanten. Met concurrentie. Met deadlines.  En de gewone diensten moeten netjes blijven draaien.

Is dat een verschil !?!
Euhh, maar met dat probleem worstelt de ICT User toch ook? Ja, natuurlijk. ICT projecten mogen ook bij deze bedrijven de dienstverlening niet verstoren. Echter het vertrekpunt is anders. Bij de Providers is ICT “de reden van bestaan”. En er is daardoor dwingend aandacht voor beheer EN ontwikkeling.

Bij de Users lijkt door de voortdurende ITILisatie de aandacht van ICT afdelingen verschoven naar beheer.  ICT wordt dan wel gezien als enabler van ontwikkeling van nieuwe diensten of producten, maar is niet de bestaansreden van het bedrijf. Ontwikkeling van nieuwe ICT systemen leidt in dit soort situaties vaker wel dan niet een eigen leven en wordt sterk gedreven door de business (dat is een pluspunt!). Maar dicteert daardoor ICT in hoge mate, waardoor – ondanks het fraaie ITIL bouwwerk – ICT nog steeds kampt met onvoorspelbaarheid van de dienstverlening en verkrampte omgang met ontwikkelingsprocessen.

Bij de ICT Users dringt nu grootschalig het besef door dat er “iets” mist. Dat met de focus op beheer enerzijds en “losse” aansturing van ontwikkelingsprojecten anderzijds er een “gat” is gevallen. In jargon: er is geen alignment van business en ICT.

Change management levert geen sturing
Kijkend naar de ICT organisatie van deze bedrijven valt onmiddellijk op dat er geen structurele overbrugging is van dat gat. Change management alleen is onvoldoende: dit focust immers uitsluitend op het moment dat er “iets” doorgevoerd moet worden in de ICT infrastructuur. Alle beslismomenten daarvoor heb je als ICT organisatie al gemist. Hoe vaak komt het niet voor dat change processen worden overruled door de business, omdat het zo belangrijk is dat …(u kent de situaties, dus vul zelf maar in).

Change management levert dus geen echte sturing op. Een architectuur proces wel. De architect kan en moet de brug slaan tussen de verschillende dimensies in bedrijven. Bij de optimale vervulling van de rol van architect ben jij (en je team) onafhankelijk en heb je gelijke aandacht voor:
• De bouwwaarde: focus op de ontwikkelbaarheid en onderhoudbaarheid van het systeem, door toepassing van heldere ontwerpprincipes;
• De gebruikswaarde: focus op wat het systeem toevoegt voor de organisatie (de functie), in relatie tot de investering (80-20 denken);
• De belevingswaarde: focus op wat de eindgebruiker ervaart bij het gebruik van het systeem, wordt hij/zij ondersteund of geremd? (gebruiksgemak, look-and-feel, begrijpbaarheid); 
• De beheerwaarde:  focus op het voldoen aan de non-functionele kwaliteitscriteria die door het systeem worden geëist.
Deze vier aspecten vormen de vier pijlers van de brugfunctie die architectuur kan vervullen in alle typen organisaties.  Besteed onvoldoende aandacht aan een van de pijlers, en er ontstaat onmiddellijk frictie.

De ICT users vullen de rol van ICT Architect niet of hooguit ad hoc in, en dan vaak met wisselende externe partijen. Dat komt de toekomstvastheid van het systeem meestal niet ten goede, en als de architect een “project gedreven ontwikkelfocus” heeft, dan weet je een ding zeker: beheer sneeuwt sowieso onder (kijk maar eens hoe dit werkt bij ICT Providers).

En de eigen medewerkers? Als die als architect worden aangewezen of gezien hebben ze wellicht nog niet alle ervaring en/of de statuur om voldoende overwicht te hebben op alle belanghebbenden in dit ingewikkelde speelveld. Naar deze functie moet een medewerker toegroeien. Liefst ook door ervaring op te doen in verschillende omgevingen en rollen, want anders loop je kans op een organisatorische blinde vlek.

Uitbesteding architectuur functie?
Grote organisaties kunnen hun architecten i.h.a. wel vasthouden. Voor kleine organisaties, en dan zeker de ICT Users, ligt dat wel anders. Uitbesteden dan maar? Nou, outsourcing van de architectuurfunctie ligt in het algemeen niet voor de hand. De effectieve architect heeft een strategisch/tactische functie, en die zou elke organisatie, provider of user, zelf moeten willen invullen.
Maar uitbesteding kan natuurlijk wel en er kunnen gegronde redenen voor zijn, b.v.:
• de eigen organisatie is te klein;
• een of meer full-time architecten zijn te duur;
• het speelveld is te klein om voor een architect interessant te zijn;
• een geschikte kandidaat is überhaupt onvindbaar;
• het blijkt moeilijk eigen architecten vast te houden;
• etc.

Herkent u zichzelf in deze blog? Of zegt u “wat een onzin”.  Graag ga ik met u in discussie, zowel over de manier waarop je de brug slaat tussen ontwikkeling en beheer, als wel over de rol van architect in dergelijke processen. Laat maar komen die reacties!