IT OPERATIONS — BEYOND RUN
IT Operations is still often reduced to Run. That view begins too late.
The purpose of Operations is not simply to keep systems running or to restore them after an incident. It is to help ensure that the right service reaches the right user at the right time — with the expected level of performance, availability, resilience and support.
That is the Service Promise.
But a service does not suddenly become operational when it reaches production. It is designed, introduced, operated, maintained and improved. Decisions made at every one of those moments influence whether the promise can be kept later.
Operations therefore has something to contribute throughout the entire service lifecycle.
Not by owning every discipline. Not by adding another approval gate. But by bringing operational knowledge into the decisions that shape the service.
DESIGN THE SERVICE FOR OPERABILITY.
The first operational questions should be asked while the service is still being designed — not at the end of the project, when someone finally asks what needs to be monitored.
Designing a service for operability means defining the conditions required to operate it throughout its lifecycle:
- The operational model and ownership.
- Support and escalation paths.
- Observability and monitoring.
- Service levels, capacity and resilience.
- Operational procedures and requirements.
This is where Support by Design begins.
It is also where Business Observability starts. Before choosing signals or dashboards, we need to understand what the service is expected to deliver, for whom and under which conditions. Otherwise, we risk monitoring technical components without knowing whether the Service Promise is actually being fulfilled.
Operational readiness is not a document produced just before go-live. It is a quality of the service that must be designed from the beginning.
PRESERVE OPERATIONAL INTENT THROUGH DELIVERY.
A service can be well designed and still become difficult to operate if its operational intent is lost during delivery.
Transition and Change are where design decisions become real operational capabilities.
- Is the service ready for production?
- Can it be deployed and released safely?
- Are support teams prepared?
- Are monitoring, escalation and recovery mechanisms available?
- Can change be introduced without compromising operability or resilience?
The objective is not simply to move a solution into production. It is to introduce a service that can be understood, supported and sustained once the project team has moved on.
OPERATE THE SERVICE — NOT ONLY ITS COMPONENTS.
Run is the most visible part of IT Operations. But it is only one part.
This is where teams operate the service day to day: monitoring its behaviour, detecting meaningful events, responding to incidents and supporting its users.
The quality of Run depends heavily on what was designed earlier.
If service boundaries are unclear, alerts lack context. If dependencies are unknown, impact is difficult to assess. If recovery expectations were never defined, teams have to invent them during an incident.
Run should not begin with discovering how the service works. It should apply and continuously enrich the operational knowledge built across the lifecycle.
The goal is not merely to keep every component green. The real question is whether the service continues to deliver what its consumers need.
KEEP THE SERVICE RELIABLE AND SUPPORTABLE.
Services change even when their business purpose remains the same.
Technologies age. Capacity needs evolve. Components require patching and upgrades. Configurations drift. Dependencies change. Obsolescence introduces new risks.
Maintaining a service means keeping it reliable and supportable over time through:
- Maintenance and patching.
- Upgrades and lifecycle management.
- Capacity and performance management.
- Configuration management.
- Obsolescence management.
These activities are sometimes treated as purely technical work. But they directly influence the Service Promise.
Maintenance is not separate from value delivery. It is one of the conditions that makes sustained value possible.
TURN OPERATIONAL EXPERIENCE INTO BETTER DESIGN.
Operational experience creates knowledge.
Incidents reveal hidden dependencies. Problems expose structural weaknesses. Repetitive manual work reveals opportunities for automation. Performance issues show where assumptions no longer match reality.
Improvement turns that experience into a better service and a better way of operating it.
This includes Problem Management, root-cause analysis, reliability improvement, automation, toil reduction, performance optimisation and better observability.
But improvement should not stop at fixing today’s operation.
What is learned while running, maintaining or improving a service should influence how its next version is designed and changed.
Otherwise, the organisation learns — but the service lifecycle does not.
THE RIGHT RESOURCES FOR THE REQUIRED SERVICE LEVEL.
Across these five moments, Operations carries another responsibility: using resources wisely.
IT services rely on human, physical, digital, financial and energy resources. The objective is not simply to consume less. It is to allocate the right resources to the required service level and avoid unnecessary consumption.
This is where cost and Green IT become part of Operations.
Not by deciding what the business needs or which capabilities should exist, but by ensuring that services are appropriately resourced, efficiently operated and sustainably maintained.
Reliability, performance, resilience, speed, control, cost and sustainability must be balanced around the Service Promise.
FIVE MOMENTS. ONE OPERATIONAL SYSTEM.
Design. Transition & Change. Run. Maintain. Improve.
These are not five disconnected territories. Together, they form a continuous operational loop.
DESIGN → CHANGE → RUN →
MAINTAIN → IMPROVE →
BACK TO DESIGN.
The loop closes only when learning can cross organisational boundaries: when an incident can influence a design decision, when maintenance risk can shape a future architecture, and when user experience can change what the organisation measures.
That does not happen automatically.
It requires clear ownership, decision rights and an operating model capable of keeping different disciplines aligned around the same Business Promise.
This is where Operational Architecture becomes useful.
Not as another framework or another architecture discipline, but as a way to connect the operational capabilities required to design, introduce, operate, maintain and continuously improve a service.
BEYOND RUN DOES NOT MEAN OPERATIONS SHOULD OWN EVERYTHING.
It means that operational consequences are created throughout the service lifecycle — and operational knowledge needs to be present wherever those consequences are shaped.
Architecture provides intent. Engineering turns it into a working solution. Service Management creates sustainable practices. Operations brings the knowledge required to keep the Service Promise real over time.
The objective is not to make Operations larger. It is to make the service more operable, more resilient and more useful to the people who depend on it.
IT Operations is the art of delivering the right service, to the right user, at the right time — throughout the entire service lifecycle.VANESSA GONÇALVES · OPERATIONS LAB
HOW DOES OPERATIONAL LEARNING INFLUENCE YOUR NEXT DESIGN DECISION?
Vanessa is continuing to explore how operational knowledge, service modelling and Business Observability can make the Service Promise visible throughout the lifecycle.