BOA 1. Centralised workflow

The DevOps philosophy of collaboration between technology teams is on the rise, thanks to the benefits it offers in bringing together development and operations departments in the technology world. However, this methodology is not enough; in fact, there are already terms such as DevSecOps, where security is built into the whole software life cycle.

In the world of application performance, there is no strategy that continuously and non-intrusively meets the needs and objectives of the business departments of technology companies, one that links their objectives to the software code and shows how poor programming without a performance focus affects their main objectives:

• Operational costs: costs associated with the technology infrastructure.
• Business:
  • Data delivery (SLA): meeting the target time in overnight processes.
  • Response time: control of the user experience and the excellence of the services offered.

The methodology that solves this lack of visibility is called DevPerOps. It essentially brings the concept of performance into the classic DevOps cycle, gives it a business view and adds it to an organisation's development life cycle as a new phase.

When software components are running in production and fully operational, it is time to capture their metrics to learn how these elements affect business objectives through continuous monitoring. This is where BOA helps us centralise the whole workflow of a continuous Performance Technical Office (OTR).

Detection and analysis – OTR team

Once a candidate or an inefficiency is detected in a software element (“Registered candidate”) that affects any of the business parameters, according to the criteria set in the algorithms and the adjusted thresholds, it is assigned to an analyst for resolution. Depending on its origin and the information available, the analyst will either discard the process or prepare a technical design (“Pending recommendation”). This design contains all the information needed for the change to be made successfully: the changes in as much detail as possible, down to the line of code, the cost of making them, and an estimate of the savings to be achieved.

Approval – Client OTR manager

Once the document is ready, it is assigned to the client's OTR manager for approval of the design. This is an intermediate step in which the client confirms that the design serves the project's objectives and that the expected ROI (cost vs. savings) meets the organisation's standards.

Development – Applications (providers)

Once the client approves the design, the document is sent to the people responsible for the application, who must make the proposed changes. The development provider can count on the OTR for any questions or support it needs from Orizon. The application team must also tell us the planned implementation date and the final number of hours it took to make the changes.

Measurement – OTR team

Finally, once the changes to the software elements have been promoted to production, they are measured with the same metrics used to detect the process at the start of the workflow, to compare before and after. With this data, BOA automatically generates a chart and sends it to everyone involved in the circuit (the OTR team, the client OTR manager and the application team), so that all of them know the results achieved.

All these phases are fully integrated into BOA, so you can see which candidates or recommendations are at each point of the continuous performance watch, and keep real-time control of a Performance Technical Office (OTR).