Guiding Principles for Building a Performance Engineering-Driven Delivery Model

While recently attending a Dynatrace User Group in Hartford, I had the opportunity to sit in on a great presentation from a leading US insurance company as they explained their three-year APM journey. I see a lot of these success stories, but this one was especially impressive. To see how they have refined their internal processes, successes and performance best practices to ensure delivery of high quality, high performing and highly scalable applications over these years.

The performance engineering group within the large US insurance company was the one that started adopting application performance management (APM) in the company. Overtime they built an APM maturity model that helped them achieve successful adoption of APM across all application owners. Below is the diagrammatic view of their model:

As the diagram shows, this is an iterative model that they built from their successes and failures. For example, once they showed their service value to application owners, they started building delivery processes for their services. As their delivery processes became streamlined, they started driving awareness of their services to larger groups within the company. As the demand for their services increased, they focused on hiring strong technical personnel within their team who could not only deliver the services efficiently but also brought technical thought leadership to application owners.

The top five takeaways from their presentation were:

• Demonstrate Value: As a performance engineering group, it is very important to demonstrate value of the processes and the tools that they use to a bigger audience including architects, developers and IT operations. For instance, this group used Dynatrace tools to find scalability issues of an application during the load testing cycle. Equipped with this information, they engaged the architects and the developers of the application and brainstormed with them about the architectural choices that were made in the application. This joint working engagement not only allowed them to show value of the performance engineering team but also enabled them to engage with the architecture team early on in the development cycle to eliminate any scalability issues and hence significantly reducing the cost.
• Highlight "Wins": The charter of the performance engineering team is to work across all application teams to inculcate performance management as part of the development process. This company is very much aware that the cost of fixing an issue increases multi-fold if it is not addressed early on in the development cycle. When they started the APM initiative, it was not necessarily easy. In order to show value of their services, they used past "wins" of fixing performance issues like scalability and slow response time in one application to showcase the importance of their services to other application owners, developers and architects. The end result is that they are at a stage where the demand for their services is outpacing the supply that in turn is a great place to be.
• APM is a journey: When asked about the time taken for them to reach their performance management goals, I was told that APM is a journey and does not necessarily have a finite end. They are continuously working to not only onboard more applications but also continuously improving their methodology to make it better. As shown in their model above, as the group grew and gained maturity in APM, they used their experience to take the operating model to the next level.

For takeaways 3 and 4, click here for the full article.