XaaS isn’t everything — and it isn’t serviceable

XaaS is, regrettably, defined as, “any computing service that is delivered via the internet and paid for in a flexible consumption model rather than as an upfront purchase or license.”

Do some Googling about XaaS and you’ll find much repetitive gushing, but for the more jaundiced among us, it’s hard to avoid concluding that XaaS is, in fact, little more than the intersection of cloud-based computing and charge-backs.

And yet in all of the discussion, that XaaS is the logical outcome of services-oriented architecture (SOA) seems to have been ignored.

Also strange is that XaaS excludes the part of “everything” that the uninitiated might think of as the most important set of services IT provides, namely, everything business analysts, IT internal consultants, and application development and support staff do for a living.

Which I guess means “Everything” as a Service is really “A Few Things as a Service” (AFTaaS), or maybe “Everything Except Effort as a Service” (EEEaaS).

What XaaS should really mean

What XaaS ought to refer to is the logical application of SOA principles to just about everything that gets done in the enterprise.

It should, for example, include what services firms call business process outsourcing (BPO). It should also include what we might dub “business process insourcing” but usually call “shared services.”

Work as a Service (WaaS), anyone?

XaaS should, that is, include not only the technology itself but also the business results the technology supports.

But not who pays, and how. Architecture is about how solutions are put together, not about financing them.

‘Work as a Service’: Shared services as architecture

Here’s the thing: BPO isn’t new, and has made paying by the drink for work an option since its inception.

And just as IT can provide SaaS to its business users either by way of commercial cloud or in-house provisioned applications, so business functions can make their services available to the rest of the business by way of organizing as in-house provisioned shared services, or through use of a BPO vendor.

But a shared services group isn’t just like a BPO only internal. The difference between them? Contracting with a BPO provider isn’t an architectural decision. Organizing as an internal shared service most assuredly is.

Like most other outsources, the decision to engage a BPO provider is usually an admission of management failure. It hands off responsibility for a business function that internal management couldn’t properly oversee to a contract.

This doesn’t always mean organizing as a collection of shared services is the right choice, though.

Among the downsides: An in-house shared-services business architecture, unlike a BPO, has, when carried to its logical conclusion a reductio ad absurdum outcome, where every business department charges every other business department for the services it provides. For example, IT might charge HR a monthly fee for use of the HRIS, while HR might reciprocate by charging IT for recruiting, benefits management, and payroll services.

Ubiquitous shared-services can turn the enterprise into a giant financial ouroboros.

Business services oriented architecture: One size fits no one

BPOs and XaaS do share a characteristic that might, in some situations, be a benefit but in most cases is a limitation, namely, the need to commoditize. This requirement isn’t a matter of IT’s preference for simplification, either. It’s driven by business architecture’s decision-makers’ preference for standardizing processes and practices across the board.

This might not seem to be an onerous choice, but it can be. Providing a service that operates the same way to all comers no matter their specific and unique needs might cut immediate costs but can be, in the long run, crippling.

Imagine, for example, that Human Resources embraces the Business Services Oriented Architecture approach, offering up Human Resources as a Service to its internal customers. As part of HRaaS it provides Recruiting as a Service (RaaS). And to make the case for this transformation it extols the virtues of process standardization to reduce costs.

Imagine, then, that you’re responsible for Store Operations for a highly seasonal retailer, one that has to ramp up its in-store staffing from Black Friday through Boxing Day. Also imagine IT needs to recruit a DBA.

I trust it’s clear the same process won’t work for both recruiting store staff by the hundreds and for hiring a single, highly specialized technical professional.

“Standardize” is easy to say but hard to make work right. And that’s before the HR manager responsible for recruiting tries to explain what they need the HRIS to do.

In this, what we might call a business-services-oriented architecture isn’t that different from adopting SOA (along with microservices, its teeny brethren), for your application architecture. In both cases, enforcing standardization on a single version is one-size-fits-no-one engineering.