most investment decisions are driven by the benefit and return we expect to get from the money we invest. the operating cost of the service is the half of that equation that tends to be missed.
businesses fund projects from the build-and-deliver budget. once the project closes, operational costs migrate into a different line of the P&L — usually a less generous one. budgets sized only to the build leave the operating organisation under-resourced before the service has even gone live.
opsasto's budget assurance is one question, asked early: what does this cost to run, fully loaded, for the first three years? once you can answer it, you can sign the build.
an architecture optimised for the day of go-live is rarely the architecture that should run on the anniversary of go-live. design for the second year and the first will follow.
the cost of resolving an architectural issue grows quickly once a service is in production — measured in re-platforms, breaking changes, and the politics of explaining what went wrong. the architecture assurance is the practice of putting non-functional and operational considerations into the same room as functional ones, before the design is signed.
the support model describes how support needs are fulfilled, which functions are available, and who provides them. it also surfaces stakeholder priorities and aligns their views before an incident does it for them.
opsasto runs a support model workshop on most engagements — a structured half-day where the people who will run the service in the dark agree what they need from the people who built it in the daylight. the output is a one-page model and a rota.
the first three people on a new service know everything because they built it. the tenth person joins six months later and inherits whatever was written down. the practice of knowledge assurance is the practice of writing it down well.
knowledge isn't documentation. it's the union of runbooks, architectural diagrams, decision logs, named owners, and the small body of unwritten conventions that hold a team together. when a service changes hands, the unwritten conventions are the ones that fall on the floor first.
sourcing activities are the first steps on a path of a mostly long-term and close relationship with a service provider — and the first opportunity to exchange expectations, verify assumptions, and build a common understanding of the agreement being put in place.
contracts written for procurement read differently than contracts written for operations. the contracts assurance is the practice of writing service-level commitments, change-control clauses, and exit terms in language the ops team can actually invoke at 09:00 on a tuesday.
incident, change, problem — three processes that every service eventually needs and that every team eventually argues about. the process assurance is the practice of agreeing the smallest version that works, before the service goes live, and then rehearsing it.
itil processes still have value in a devops world. the value is not in the artefacts; it's in the shared language of what an incident is, what a change is, and what a problem is. when those words mean the same thing across a team, the process can be small.
trias politica — the separation of powers — is a quietly elegant idea borrowed from political philosophy. for IT services it shows up as separation of duties between those who design, those who operate, and those who audit. one heroic admin with every key is a liability; three named roles with three sets of keys is a service.
this is the chapter where opsasto talks about identity, access, change control and audit in the same breath. the goal isn't to multiply gates; it's to put the gates where the risk is, and to keep them invisible the rest of the time.
the lifecycle of a service stretches far past the point where the delivery project finishes. the cutover period is the bridge — and the objective is to ensure that the service that has gone in production fulfils its users' expectations and that the organisation can deliver the needed operational quality.
cutover is, in practice, the only chapter the audience reads. it's where every other chapter is tested — does the budget hold, does the support model run, do the contracts fire, do the runbooks make sense in the dark. the cutover plan is the master schedule for proving that everything else is true.
a structured walk-through sized to your project's risk, with a deliverable you can hand to your sponsor on friday. used in waterfall as work-stream deliverables, in agile as product-backlog items and definition-of-done.