This post is the second of my series concerning the performance engineering maturity model (PEMM). In the first, I’ve introduced the overall idea, and now it’s time to get in more detail.
Whenever an application doesn’t fulfill performance requirements, it’s clear that something went wrong and the root-cause analysis can be very challenging. Based on my experience a proactive approach is much better because this gives confidence and prevents you from frustrated users due to not responding applications.
As already mentioned in my previous post I’ve created a performance engineering maturity model which provides the required transparency about best practices in this discipline. Obviously, there is no need that all companies reach the highest level in all available performance engineering subjects. Therefore, I use a maturity level based approach which allows a tailor-made adoption and improvement over time. In this post, I will outline the three domains and nine practices of this maturity model.
The 3 Domains
I’m convinced that only a lifecycle performance engineering approach will help companies to reach acceptable user experience. Therefore, I think it’s essential that performance considerations must become part of every stage in the development chain. Those businesses who build high responsive applications consider performance from day one in their development process, they verify performance requirements on pre-production stages and continuously monitor and improve performance metrics on production. Summarizing this, the three domains of the performance engineering maturity model are: build, test and operate.
The 9 Practices
There are nine performance engineering practices, and each is divided into the three maturity levels.
Build domain: The biggest proportion of performance issues are related to failures in software design and implementation. Therefore, integrate non-functional aspects in your early design and development considerations. The three practices of the build stage are:
- Early performance analysis
- Standards and metrics
- Design for performance
Test domain: High latency or peak load patterns can result in unsatisfied response times. Some applications behave totally different during concurrent user situations. The failure range goes from slow loading pages to crashes of the entire system. Obviously, the risk related to ignoring non-functional testing aspects is too high and therefore the performance engineering practices in this testing domain are:
- Single user performance checks
- Realistic multi-user checks
- Test boundaries
Operate domain: Successful organizations are proactive. They know how to derive business decisions based on their most valuable assets, their customer impact metrics. The operational performance engineering practices includes the following
- Detection of slow running requests
- Collection of performance metrics
- Performance metrics drive business decisions
There is more to come…
In a subsequent post, I will outline the 27 practices of the performance engineering maturity model followed by another post about how you can calculate your maturity level in this discipline.