ICT architectuur: randvoorwaarde voor maar juist ook tijdens uitbesteding

Populistische struisvogelpolitiek of de koe bij de horens vatten?

Stel, een organisatie heeft besloten om haar ICT dienstverlening uit te besteden. Laten we voor het gemak, “for the sake of argument”, in dit voorbeeld er vanuit gaan dat dit infrastructuurdienstverlening omvat, inclusief de verantwoordelijkheid om applicaties technisch ter beschikking te stellen aan eindgebruikers. Functioneel (applicatie) beheer blijft in de eigen organisatie belegd.

Een belangrijk onderdeel van het traject om tot uitbesteding te komen is het bepalen van de exacte scope. Wat wordt er uitbesteed? Die scope wordt beschreven in termen van infrastructuurcomponenten en veelal in termen van dienstenniveaus voor die infrastructuur. Onderwerpen als beschikbaarheidspercentage en resolutietijd spelen hier een belangrijke rol.

Een professionele leverancier zal vragen om inzicht in de samenhang tussen die infrastructuurcomponenten. De uitbestedende organisatie heeft (natuurlijk) grip op haar ICT architectuur, en kan de potentiële leverancier(s) dit inzicht geven.

Diezelfde professionele leverancier zal dit inzicht niet alleen op infrastructuurniveau willen hebben, maar zal aangeven dat het van belang is om te weten welke applicaties waarop draaien c.q. waarvan afhankelijk zijn. En hoe de samenhang tussen die applicaties is. Dat is tenslotte nodig om de technische beschikbaarheid van die applicaties te kunnen garanderen. De uitbestedende organisatie heeft (natuurlijk) ook dit architectuurniveau helder in kaart en kan de potentiële leverancier(s) dit inzicht geven.

De gevraagde serviceniveaus ten aanzien van de technische beschikbaarheid van de applicaties blijken vervolgens voor alle applicaties hetzelfde te zijn. De eerdergenoemde professionele leverancier zal aangeven dat zij verwacht dat dit niet juist is, omdat bepaalde applicaties een rol spelen in zeer belangrijke bedrijfsprocessen en andere applicaties net even wat minder belangrijk zijn. Er ontstaat een goede discussie omtrent differentiatie in serviceniveaus. De basis voor deze discussie, en de eruit voorkomende besluiten, is de match van de applicatiearchitectuur met de bedrijfsprocessen.

Tot zover gaat alles “volgens het boekje”. De contractuele afspraken over de dienstverlening worden vastgelegd, en na uitgebreide onderhandelingen over het financiële plaatje worden de handtekeningen gezet. Het ingaan van de overeenkomst wordt op bescheiden wijze gevierd tijdens een klein feestje, en de hard gewerkte hebbende medewerkers aan beide zijden worden in het zonnetje gezet. En dan?

Tijdens het uitbestedingproces is goed nagedacht over de invulling van de regiefunctie. Op welke wijze wordt straks gezorgd voor continue afstemming van door de business gewenste diensten en dienstenniveaus versus door de geselecteerde leverancier geleverde diensten en dienstenniveaus? Aan de kant van de uitbestedende organisatie wordt aan de rol van “demand manager” invulling gegeven, en de in het contract opgenomen “governance afspraken” staan borg voor continue “alignment” tussen leverancier en klant. Tot zoverre … alles “volgens het boekje”.

Zes maanden later kom ik op bezoek bij de ICT manager van de organisatie die heeft uitbesteed. Ik vraag hem naar de mate waarin hij grip heeft op zijn ICT. Tijdens het gesprek laat de ICT manager zich ontvallen dat hij verder geen aandacht besteedt aan ICT architectuur. Hij neemt nu tenslotte diensten af. Dus waarom zou hij?

Een eerste aandachtspunt waar ik hem op wijs is de manier waarop de contractuele afspraken zijn vormgegeven. Aangezien deze geformuleerd zijn in termen van “serviceniveaus op infrastructuurcomponenten” kan er wel gesproken worden over het “afnemen van diensten”, maar dat zijn dan nog steeds op individuele componenten gerichte diensten. “Server XYZ is 99,8% beschikbaar”. Dát is de verantwoordelijkheid van de leverancier. Maar hoe deze server in de totale ICT architectuur is opgenomen, hoe deze server samenhangt met c.q. afhankelijk is van andere infrastructuurcomponenten, en welke weerslag het falen van een van deze componenten heeft op de serviceniveaus op andere componenten danwel op applicaties … is niet expliciet afgesproken als zijnde een meetpunt in de dienstverlening, en is dus niet primair de verantwoordelijkheid van de leverancier!

“Ja, maar …”, zegt de ICT manager, “de leverancier moet toch weten welke infrastructuurcomponenten hij voor ons in beheer heeft”. Dat is absoluut waar. En dan is het aan te bevelen voor die leverancier om ook vooral grip te hebben op de samenhang in de ICT architectuur. Echter, dit vergt tijd van medewerkers die gebruik maken van beschikbare tooling, en dat kost dus geld. Indien dit niet gecontracteerd en dus vooraf expliciet besproken is, zal geen enkele leverancier zelf iemand vrij maken, die er voor zorgt dat de integrale kijk op de actuele ICT architectuur bewaakt wordt. De focus ligt op de afgesproken dienstenniveaus, in dit geval op individuele infrastructuurcomponenten, en dat staat in de rapportage over de service level agreement (SLA).

