Your automation initiative just went live, and yet…

0 failed, 0 passed

✓

is it faster for one team to do their own job?passed

yes. every team can ship their own thing now. AI is making that even easier.

✗

is it faster for customers to consume infrastructure?failed

no. consuming still means forms, tickets, and waiting on a queue.

✗

do teams know how to build services the new path can consume?failed

every team builds to its own conventions. nothing arrives consumable and nobody is accountable for bringing it together

✗

are the responsibilities between infra and app teams clear?failed

every control nobody owns gets dumped into the design authority. reviews stay manual, and infra wears the blame for the queue

✗the new tool fixed it

expected: one process

actual: two. the old one survives every rollout, because nobody removed the reason it exists.

note: the fde you hired is maintaining both of them now.

fix the processskipped

there's no software for this step.

Most automation tooling is focused on solving the provisioning bit

But in a typical enterprise flow, provisioning is a small slice. The lag lives in everything else, and it all gets stuffed into the same flow.

100

days elapsed

Intake

2days

5days

Design defect = back to the start (+78d)

Design & approval

60days

Provision

15days

The bit IaC and agents fix

15 days of build, 40 minutes of machine time.

Release

3days

Handover

15days

100 days elapsed

Intake

Defect = back to the start (+78d)

Design & approval

60d

Provision

IaC fixes this

15d

Release

Handover

15d

Automation programs fail when they assume the complexity lives in the technology. It lives in the operating model.

Every check required to transition a service ends up in every request to infrastructure, whether you're adding a VM to a cluster or building a new capability

The result is a long, people-driven process that pulls in every party, and it's brutal when errors are caught late.

Most of these processes solve a real problem, and can't just be ripped out.

Platform programs work when they make Finance, Service Management, Service Transition and Security Compliance easier, so the infra requests themselves can get out of the way

EXAMPLE

Intake2 days

Registration5 days

Design & approval60 days

Provisioning15 days

Release3 days

Operateongoing

Publish · consumer process60 days

×N · one per consumer

Pattern defined

Modules built & tested

Published to catalogue

Owner submits request

Eligibility checked

Estimate produced

Asset recorded

Architecture review

CI created

Waiting on sign-off

Placement approved

HLD drafted

Design authority sign-off

Rework loop

Build sheet approved

Environment deployed

Smoke tested

Handover to Ops

Firewalls opened

Access granted

Go live

Monitored

Who owns the whole?

Manual copy between environments

One request, many teams

Where does a service get transitioned?

When does the customer find out what they need to do to maintain it?

Event

Command

Actor

Policy

Hotspot

System

The new strain of AI-enabled catalogues claims to fix this by auto-publishing your tools into the catalogue. They rarely publish the right things

We used to have a bad catalogue. Now we have a large one.

Our catalogue now contains services that have not been announced at re:Invent yet. I no longer get to say something is a bad idea, because by the time I've read the proposal my agent has provisioned it, documented it, and made me the owner

GM at a bank

probably

We used to have a bad catalogue. Now we have a large one.

Our catalogue now contains services that have not been announced at re:Invent yet. I no longer get to say something is a bad idea, because by the time I've read the proposal my agent has provisioned it, documented it, and made me the owner

GM at a bank

probably

So how do you build an automation strategy that actually works?

So how do you build an automation strategy that works?

Define your consumers

Standardise your services

Define one way in

Match change to its scope

Build your strategy around a few archetypes

Your customers run from teams who can spell cloud and don't care to learn, to teams who dream in Terraform. A single standard forces one of them into the wrong shape.

So split your consumers into a handful of groups and give each group its own shared responsibility line. The point of the grouping is that deviation gets decided per group, not per argument. A vendor building something to hand back gets one tier, because the handover matters more than their preferences. An internal team prototyping gets the gets a different tier, which comes with wider access but more responsibility, because speed is the point and they carry the support burden that comes with it.

Every group sits on the same controls underneath. The catalogue, identity and policy don't change when the tier does.

Your customers run from teams who can spell cloud and don't care to learn, to teams who dream in Terraform. A single standard forces one of them into the wrong shape.

Every group sits on the same controls underneath. The catalogue, identity and policy don't change when the tier does.

Digital Islands

Native

Cross Functional

Teams

Enabled

