Van shared service center naar managed service provider: waarom die stap nodig is en wat hij van de architectuur vraagt

Het probleem: een shared service center levert onderdelen, geen uitkomst

Veel grote organisaties hebben hun IT-beheer ondergebracht in een shared service center. Dat model heeft veel gebracht. Eén afdeling bundelt het beheer van servers, opslag, netwerk en werkplekken voor meerdere interne afnemers, zodat niet iedere afnemer dezelfde kennis en middelen zelf in huis hoeft te hebben.

Maar het model heeft een ingebouwde beperking. Een shared service center levert onderdelen. Een virtuele server, een stuk opslag, een database, een netwerksegment. De klant bestelt die onderdelen, zet ze in elkaar en is zelf verantwoordelijk voor het resultaat. Als de applicatie traag is, ligt dat aan de server, de opslag, het netwerk of de applicatie zelf, en het gesprek daarover gaat over componenten in plaats van over de dienst die de klant nodig had.

Een managed service provider werkt andersom. Die levert een dienst met een afgesproken uitkomst, bijvoorbeeld een applicatieplatform dat beschikbaar is, beveiligd wordt en bijgewerkt blijft, en neemt de verantwoordelijkheid voor alles wat daarvoor nodig is. De klant koopt de uitkomst, niet de onderdelen.

Wat er precies verschilt

Het wezenlijke verschil zit in de verantwoordelijkheid. Bij een shared service center ligt de samenhang bij de klant. Bij een managed service provider ligt de samenhang bij de provider. Dat verplaatst niet alleen werk, het verplaatst ook de plek waar architectuur nodig is.

Waarom shared service centers deze stap moeten maken

Vier krachten duwen shared service centers dezelfde kant op.

Klanten willen een uitkomst, geen bouwpakket. Een directie of een dienstonderdeel heeft geen behoefte aan servers. Het heeft behoefte aan een werkende, veilige en actuele applicatieomgeving. Zolang het service center onderdelen levert, moet elke klant zelf de kennis in huis hebben om er iets werkends van te maken. Dat is precies de kennis die het service center bedoeld was te bundelen.

De vergelijking met publieke cloud is onontkoombaar. Cloudaanbieders leveren managed diensten met een catalogus, een prijs per dienst en een duidelijke verantwoordelijkheidsverdeling. Interne klanten vergelijken daarmee, ook als ze om goede redenen niet naar de publieke cloud kunnen. Een shared service center dat componenten blijft leveren, verliest die vergelijking op transparantie en snelheid, niet per se op prijs.

Security en continuïteit zijn eigenschappen van een dienst, niet van een component. Normenkaders zoals BIO en ISO 27001 vragen om aantoonbare beheersing van de hele keten. Als de klant de onderdelen zelf samenstelt, is niemand verantwoordelijk voor de keten als geheel. Een managed dienst kan hardening, monitoring, backup en herstel als vaste eigenschap meeleveren, omdat de provider de hele dienst beheert. Zie ook de dienst security, compliance en continuïteit.

Schaal vraagt om standaardisatie. Veel afnemers met ieder een eigen variant van dezelfde omgeving zijn moeilijk schaalbaar te automatiseren en lastig bij te houden in hun levenscyclus. Elke variant vraagt eigen kennis, eigen tests en eigen onderhoud. Standaarddiensten zijn wel herhaalbaar te leveren en te onderhouden. Wie wil automatiseren, moet eerst standaardiseren, en wie wil standaardiseren, moet diensten definiëren.

Wat de overstap van de architectuur vraagt

Hier zit de kern. De stap van componenten naar diensten is geen reorganisatie en geen nieuw tarievenmodel. Het is een architectuurvraagstuk. Vanuit enterprise-architectuur bekeken vraagt de overstap om vijf dingen.

1. Een dienstencatalogus die op capabilities is gebouwd

De catalogus bepaalt wat de organisatie levert. De verleiding is groot om de bestaande componenten een nieuwe naam te geven en dat een catalogus te noemen. Dat verandert niets. Een bruikbare catalogus begint bij wat klanten moeten kunnen, vertaald naar diensten die een uitkomst leveren. Capability-based denken is daarvoor het gereedschap. Per capability wordt duidelijk welke dienst die ondersteunt, wat die dienst omvat en waar de grens ligt.

2. Standaardplatformen met vaste bouwblokken

Een dienst met een afgesproken uitkomst kan alleen bestaan als de onderliggende platformen standaard zijn. Architecture Building Blocks beschrijven wat een platform moet kunnen, Solution Building Blocks beschrijven hoe dat concreet wordt ingevuld. Deploymentpatronen leggen vast hoe een dienst wordt uitgerold, in welke varianten en met welke keuzes voor de klant. Alles wat daarbuiten valt is maatwerk, en maatwerk moet zichtbaar duur zijn. Zie platform-, cloud- en infrastructuurarchitectuur.

