XaaS is, regrettably, defined as, \u201cany computing service that is delivered via the internet and paid for in a flexible consumption model rather than as an upfront purchase or license.\u201d\n\nDo some Googling about XaaS and you\u2019ll find much repetitive gushing, but for the more jaundiced among us, it\u2019s hard to avoid concluding that XaaS is, in fact, little more than the intersection of cloud-based computing and charge-backs.\n\nAnd yet in all of the discussion, that XaaS is the logical outcome of services-oriented architecture (SOA) seems to have been ignored.\n\nAlso strange is that XaaS excludes the part of \u201ceverything\u201d 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.\n\nWhich I guess means \u201cEverything\u201d as a Service is really \u201cA Few Things as a Service\u201d (AFTaaS), or maybe \u201cEverything Except Effort as a Service\u201d (EEEaaS).\n\nWhat XaaS should really mean\n\nWhat XaaS ought to refer to is the logical application of SOA principles to just about everything that gets done in the enterprise.\n\nIt should, for example, include what services firms call business process outsourcing (BPO). It should also include what we might dub \u201cbusiness process insourcing\u201d but usually call \u201cshared services.\u201d\n\nWork as a Service (WaaS), anyone?\n\nXaaS should, that is, include not only the technology itself but also the business results the technology supports.\n\nBut not who pays, and how. Architecture is about how solutions are put together, not about financing them.\n\n\u2018Work as a Service\u2019: Shared services as architecture\n\nHere\u2019s the thing: BPO isn\u2019t new, and has made paying by the drink for work an option since its inception.\n\nAnd 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.\n\nBut a shared services group isn\u2019t just like a BPO only internal. The difference between them? Contracting with a BPO provider isn\u2019t an architectural decision. Organizing as an internal shared service most assuredly is.\n\nLike 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\u2019t properly oversee to a contract.\n\nThis doesn\u2019t always mean organizing as a collection of shared services is the right choice, though.\n\nAmong 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.\n\nUbiquitous shared-services can turn the enterprise into a giant financial ouroboros.\n\nBusiness services oriented architecture: One size fits no one\n\nBPOs 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\u2019t a matter of IT\u2019s preference for simplification, either. It\u2019s driven by business architecture\u2019s decision-makers\u2019 preference for standardizing processes and practices across the board.\n\nThis 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.\n\nImagine, 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.\n\nImagine, then, that you\u2019re 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.\n\nI trust it\u2019s clear the same process won\u2019t work for both recruiting store staff by the hundreds and for hiring a single, highly specialized technical professional.\n\n\u201cStandardize\u201d is easy to say but hard to make work right. And that\u2019s before the HR manager responsible for recruiting tries to explain what they need the HRIS to do.\n\nIn this, what we might call a business-services-oriented architecture isn\u2019t 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.