Mode 1 App Teams

Managed

Customer

Application administration

App admin

Opt In Controls

Opt Out Controls

Platform

Cloud deployments

Deployments

Opt In Controls

Platform

Workload Tenant boundaries

Boundaries

Platform

Platform Base Controls

Controls

◀

▶

Customer control & responsibility

Customer control

Workout what it means to run a service, and feed it through your workflows

It's the list of things to automate, not a document

A service design package is where the team that owns a service writes down how they intend to run it: who supports it, which controls apply, what good looks like. Nobody does this to pass audit. Every line in it ends up configured in a downstream tool, so define the shape once and every service feeds through the same workflows.

Exposed to different users

Architecture

Delivery teams

Operations

Risk & audit

Customers

Service design package

e.g. ITIL v4 service capabilities

Availability management

Business analysis

Capacity and performance

Change enablement

Incident management

IT asset management

Monitoring and event management

Problem management

Release management

Service catalogue management

Service configuration management

Service continuity management

Service design

Service desk

Service level management

Service request management

Service validation and testing

Configured across many tools

Service management

catalogue, support model, CMDB

Observability

SLAs, SLOs, alert routing

Policy & controls

control mappings, exceptions

Automation

templates and parameters

Documentation

customer and ops views

Define one way in, and one way to change things

One way in, one way to change things

The platform is explicit about three things: how services are exposed, how change is made, and how the things teams build get wired in. Customers arrive through one route, an engine executes change across every service, and the teams underneath publish what it runs. Three layers, each built for the layer above it.

Engineers

PMs

Architects

Operations

Consumer Portal

Catalogue

Requests

Blueprints

Policies

SOPs

Orchestration, Policy & Execution Engine

Workflows

Policy

Exceptions

Approvals

Identity

Distributed Service Definitions, Templates & APIspublished by the teams themselves

Cloud

Network

Security

Identity

DevOps

Scope Automation around your org model.

One definition, an entire estate

Platform level change scales better when it's scoped around who it affects. Then you can build automations that ensure that adoption can be retrospectively applied at scale, with policy that inherits down, and exempts up.

1. Change is bundled by scope

Core

Agency

Agency environment

Team

Business application

Application service

SDLC component

Workload

The lower in the stack, the more frequently the template is executed.

2. Mapped to the resources that implement it

Azure spoke VNET

AWS SCP agency policies

AWS spoke VPC

Azure policy agency policies

3. Released to each instance of that scope, ring by ring

Ring 0

Digital AWS VPC

Ring 1

Marketing AWS VPC

Geotech spoke VPC

Ring 2

Revenue spoke VPC

We've done it before, let us help you

Rory Chatterton

Principal and founder, Wayvz

Fifteen-plus years building at enterprise scale, across retail, banking, financial markets and government. I built and ran the cloud-automation function inside a national retailer, and have been helping others ever since.

Wayvz is principal-led. I do the thinking and the building, with a hand-picked network of senior specialists when the work needs scale. No bench, no juniors, no partner who vanishes after the pitch.

Huge IaC Environments

The largest Terraform and Vault fleet in APAC at the time (2018–22). Built it, ran it.

1000+ Apps Migrated

Applications migrated and run on platforms I delivered

33 years, per year

shaved off every login across a global enterprise, by tuning the layers nobody looks at

From Plan to Run

Business case, service design, build, then the enablement to run it. I've carried services through the whole lifecycle, not one slice of it.

Portfolio Roadmaps

Roadmaps defined and delivered for large portfolios of projects, executed across multi-disciplinary teams.

From 0 to Won

Automation portfolio's built from the ground up, from what is git, to same day provisioning.

Contact Us

Get in touch with Wayvz! Whether you have a project in mind, want to collaborate, or simply say hello, please don't hesitate to reach out.

(Contact)

[email protected]

(Address)

6 Middlemiss St, Lavender Bay, NSW 2060, Australia

Wayvz Pty Ltd ABN 76 678 816 601

Wayvz Group Pty Ltd ABN 41 683 097 789

Wayvz Pty Ltd ABN 76 678 816 601

Wayvz Group Pty Ltd ABN 41 683 097 789

Wayvz Pty Ltd ABN 76 678 816 601

Wayvz Group Pty Ltd ABN 41 683 097 789