Featured image of post User-Centric On-Demand Self-Service

User-Centric On-Demand Self-Service

The NIST Definition of Cloud Computing highlights On-Demand Self-Service as one of the essential characteristics of the cloud model.

The NIST Definition of Cloud Computing highlights On-Demand Self-Service as one of the essential characteristics of the cloud model. The characteristics of the cloud model are defined independently of the Service Models (SaaS, IaaS, Paas, …) and the Deployment Models (Private cloud, Public cloud, Hybrid cloud, …).

On-demand self-service.
A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.

Simply offering on-demand self-service does not necessarily mean that the desired added value is delivered. The value of the on-demand self-service can be on the side of the (internal) consumer, the business, or in the best case on both sides.

So, how can we make sure to meet the desired added value?
In my opinion, Platform Engineering and applying product management to internal platforms are crucial in achieving User-Centric On-Demand Self-Service and providing greater value.

Platform-as-Product Concept

Nicki Watt (CEO & CTO, OpenCredo) highlights in her talk Why is it so hard to create a great Platform-as-a-Product? | PlatformCon 2023 that the Platform-as-Product Concept is based on three key aspects of Product Thinking:

  • User-Centric

  • Useful & Desirable

  • Constantly evolving features

I believe that these principles are especially relevant to the on-demand self-service portals of the platform.

# Self-Service Portal

Platforms, offering on-demand self-service typically have at least a Self-Service Portal beside other user/machine interfaces, like RestFul API, CI/CD Pipelines, and so on.

The first stop for designing a User-Centric On-Demand Self-Service is the Self-Service Portal. A lot of the complexity of the services you offer can be abstracted by the interface you offer. Your self-service portal’s forms and features are also a great tool to hint the consumers to the “The Golden Path”.

Defaults are Powerful, a lot of consumers will stay at the default value. You can use the defaults to guide the requestor to the preferred setting/flavor/size of the service you offer, but on the other hand, if this setting/flavor/size is not the demand of the majority of your consumers you will generate a lot of overhead (re-request, modify, …). If you want your consumers to make an informed decision, don’t set a default option.

# Day-1 - On-Demand Self-Service

Service Designers tend to offer all of the possible features of their service to the (internal) consumer during the order process (Day-1). In my experience, this often leads to the situation that none of the persona’s needs is fully met, but many consumers are unnecessarily confused or even overloaded. Let’s compare two approaches to a request-form UI.

On-Demand Self-Service - Simple UI

The above request form is radically simplified. This UI can be a perfect fit for the user that does not have complex requirements or users that in the first step just quickly want to order the server and later modify the server (Day-2) to the application requirements.

On-Demand Self-Service - Complex UI

The second example offers the requestor many more options. This additional overhead can be useful for consumers that require precisely customized server configurations and are able to decide all these aspects during the initial order process.

In my experience, a radically simplified form meets the needs of a larger target group. Most consumers of (internal) platforms with self-service are looking for fast results and simplification of their daily business.

# Day-2 - On-Demand Self-Service

Offering on-demand self-service limited to the spinup of new cloud services is a bad idea, you need to cover the whole lifecycle of the services your platform offers. Missing the decommissioning step results in tremendous waste, missing the reconfiguration (Day-2) means missed value, and both result in semi-automated or even manual steps requested via email or ticketing systems.

The possible value of Day-2 operations is huge and not only limited to the specific service itself. There is a lot of potential for other services to interact with this specific service. Avoiding media/tool breaks typically results in faster processes, fewer failures, and a better user experience.

If we stay with the example of the Linux server, a low-hanging fruit for a Day-2 action is CPU and Memory reconfiguration. But typically a Linux server in the IaaS model is way more than the compute and storage configuration, there is identity management, backup & recovery, patch management, monitoring management, firewall rules, configuration management, and so on.

# Visibility

In my opinion, good visibility is one of the key differentiators between a cloud platform (any deployment model) and a traditional virtualized datacenter.

Your users will be very happy to get direct access to information about their service (without switching to another tool).

  • Configuration

  • Basic performance metrics

  • Costs summary

  • Task details

# Automation

Another critical aspect of an on-demand self-service is the automation behind the self-service portal. Automating tasks with standardized in- and outputs is common in enterprise IT, but automating decisions is still challenging due to the need for well-defined and deterministic processes.

Please note that robust automation has a higher priority in an on-demand self-service model with good visibility. Automation-Errors do have a direct impact on the user experience and weakens the trust in the platform. Trust is, in addition to the general added value, an important factor for the broad adaption of the platform.

Built with Hugo
Theme Stack designed by Jimmy