Professionele leveranciers, en die zijn er, maken bovenstaande bespreekbaar in de commerciële fase. Bij het definiëren van dienstenniveaus, bij het bespreken van de processen tussen leverancier en klant op tactisch en operationeel niveau, en bij het bespreken van de governance. Minimaal levert dit afspraken op over het op regelmatige basis opleveren, door de leverancier, van een actuele weergave van de ICT architectuur. En mogelijk wordt zelfs de stap gemaakt naar serviceniveaus op beheerketens, waardoor grip op afhankelijkheden ingebakken zit in de dienstenniveaus.

Sommige leveranciers vullen die vereiste grip op de ICT architectuur in met een “houtje touwtje” methode. Men wijst een medewerker aan die in de laatste week van de maand als een gek Visio platen in elkaar zet c.q. bijwerkt op basis van de actuele sitiuatie, deels verkregen door gesprekken met beheermedewerkers en de service manager, en deels verkregen door in de beheerinformatiebronnen te spitten. Het resulterende overzicht groeit van “onvolledig en knullig” naar “redelijk”, maar nooit veel verder dan dat. En aangezien deze werkwijze zeker geen automatisme is bij de meeste ICT dienstverleners, groot en klein, vergt het veel moeite om het voor elkaar te krijgen. Het is dan ook aan te bevelen om hier vooraf, in de contractfase, hele duidelijke afspraken over te maken, zowel over de kwantiteit alsook over de kwaliteit, en wellicht zelfs over het format, van de aan te leveren informatie.

Ook het format? Ja, absoluut. Want wat doet de klantorganisatie met die ICT architectuur? Okee, het is ook de basis voor de facturering door de leverancier dus het is wel prettig om dat te kunnen controleren. Het is ook de basis voor de beoordeling van dienstenniveaus inclusief de algehele tevredenheid over de geleverde diensten. En daar waar problemen ontstaan zijn, met of zonder financiële consequenties, is het prettig om gezamenlijk te kunnen bepalen waar de oorzaken liggen en hoe deze kunnen worden opgelost. De leverancier kan nou wel zeggen dat oplossing XYZ het beste is, maar je zult als klant toch moeten kunnen beoordelen of dit hout snijdt.

Maar er is meer. Zoals in eerdere artikelen betoogd wordt het maximale uit “werken onder architectuur” gehaald als van boven naar beneden, en van beneden naar boven, de doorvertaling wordt gemaakt, en wordt onderhouden. Van bedrijfsprocessen naar technische architectuur, en van technische architectuur uiteindelijk weer naar bedrijfsprocessen. Het feit dat de infrastructuur nu in de lucht wordt gehouden door een derde partij doet geen afbreuk aan dit principe. En dus dient de klantorganisatie in staat te zijn om die integrale architectuur te bewaken.

En daar komt dan het onderwerp “format” weer om de hoek. Losse Visio platen zijn moeilijk te koppelen, los van het feit dat informatie over objecten in die Visio architectuurplaten niet in een database wordt onderhouden, er geen queries op kunnen worden “afgevuurd” etc. Dat geldt als een organisatie zelf het beheer doet, en dat geldt als een deel van dat beheer is uitbesteed. De klantorganisatie heeft daar op ingespeeld door bedrijfsprocessen, informatiestromen, applicatielandschappen etc. in een professionele architectuurtool te beheren. Met visualisatiemogelijkheden, maar ook met query mogelijkheden. Stel dat die architectuurtooling werkt op basis van Archimate. Zou het dan niet ideaal zijn als de leverancier in staat is om, bijv. op maandelijkse basis, het Archimate model van de ICT architectuur aan te leveren. Ten eerste levert het gebruik van Archimate, bij voorkeur via dezelfde tooling maar eventueel zijn er wel vertaalslagen te maken, een perfecte duidelijke “taal” op om te zorgen dat beide partijen dezelfde blik op dezelfde ICT architectuur hebben. Ten tweede zorgt het er ook nog eens voor dat de van de leverancier verkregen informatie eenvoudig kan worden gekoppeld aan de eigen in Archimate onderhouden architectuurmodellen op bedrijfsproces-, informatie- en applicatieniveau!

Vraag er eens naar, als je gaat uitbesteden, bij de potentiële leveranciers. Hoe borgt men de actuele kijk op de ICT architectuur? En hoe is men in staat om die kijk te communiceren naar u, als klant. Veel leveranciers zullen dit erg lastige vragen vinden en zetten liever een kruisje achter “beschikbaarheid 99,8%”. Terwijl juist het gebruik van ICT architectuur ervoor gaat zorgen dat de aangegane samenwerkingsrelatie een succes blijft, gedurende de jaren van het contract. Er zijn leveranciers van “managed services” die hier heel goed op inspelen. Maar het zijn er nog niet veel. Het is belangrijk om het kaf van de koren te scheiden. Vat de koe bij de horens, want als je kiest voor struisvogelpolitiek loop je later onherroepelijk tegen de lamp.