SSOA : Self Service Oriented Architecture: ‘as a Service’ for real

This post provides some insights about how to establish a true agile enterprise IT based on an evolved concept of Service Oriented Architectures (SOA) and how that relates to Cloud Services Providers (CSPs) and Platforms.

Around 2000, many architecture efforts in the enterprise were about transforming the existing IT architectures into Service Oriented ones, and in some way, those efforts still continue today through micro services architectures.

The basic idea of SOA was to create Services per business functionality (i.e BillingService) and make them discoverable through a Service Directory (or Registry), so business processes and applications could be created by composing services. The idea of having business processes automated via Services composition and orchestration captivated many CTOs and CIOs and there were huge investments on SOA, integration and ESBs across the enterprise world.

Almost at the same time, according to the famous Steve Yegee post Jeff Bezos initiated a transformation inside Amazon that ended up leading to what we know today as AWS. I have the suspicion that Bezos and Amazon understood the concept of Services and SOA slightly differently than the rest of the industry at that time.

Meanwhile the industry was mainly focused on Services Functionality and integration of services, Amazon was focused on making every interaction between departments fully digital and in a Self-Service way: via electronic interfaces (APIs) and forbidding human to human interaction.  One important consequence of not allowing direct interaction between humans, is that services interfaces no longer need to provide only APIs operations for using the service functionality (i.e. sendMessage(queue, msg) in a Queue service like AWS SQS) . Instead, the service interfaces also need to provide operations for making the service “usable” in a Do It Yourself  (DIY) way, so operations for provisioning and managing IT resources are also needed (ie: createQueue(params): queue ) in the services interfaces. Since the services can be potentially consumed by anyone in the company in DIY way, the following set of features become relevant :

• managing multi tenancy (ie tenant = aws account) for serving multiple consumers
• dealing with consumers identity, credentials, permissions and policies (i.e IAM policies)
• establishing quotas, guards and limits.
• providing proper documentation and portals for service consumers (enabling DIY) 
• metering the service usage and eventually billing the consumption of resources (pay per use) 
• API published and accessible via IP (API includes operations for using the service and managing the service resources in a DIY way)
• API standards and Resources models (important for conceptual integrity across multiple services)
• Consoles, CLI, and SDKs for simplifying the consumptions of the Service APis 
• Onboarding process to start consuming Services.
• Providing Service Levels:  SLIs, SLOs and SLAs with proper operations processes and teams (DevOps)

Instead of naming this style of architecture  “as a Service” I prefer to refer to it as Self Service Oriented Architecture (SSOA) or just simply Cloud Services Architecture (or Web Services like AWS), since not everybody gets the importance of self service and DIY when using the terms IaaS, PaaS, SaaS.

By making each Service in the company Self Service,  any team in the company can potentially consume services from other teams,  without requiring integration projects between service-consumers and service-providers teams. Actually, asking a human to provision resources either via email, ticketing tools or equivalent human2human interface, as it commonly happens in many enterprises, is usually a symptom of a bad Self Service architecture and contrary to that DIY way of working. I do believe that becoming self-service at all services and departments in a company, can enable true agility and autonomy, being an important ingredient of modern DevOps approaches that treat infrastructure (resources) as code (a direct consequence of having an API for provisioning and managing resources in a programmable way).

That way of operating (self service / DIY)  is not new, since it is how the cloud and the web operates. For instance, nobody needs to interact with any Google employee to get a new Gmail account. As a service consumer I can self-provision my new email account on Gmail by myself via the internet. Gmail is a service offered via the web. I suspect that one of the reasons why AWS called its services WebServices was because they are offered through the web (as you can see AWS does not use explicitly the terms IaaS, PaaS, SaaS....) 

The same happens with any Cloud Service Provider (CSP) in the IT space today,  like AWS, GCP or Azure. Once you are on-boarded into the CSP’s platform, you are autonomous to consume and use any provided service via the internet (using APIs, CLIs, SDKs, WebConsole) on your own (as long as you pay and have permissions, of course), without requiring any human interaction with the team that created and manages the service you are consuming. This is not usually the case of many big corporations IT departments, in which it is quite common to have teams providing services to others via humans and/or requiring humans to perform the setup and provision of resources. In that context , many projects requiring assets and services from different teams end up being integration projects complex to manage and execute, and I believe this is one of the reasons why big enterprises usually exhibit bad time to market when compared to digital companies.

Many digital transformations pivot around the idea of modernism technologies and applying agile and DevOps practices. Beyond the transformation of IT technology, employee skills and culture, I do believe that making every team or department a service team offering Services that can be consumed in a Self-Service way by others, can make a substantial difference in achieving true agility and true digital transformation. Moreover, If every service is designed to be externalised (the service is designed to be consumed by any developer around the world via the internet), the company could end up selling those services to other companies and developers, generating new business lines (as Amazon did with AWS).

In essence, if you wanted to transform your IT into a Self Service Oriented Architecture SSOA, basically you would need to replicate or at least “emulate” the behaviour and features of public CSPs, which implies making your IT platform behave as a private CSP (whose services could end up being externalised). I would highlight the word “emulate” in the previous sentence, because depending on your requirements and existing IT capabilities, features that are determinant in a public CSP, like “elasticity” and scalability, can not be as determinant in your own private CSP, at least in the beginning of the transformation journey (because you are serving less consumers with less traffic than public CSPs do). Doing that kind of transformation will require certain transversal architecture elements (like an IAM and others), but perhaps this is subject of another post (some hints are in this talk)