Practice/The Eight

The Eight.

The Opsasto methodology identifies eight assurance areas. Every Opsasto line-item in a project plan can be related back to one of them. The activities, deliverables, and the scrutiny applied are sized to the project and the risk of a security or reliability incident.
01
1
Budget

Ensure the end-to-end, multiyear operational costs are clear, and how these costs will be (re)covered is known.

02
2
Architectural Assurance

Verify that the service can deliver on the non-functional requirements through test, simulation and production verification.

03
3
Support Model

Design and implement an end-to-end support model — the functions, the SLOs, and the providers.

04
4
Knowledge Capturing & Transfer

Ensure documentation required by support teams is in place, accessible, and can be found. Training has taken place.

05
5
Contracts

Ensure that SLAs, OLAs, 3rd-party support contracts, SOWs and any other contracts needed to deliver the end-to-end service are in place.

06
6
Tooling & Processes

Design and implement relevant support tools and processes — sized to the service, agreed across the support model.

07
7
Information Risk Management

Verify that required IT controls are in place and are working as expected. Design effectiveness tested before go-live.

08 · Go-Live
8
Cutover Plan

How, after Go Live, support is transferred from the project organisation to the support organisation, and the criteria for operations to accept operational accountability.

1// Budget

The operational cost, made visible.

Ensure the end-to-end, multi-year operational costs are clear, and that it is known how these costs will be (re)covered. Most investment decisions are driven by the expected benefit and return; the operating-cost half of the equation is the one that tends to be missed.

// Looks for

Read the canonical write-up →
2// Architecture

Non-functional requirements that hold.

Verify that the service can deliver on the non-functional requirements through test, simulation and production verification. The non-functional behaviour is what the operations team lives with for years; getting it right at the design stage is significantly cheaper than fixing it in production.

// Looks for

Three Golden Rules for NFRs →
3// Support Model

The end-to-end support model.

Design and implement an end-to-end support model that describes the functions, the Service Level Objectives, and the providers involved in delivering the support for the service.

// Looks for

The Support Model Workshop →
4// Knowledge

Documentation, findable; training, done.

Ensure documentation required by the support teams is in place, is accessible, and can be found. Ensure training of users and support teams has taken place.

// Looks for

About Opsasto →
5// Contracts

SLAs, OLAs, SOWs — in place.

Ensure that SLAs, OLAs, 3rd-party support contracts, SOWs, and any other contracts needed to deliver the end-to-end operational service are in place.

// Looks for

Sourcing for Operational Readiness →
6// Tooling & Processes

Tools and processes that fit.

Design and implement relevant support tools and processes. The value of the ITIL processes is in the shared language they impose — when "incident", "change" and "problem" mean the same thing across the team, the process can be small.

// Looks for

ITIL in DevOps — a short rant →
7// Information Risk

Controls in place, design effectiveness tested.

Verify that required IT controls are in place and are working as expected (design effectiveness tested). Trias politica — the separation of design, operate and audit — is the quietly elegant principle behind it.

// Looks for

Trias Politica of Information Security →
8// Cutover Plan

From project organisation to support organisation.

A plan that describes how, after Go Live, support is transferred from the project organisation to the support organisation, and the criteria for operations to accept operational accountability.

// Looks for

The Service Cutover Plan →

Most engagements start with
a one-day review of the eight.

A structured walk-through sized to the project’s risk. In waterfall, the eight appear as work-stream deliverables. In agile, as product-backlog items and definition-of-done criteria.

Request a Review Read the writing →