XaaS klarar inte vad som helst – allt som tjänst kan bli en otjänst

XaaS definieras, tyvärr, som ”varje slags datortjänst som levereras genom internet och som betalas efter en flexibel förbrukningsmodell i stället för genom ett förhandsköp eller en licens”

Googla lite efter XaaS så lär du få läsa många lovord, om och om igen. Men för oss som är lite härdade är det svårt att undvika slutsatsen att XaaS i själva verket inte är mycket mer än en korsning av molnbaserade tjänster och interndebitering.

Och trots allt prat tycks man ignorera det faktum att XaaS är den logiska konsekvensen av tjänsteorienterad arkitektur (service-oriented architecture, SOA).

Det är också konstigt att XaaS utelämnar de delar av ”allt” som den naiva observatören kanske tycker är den viktigaste kategorin tjänster som it-avdelningen kan erbjuda. Nämligen allt som affärsanalytiker, internet it-konsulter, applikationsutvecklare och supporten arbetar med.

Så jag antar att ”allt” som tjänst i själva verket betyder ”A few things as a service (AFTaaS)” eller kanske “Everything, except effort, as a service” (EEEaaS).

Vad XaaS borde innebära

Vad XaaS borde innebära är den logiska tillämpningen av principerna bakom SOA på praktiskt taget allt som företaget gör.

Det borde, till exempel, omfatta det som företagen kallas för business process outsourcing (BPO). Det borde också omfatta något som vi skulle kunna kalla för “business process insourcing”, fast det brukar heta ”delade tjänster”.

Eller kanske Work as a service (WaaS)?

XaaS borde alltså inte bara omfatta själva tekniken, utan också de resultat av verksamheten som it ska stödja.

Men inte vem som betalar, och hur. Arkitektur handlar om att sätta ihop lösningar, inte om att finansiera dem.

”Work as a Service”: Delade tjänster som arkitektur

Så här ligger det till: BPO är inget nytt. Det har gjort betalning per glas till ett alternativ från första början.

Och precis som att it-avdelningen kan förse användarna i verksamheten med SaaS (software-as-a-service), antingen genom att kommersiellt moln eller genom applikationer som körs i huset, så kan funktioner i verksamheten göra sina tjänster tillgängliga för resten av företaget genom att inrätta delade tjänster som körs i huset, eller genom en BPO-leverantör.

Men en grupp för delade tjänster är inte samma sak som BPO, fast intern. Skillnaden? Att skriva kontrakt med en BPO-leverantör är inte ett beslut om arkitektur. Att lägga upp en intern delad tjänst handlar däremot om arkitektur.

Liksom i den flesta fall med outsourcing är beslutet att anlita en BPO-leverantör oftast ett erkännande av misslyckad företagsledning. Det är att släppa ifrån sig ansvaret för en verksamhetsfunktion som företagsledningen inte klarade till ett kontrakterat företag.

Men det betyder inte alltid att det rätta valet är att lägga upp det hela som en samling delade tjänster.

Några av nackdelarna. En intern delad verksamhetsarkitektur får, till skillnad från BPO, absurda konsekvenser om den förs till sitt logiska slut. Nämligen att varje företagsavdelning debiterar varje annan företagsavdelning för de tjänster som den tillhandahåller. Till exempel kan it-avdelningen varje månad skicka räkning till personalavdelningen för användningen av personalavdelningens it-system. Samtidigt kan personalavdelningen slå tillbaka genom att skicka räkningar till it-avdelningen för rekrytering, lönehantering och tjänsteförmåner.

Delade tjänster i det absurda kan förvandla företaget till en jättelik självförtärande orm.

Verksamhetstjänstorienterad arkitektur: En storlek passar inte någon

BPO och XaaS har en viktig egenskap gemensam. Den kan i vissa situationer vara en fördel, men för det mesta är den en nackdel. Nämligen tvånget att köra med standardprodukter. Detta beror inte på att it-avdelningen gillar att förenkla. Det drivs av att de som fattar beslut om verksamhetsarkitekturer föredrar att standardisera processer och praktiker över hela linjen.

Det kanske inte låter så illa, men det kan vara det. Att tillhandahålla en tjänst som fungerar precis likadant för alla användare, oavsett vilka specifika och kanske unika behov de har, kan kanske spara pengar. Men på lång sikt kan det bli en hämsko.

Föreställ dig till exempel att personalavdelningen väljer Business services oriented architecture som arbetssätt och erbjuder Personaladministration som tjänst till interna kunder. Som inslag i Personaladministration som tjänst finns Rekrytering som tjänst. Och som argument för detta lovprisar personalavdelningen de standardiserade processernas förmåga att sänka kostnader.

Men tänk sig sedan att du ansvarar för butikerna hos en säsongskänslig affärskedja – en som måste skaffa extrapersonal mellan första advent och trettonhelgen. Och tänk dig att it-avdelningen samtidigt behöver rekrytera en databasadministratör.

Jag är rätt övertygad om att samma process inte fungerar för att både anställa butikspersonal i hundratal och för att anställa en enda, högt specialiserad it-expert.

”Standardisera” är lätt att säga, men svårt att få att fungera som man vill. Och det gäller redan innan den personalansvariga som håller i rekryteringarna försöker förklara vad han vill att det personaladministrativa systemet ska göra.

Kort sagt så är det som vi kan kalla för en verksamhetstjänstorienterad arkitektur inte särskilt annorlunda än SOA (och dess lillebror mikrotjänster) om du använder det i din applikationsarkitektur. I både fallen är påtvingad standardisering med en enda version lika med systemutveckling av modell en-storlek-passar-ingen.