Your Service Catalog Will Become a Mess. Here's How to Prevent It.

Everyone wants self-service cloud. Developers want to spin up resources without waiting on tickets. Finance wants to track costs. Security wants guardrails. Platform teams want to stop being a bottleneck.

The problem is that most implementations turn into a mess.

The service catalog becomes a tangled web of workflows, scripts, and manual steps. Adding a new offering takes weeks. When something breaks, nobody knows which layer failed. Costs drift from requests. The CMDB is perpetually out of sync.

We've found that the key to avoiding this is strict separation of concerns. Not one monolithic workflow that does everything, but four distinct layers with clear responsibilities and failure boundaries.

A well-designed self-service provisioning system separates into four layers:

Each layer has its own failure modes and its own controls. When something goes wrong, you know exactly where to look. When you add new capabilities, you know exactly what to change.

This is where users interact with the system. In most organizations, this means ServiceNow, but the principles apply to any service management platform.

The request layer is about policy and process, not technology. A user selects a VM size, enters a project code, and submits. The workflow validates required fields, routes to the appropriate approver based on cost or data classification, and only when fully approved, hands off to the next layer.

The key principle: a request doesn't trigger automation unless it's valid and approved. Bad data gets caught here, not three layers downstream.

This layer bridges the service management platform and the automation system. An approved request becomes a pipeline run with parameters.

Typically this is a REST call from ServiceNow to Azure DevOps or GitHub Actions, passing the request parameters as pipeline variables.

The key principle: failures here are visible and contained. If the pipeline can't start, the request system knows immediately. Nothing partially deploys. Nothing silently fails.

This is where infrastructure actually gets built. Terraform or Bicep templates execute against the cloud provider.

The IaC templates are opinionated by design. A "Standard VM" pattern includes encryption, diagnostic settings, and required tags. The requester doesn't decide whether to enable encryption. The pattern enforces it.

Pre-Deployment Validation

Before any resources are created, the pipeline runs validation:

1. 1Terraform plan / Bicep what-if: Shows exactly what will be created or changed
2. 2Policy compliance check: Confirms the planned resources won't violate Azure Policy
3. 3Cost estimation: Tools like Infracost compare projected cost against approved budget

If any check fails, the pipeline stops. Nothing deploys. The request is marked as failed with a clear explanation.

The key principle: idempotent, fail-fast execution. If something goes wrong, you can re-run safely. State is tracked. Partial deployments don't leave orphaned resources.

Deployment isn't the end. This layer confirms success and maintains traceability over time.

The key principle: callbacks happen on success only. The CMDB doesn't get a record for a half-deployed resource. Cost attribution doesn't start until the resource is confirmed.

The Traceability Chain

When this layer works correctly, you have an unbroken chain:

Every dollar of cloud spend traces back to a request, an approver, and a cost center. No orphaned resources. No mystery charges.

The temptation is to build one big workflow that does everything. User submits, workflow approves, workflow calls Azure, workflow creates CMDB record, workflow sends email. All in one.

This works until it doesn't.

Problems with monolithic workflows:

• Debugging is hard. When something fails, you're stepping through a 50-node workflow trying to figure out which API call timed out.
• Changes are risky. Touching the approval logic might break the deployment step. Adding a new offering means copying and modifying the whole thing.
• Ownership is unclear. Is the ServiceNow team responsible for the Terraform templates? Is the cloud team responsible for the approval routing?
• Testing is expensive. You can't test the IaC patterns without running through the whole request process.

Benefits of layered separation:

• Clear failure boundaries. Layer 2 failed? Check the API integration. Layer 3 failed? Check the Terraform.
• Independent evolution. Change the approval chain without touching the templates. Add a new IaC pattern without modifying ServiceNow.
• Defined ownership. ServiceNow team owns Layers 1-2. Platform team owns Layer 3. Both own Layer 4.
• Testable in isolation. Run Terraform plans without a ServiceNow request. Test API integration without deploying real resources.

A well-layered system makes adding new offerings straightforward:

1. 1Platform team develops the IaC pattern: Terraform or Bicep, tested in isolation
2. 2Pattern is reviewed and merged to the infrastructure repo
3. 3ServiceNow admin creates a catalog item with variables that map to the pattern's inputs
4. 4Pipeline is configured (or reuses existing parameterized pipeline)
5. 5Pattern is available in the catalog

The ServiceNow work is minimal because it's just collecting inputs. The heavy lifting is in the IaC pattern, which can be developed and tested independently.

A typical request flow:

Time from submission to running resource: minutes, not days.