XaaS wordt helaas gedefinieerd als “elke computerservice die via internet wordt geleverd en waarvoor wordt betaald in een flexibel consumptiemodel in plaats van als een voorafgaande aankoop of licentie.”
Ga eens googelen over XaaS en je zult veel herhalende stromen vinden, maar voor de meer geelzuchtigen onder ons is het moeilijk om te concluderen dat XaaS in feite niet veel meer is dan de kruising van cloudgebaseerd computergebruik en terugboekingen.
En toch lijkt in alle discussie dat XaaS het logische resultaat is van services-georiënteerde architectuur (SOA) genegeerd wordt.
Ook vreemd is dat XaaS het deel van “alles” uitsluit dat niet-ingewijden zouden kunnen beschouwen als de belangrijkste reeks diensten die IT levert, namelijk alles wat bedrijfsanalisten, interne IT-consultants en applicatie-ontwikkeling en ondersteunend personeel doen voor de kost.
Wat volgens mij betekent dat “Everything” as a Service eigenlijk “A Few Things as a Service” (AFTaaS) is, of misschien “Everything Behalve Effort as a Service” (EEEaaS).
Wat XaaS echt zou moeten betekenen
Waar XaaS naar zou moeten verwijzen, is de logische toepassing van SOA-principes op zowat alles wat er in de onderneming wordt gedaan.
Het moet bijvoorbeeld omvatten wat dienstverlenende bedrijven business process outsourcing (BPO) noemen. Het moet ook bevatten wat we ‘insourcing van bedrijfsprocessen’ zouden kunnen noemen, maar gewoonlijk ‘gedeelde services’ noemen.
Work as a Service (WaaS), iemand?
XaaS moet dus niet alleen de technologie zelf omvatten, maar ook de bedrijfsresultaten die de technologie ondersteunt.
Maar niet wie betaalt en hoe. Architectuur gaat over hoe oplossingen tot stand komen, niet over de financiering ervan.
‘Work as a Service’: gedeelde services als architectuur
Hier is het ding: BPO is niet nieuw en heeft vanaf het begin een optie gemaakt om met de drank te betalen voor werk.
En net zoals IT SaaS aan zijn zakelijke gebruikers kan bieden via commerciële cloud of in-house geleverde applicaties, zo kunnen bedrijfsfuncties hun diensten beschikbaar stellen aan de rest van het bedrijf door middel van organisatie als in-house geleverde gedeelde diensten, of door gebruik te maken van een BPO-leverancier.
Maar een shared services-groep is niet alleen een interne BPO. Het verschil tussen hen? Contracteren met een BPO-aanbieder is geen architecturale beslissing. Organiseren als interne shared service is dat zeker.
Net als bij de meeste andere uitbestedingen, is de beslissing om een BPO-aanbieder in te schakelen meestal een erkenning van falend management. Het draagt de verantwoordelijkheid voor een zakelijke functie die het interne management niet goed kon overzien, af aan een contract.
Dit betekent echter niet altijd dat organiseren als een verzameling gedeelde services de juiste keuze is.
Een van de nadelen: een in-house shared-services bedrijfsarchitectuur, in tegenstelling tot een BPO, heeft, wanneer het tot zijn logische conclusie wordt gebracht, een reductio ad absurdum resultaat, waarbij elke bedrijfsafdeling elke andere bedrijfsafdeling in rekening brengt voor de diensten die zij levert. IT kan HR bijvoorbeeld een maandelijks bedrag in rekening brengen voor het gebruik van de HRIS, terwijl HR dit kan beantwoorden door IT in rekening te brengen voor werving, beheer van secundaire arbeidsvoorwaarden en salarisadministratie.
Alomtegenwoordige shared-services kunnen van de onderneming een gigantische financiële ouroboros maken.
Bedrijfsservicegerichte architectuur: One size fits no one
BPO’s en XaaS hebben een kenmerk gemeen dat in sommige situaties een voordeel kan zijn, maar in de meeste gevallen een beperking is, namelijk de noodzaak om te commoditiseren. Deze vereiste is ook geen kwestie van de voorkeur van IT voor vereenvoudiging. Het wordt gedreven door de voorkeur van de besluitvormers van de bedrijfsarchitectuur voor het standaardiseren van processen en praktijken over de hele linie.
Dit lijkt misschien geen moeilijke keuze, maar dat kan het wel zijn. Het aanbieden van een service die op dezelfde manier werkt aan alle nieuwkomers, ongeacht hun specifieke en unieke behoeften, kan de onmiddellijke kosten verlagen, maar kan op de lange termijn verlammend werken.
Stel je bijvoorbeeld voor dat Human Resources de Business Services Oriented Architecture-aanpak omarmt en Human Resources as a Service aanbiedt aan zijn interne klanten. Als onderdeel van HRaaS biedt het Recruiting as a Service (RaaS). En om het pleidooi voor deze transformatie te maken, prijst het de voordelen van processtandaardisatie om de kosten te verlagen.
Stelt u zich dan eens voor dat u verantwoordelijk bent voor Store Operations voor een retailer die zeer seizoensgebonden is, een die zijn personeelsbezetting in de winkel moet opvoeren van Black Friday tot en met tweede kerstdag. Stel je ook voor dat IT een DBA moet aanwerven.
Ik vertrouw erop dat het duidelijk is dat hetzelfde proces niet werkt voor zowel het werven van honderden winkelpersoneel als voor het inhuren van een enkele, zeer gespecialiseerde technische professional.
“Standaardiseren” is gemakkelijk gezegd, maar moeilijk om het werk goed te maken. En dat is voordat de HR-manager die verantwoordelijk is voor rekrutering probeert uit te leggen wat hij met de HRIS moet doen.
Hierin verschilt wat we een op bedrijfsservices gerichte architectuur zouden kunnen noemen niet zo veel van het adopteren van SOA (samen met microservices, de kleine broeders), voor uw applicatiearchitectuur. In beide gevallen is het afdwingen van standaardisatie op een enkele versie one-size-fits-no-one engineering.
