Having worked on both sides of the apparently invisible dividing line between Delivery and Operations, I have heard and debated both perspectives on operational readiness requirement.
We can debate about it eternally. I, stand by the need for it, heart and soul.
What is Operational Readiness?
This is a typical Agile software development model.
This is a typical Waterfall model.
In an Agile world, we expect changes coming out of a release or issues found in a system to be factored into the next sprints and prioritized. They do go into the backlog but when and how they will get prioritized is governed by a multitude of factors.
What I find missing in the Agile flow is “Maintenance” or “Support”. No matter which methodology we choose to “Support”: A dedicated operations team or You Build It You Run it. The application and the infrastructure it lives on needs maintenance. We need people to maintain it.
Operational readiness is ensuring the application has met the maintenance requirements. It defines parameters that should be checked to ensure the non-functional requirements are met. In addition, there are some key operational requirements:
· Monitoring and Alerting
· Incident Management basis the priority and category of the application
· Maintenance/support documents
· if there are third party applications involved in the project then the relevant contacts and relationship
· In a project which involves a stream of integrated applications, who owns the individual applications. Who will be supporting when an incident occurs within the chain? How is the communication managed?
· Security requirements
· Service Level Agreements
· Disaster Recovery
· Configuration Management
Operational Readiness is rightly termed as a requirement.
Why do we need Operational Readiness?
As I mentioned above irrespective of the delivery methodology, an application once shipped needs to be supported. The technology and process maturity in an organisation shapes how the maintenance works. Nonetheless, it needs maintenance. It needs support.
Incidents happen and they need to be resolved. SLA’s need to be met.
How well we avoid incidents, how well we anticipate an incident, how well we resolve them before they happen and how well we respond when they do happen — is defined by operational readiness.
Why is it considered a blocker? The other perspective.
A project has timelines and budget constraints. There is plethora of constraints in delivering a project. Having to check off things that can seemingly be done later, having to check off things that essentially are not part of the functional requirements, having to check off things that seem more focused on “process” rather than actual development — doesn’t seem like an appealing choice when projects are meeting timelines and budgets.
When you look at the operational readiness requirements, one would think these are a no brainer and would be incorporated by any project. Ask the people in your organization who support the applications, they will be able to provide an accurate assessment of how ready the shipped applications truly are.
How can we make it work together?
DevOps — Delivery and Operations as one. DevOps adds the “Maintenance” to the Agile flow.
The shift in mindset is essential. When I say DevOps I do not mean a set of tools. Instead using the right tools and processes to ensure we make maintenance and operations as smooth as possible for everyone involved.
Operational readiness should be factored in when designing the requirements. In an Agile world, it should be incorporated in the Definition of Done. These requirements should be part of the delivery culture.
Unless we understand what “Ops” means in DevOps, we cannot operate as one, we cannot be a DevOps model of work.
Operational readiness should not be a requirement but a mindset in theory.