5.3.5: Configurable Enablement for Cloud Offerings

Cloud services are often praised for their configurability – the ability for customers to tailor the service to their needs without changing the underlying code. The fifth principle, configurable enablement for cloud offerings, emphasizes that the cloud offerings (the final products/services delivered via cloud) should be designed to be configurable and customizable in a self-service manner. In other words, cloud solutions should come with built-in flexibility to meet different business requirements through configuration settings, rather than one-size-fits-all or requiring engineering changes for each customer.

Cloud offerings refers to the actual services delivered to end-users – this could be an Infrastructure-as-a-Service (IaaS) like a virtual machine or storage bucket, a Platform-as-a-Service (PaaS) environment, a Software-as-a-Service (SaaS) application, or even Business-Process-as-a-Service (BPaaS) where entire business processes are delivered as a cloud service. The principle of configurable enablement spans all these: whether you’re delivering raw infrastructure or a complete business app, the user should have control to adjust certain parameters to fit their context.

For example, in IaaS, configurable enablement might mean offering various sizes of VMs, different network configurations, and allowing users to choose regions or availability zones for deployment. In SaaS, it means the software should allow each customer to have their own settings – such as custom fields, workflows, branding, access controls, etc., configured through the application’s admin interface.

• Infrastructure as a Service (IaaS): Configuration might include selecting machine images, CPU/RAM sizes, storage capacity, networking (such as virtual private cloud settings, firewall rules), etc.
• Platform as a Service / Application as a Service: (the terminology "Application as a service" in the slides likely overlaps with PaaS) – configuration could involve choosing runtime versions, scaling rules, or enabling add-on services (like a database or caching service attached to an app).
• Software as a Service (SaaS): Configuration often involves business logic: an admin can configure roles and permissions, customize the data fields or UI, configure business rules (like approval flows in an HR system), integrate with other systems via configurable connectors, etc.
• Business Process as a Service (BPaaS): This is typically a specialized case of SaaS where an entire business process (like payroll processing, or claims processing in insurance) is offered as a service. The configuration might allow the business to tweak the process to its policies (for example, define its pay periods, approval hierarchies, compliance rules in a payroll BPaaS).
  

The principle of configurable enablement is crucial for multi-tenant cloud services. In a multi-tenant model, many customers share the same application code and infrastructure, so you can’t customize by altering the code for each customer. Instead, you build the software to be highly configurable via metadata. Each tenant (customer) can have a distinct experience and rules, set through configuration that the application reads. For instance, Salesforce (a multi-tenant SaaS CRM) allows each organization to create custom objects, fields, workflows, and even custom logic via configuration, all while running on the same core software. This principle ensures the cloud offering can meet diverse needs without creating one-off versions.

From an enterprise consumer perspective, configurable cloud offerings mean that when you adopt a cloud service, you have the power to adapt it to your processes. This reduces the need for custom development. From a provider perspective (if the enterprise is offering cloud services or internal shared services), it means designing your systems to be generic but adaptable – usually a more complex initial design, but it pays off by avoiding custom forks for each use case.

Example: Workday, as a vertical SaaS for Human Resources, exemplifies configurable enablement. Workday provides a unified HR platform for all its customers, but each customer can configure their organizational structure, approval workflows, benefit plans, performance review processes, and more, through Workday’s configuration menus. When laws or business rules change, an admin can often configure the new rule (say, a new overtime calculation formula) without Workday engineers writing new code specifically for that customer. This configurability is a big selling point for cloud software versus traditional on-premise software; it allows faster adjustments and upgrades. Another example is AWS in the IaaS space – AWS offers many configuration knobs for each service (for an S3 storage bucket, you can configure versioning, encryption, lifecycle rules, access policies, etc., all via config settings). AWS constantly adds features that expand the configurability of their offerings (like new instance types, new policy settings), showing their commitment to enabling customers to tailor the service to their needs.

When formulating a cloud strategy, ensure that the services you choose or build have this quality. If you are comparing vendors, for instance, evaluate how much you can configure the service to fit your enterprise requirements (without needing vendor professional services every time). If you are building internal cloud-native applications, prefer making them configurable (e.g., using feature flags, settings files, or policy engines) so that the same service can serve multiple scenarios.

---