The most important determinants to success of application performance management (APM) projects are attitude and discipline. That’s my experience, at least.
We don’t have a refined scientific theory of APM projects yet, in the sense that physics does a masterful job of calculating that a rocket launched here will land there. We never will. Like medicine and law and plenty of other important subjects, we have a body of experience that participants talk over and from which they try to derive sense.
Most of the sense isn’t specific to APM: successful projects aren’t the ones without errors, but the ones with the wisdom to recover from errors and even turn them into opportunities. Good DevOps who use good APM sometimes still end up with embarrassing spikes in response latency. If they’re truly good, though, they know to study the underlying causes after the incident ends, and adjust plans based on the knowledge gained. Errors are chances to learn and strengthen the system–or, sometimes, learn what isn’t important enough to warrant more effort.
Plenty of other fields come to similar conclusions. Gamblers, financiers, athletes, and others teach that what determines success is less often technical–a “system” or “model” or “strategy”, all of which are a glut on the market–than the personal and organizational discipline to apply some plan consistently and thoughtfully. General Patton famously expressed the military application as, “A good plan violently executed now is better than a perfect plan executed next week.”
When you deploy APM, therefore, recognize that there will be setbacks and stumbles in its use. APM has enormous potential; at its best, the results can look magical from the outside. That magic only happens, however, with a willingness to make the most of APM on a daily basis, learn from errors, reinforce successes, and maintain a focus on excellence.
All that I’ve described so far is general enough to apply to most areas of life. One aspect of a winning attitude that I haven’t yet mentioned is a passion for pertinent specifics. Good APM teams aren’t just flexible and responsive in principle: they pursue the APM-specific technical expertise that enables success. For APM, “technical expertise” is less about, for instance, making the right choice between developer-oriented and user-oriented implementations, and more about learning enough to optimize whichever of these the organization chooses. “Optimize” here means, of course, adjust to the organization’s goals–not the vendor’s, or what shows up in an analyst’s industry survey, but what is right for your particular organization. I see companies which mandate Web pages render within a second-and-a-half of a user request; others define success with a boundary at twenty seconds. A good APM team knows how to fit the specific technologies it selects to the specific resources available to meet the specific plans and requirements of its mission.
Next month, I’ll explain a few of the mistakes I’ve made, and how they resulted in better application performance.