Skip to content
Expertise

Post-implementation policy

Only in production can you validate software performance and its impact on business objectives, by evaluating each element after it goes live.

In a previous post, we explained that today's DevOps approach needs a new phase in the development life cycle to control the performance of software components (DevPerOps) through a continuous Performance Technical Office (OTR), and how, before components are promoted to production, certain controls can be set up to ensure minimum quality and performance standards: the promotion policy.

Post-implementation policy

However, even with rules in place in earlier environments, production is the only environment where it is possible to measure every metric and its correlation with business factors.

For a proper post-implementation policy, two basic components must exist:

1. Control over which components go into production, to know the date on which a component was added, removed or changed.

2. Correct runs of the software components after they go into production, so that changes in behaviour can be evaluated in any metric associated with the changed process.

These two points are vital to set up a control mechanism for the elements that go into production and to evaluate their impact on business processes.

Post-implementation policy

The post-implementation policy takes the following elements into account and produces an output report with an OK or NOK before the component goes into full production.

  • There will be a report on whether the element has already been evaluated in a pre-production environment (the “promotion policy”), which shows whether inefficiencies have already been fixed proactively.

  • A central team will watch the processes that, after implementation, affect any business process while consuming more than a set minimum, and the elements whose associated performance metrics increase by a given percentage compared with the previous production version.

    • ✔ If everything is correct and no threshold is exceeded, it goes into full production.

    • ✘ Otherwise, the component is sent back to the application team for review, and an incident is opened to fix the software.

  • The application team must commit to checking it within a limited time, as it falls within the provider's warranty thanks to early detection in production.

With this control mechanism, all the elements that could not be evaluated in earlier environments are detected and evaluated immediately after going into production, shortening verification time and limiting their impact on business processes.

Detecting performance problems after implementation in production also brings several benefits:

  • Ensuring the optimal performance of every software element.

  • Fixing software inefficiencies early, within the warranty period.

  • Lower costs thanks to early detection of their impact.

  • Controlling how the development cycle affects business processes (the percentage of all changes that have an impact after going into production).

  • A ranking of applications and software providers by software performance, based on the incidents detected.

Only in production is it possible to validate the performance of a software component and its impact on the client's main business objectives (costs, SLAs and response times), by evaluating the metrics of an individual element after it goes into production: post-implementation.