3. Een principestelsel dat besluiten stuurt

Bij elke nieuwe klantvraag komt de vraag terug of dit binnen de standaard past of niet. Zonder vastgelegde principes wordt dat elke keer een onderhandeling en wint uiteindelijk de klant die het hardst roept. Een principestelsel maakt de afweging toetsbaar. Standaard tenzij, beveiliging als ontwerpeigenschap, automatiseerbaar of niet leverbaar. Principes zijn pas bruikbaar als ze uit de strategie volgen, als ze toetsbaar zijn en als er een besluitvormingsproces aan hangt.

4. Een heldere verdeling van verantwoordelijkheden tussen teams

Een managed dienst loopt door meerdere teams heen. Netwerk, compute, opslag, beveiliging, beheer. Als elk team alleen zijn eigen component kent, ontstaat de samenhang nergens. De architectuur moet vastleggen welk team eigenaar is van welke dienst, welke platformteams daaraan leveren en hoe requirements en afhankelijkheden tussen die teams worden belegd. Dat is technische regie, en zonder die regie blijft de catalogus een belofte. Zie architectuurgovernance en technische regie.

5. Automation en lifecycle als onderdeel van de dienst

Een managed dienst kan met de hand worden opgebouwd, maar wordt dan moeilijk herhaalbaar, schaalbaar en voorspelbaar. Levering, wijzigingen, beveiligingsupdates en uiteindelijk de uitfasering horen daarom geautomatiseerd en herhaalbaar te zijn. Dat betekent dat een architectuurkeuze pas af is als duidelijk is hoe die geautomatiseerd wordt uitgerold en gevalideerd. Acceptatiecriteria per dienst maken dat toetsbaar.

De valkuilen

Uit de praktijk van dit soort trajecten komen een paar patronen steeds terug.

• De catalogus als etiket. Bestaande componenten krijgen een dienstnaam, maar de verantwoordelijkheid verschuift niet. De klant integreert nog steeds zelf.
• Teams die per component blijven denken. De organisatie zegt diensten, de teams leveren onderdelen. Zolang de sturing en de meting op componenten blijven staan, verandert het gedrag niet.
• Uitzonderingen zonder prijs. Elke klant krijgt zijn eigen variant, omdat niemand nee kan zeggen. Zo holt elke uitzondering de standaard verder uit.
• Governance achteraf. Architectuurbesluiten worden genomen nadat de dienst al gebouwd is. Elke correctie is dan duurder dan een besluit vooraf.
• Alles tegelijk. De hele catalogus in één keer omzetten wordt een langlopend programma dat onderweg van richting verandert. Klanten merken er lang niets van, behalve onrust.

Hoe u begint

De overstap hoeft niet met een groot programma te beginnen. Een stapsgewijze aanpak kan er zo uitzien.

1. Kies één dienst en werk die van begin tot eind uit. Een dienst waar klanten om vragen en die over meerdere teams loopt. Beschrijf de uitkomst, de standaardvarianten, de verantwoordelijkheden en de acceptatiecriteria.
2. Leg de capabilities en het principestelsel vast voor zover die voor deze dienst nodig zijn. Niet de hele organisatie modelleren, wel het fundament waarop de volgende diensten kunnen bouwen.
3. Bouw de dienst zoals de catalogus belooft. Standaardplatform, deploymentpatroon, automation, beveiliging als eigenschap. Wat niet lukt, is een architectuurbesluit dat expliciet moet worden gemaakt.
4. Meet wat de klant merkt. Levertijd, beschikbaarheid, doorlooptijd van een wijziging. Dat zijn de cijfers die het gesprek met de directie mogelijk maken.
5. Herhaal, en laat het doelbeeld meegroeien. Elke volgende dienst maakt de catalogus, de bouwblokken en het principestelsel completer.

Samengevat

• Een shared service center levert componenten, een managed service provider levert diensten met een uitkomst. Het verschil zit in wie verantwoordelijk is voor de samenhang.
• De overstap is nodig omdat klanten een uitkomst willen, omdat de vergelijking met de publieke cloud onontkoombaar is, omdat security en continuïteit eigenschappen van een dienst zijn, en omdat schaal standaardisatie vraagt.
• De stap is een architectuurvraagstuk. Hij vraagt om een catalogus op capabilities, standaardplatformen met vaste bouwblokken, een principestelsel, een heldere verdeling van verantwoordelijkheden en automation als onderdeel van de dienst.
• Begin met één dienst van begin tot eind, en bouw het fundament al doende op.

Dit is hoe Coolegem ICT dit soort transities benadert. Niet vanuit de organisatiestructuur of het tarievenmodel, maar vanuit de vraag welke diensten de organisatie moet kunnen leveren, en welke architectuur daarvoor nodig is.

Lees meer over enterprise-, solution- en systemarchitectuur bij Coolegem ICT.