IT Ops frequently emphasizes that successful application performance management (APM) follows careful analysis of requirements. There’s a positive message in that we often neglect: APM belongs lots of places it hasn’t been used yet.
Over the last year, many APM headlines have been negative: the sector is pulling back, traditional solutions are in decline, APM only belongs on a subset of a department’s portfolio, and so on. I applaud Ryan Shriver’s “APM for Agile and DevOps: 7 practical use cases“, though, for concrete illustrations of new ways to take advantage of APM.
The crucial observation behind Shriver’s write-up is that once a team understands APM and the particular product it has at hand, that product can be applied to interesting problems throughout IT (information technology). First example: don’t wait until the end of development to attach APM “after the fact”, but build it in on the first day of a new project. APM can go to work on the very first lines of code, and has the potential to alert the team to problems and, even more, educate them about alternatives, throughout the development cycle. That extension of the effective use of APM in time multiplies the benefit it delivers in proportion to that additional time.
The case of analysis
Shriver’s second example also cleverly amplifies results: analysis invariably struggles to express non-functional requirements such as performance in a consistent and meaningful way.
Deployed APM solves that problem: simply use the APM product’s dashboard as a format to communicate meaningful requirements. Consistent reference to the product saves administrative time in conducting an analysis at the beginning of a project, and coding and integration time during quality assurance and deployment.
You owe it to yourself to read all of Shriver’s article: he shows how APM can pay off throughout the product lifecycle, and in several different aspects of IT. To put this into practice pays off bigger than you might expect; as Google optimization specialist Laurent Perron, quoted in “Issues Are Not Where One Thinks They Are“, observes, only 5% of a project is “solving the problem” in a classroom sense. Most of work is figuring out the right dataset, the right audience, and so on. When APM, and especially a particular modern APM product, provides a common language and reference point for all performance discussions, a whole project becomes more efficient.
Crossing departmental or functional boundaries is not the only novel way to make the most of APM. Next week Real User Monitoring will report on new uses of APM in on-line gaming.