Are APM tools used for testing or for monitoring performance?
On days when I am feeling a little rebellious, I like to pose odd questions to IT executives to challenge their thinking about how we develop software. One of my favorites is, “Why do we manually execute the automated test suite?” It does seem ironic to me that test automation is a largely manual task.
Along those same lines, I frequently ask the question, “Why do we give the testing tools to a separate QA group when they are neither responsible for creating the bugs nor able to correct them?” It has long puzzled me that we continue to allow developers to hand over code that has not been fully tested when we have in our power the ability to rigorously exercise the functionality and operationally test the executables before they end up in the hands of the quality and release management teams.
As the velocity of development accelerates, and the number of simultaneous development streams increases to an almost unmanageable extent, we have orders of increased magnitude and complexity added to the development process. With this, we have the introduction of significant risk, and much loss of the traditional control we have exerted over application delivery activities in the past. Additionally, we are responsible for ensuring applications are both functionally correct and that they continue to perform in accordance with the topology and chronology constraints they have. Never before have we been so constrained by methodology and regulations. So it is no wonder then that we struggle to keep quality, delivery times and cost under control.
We all know that the earlier errors are detected, the cheaper they are to remediate. So the answer should be obvious-- automated testing needs to move further up in the lifecycle, and that includes application performance monitoring tools.
Of course, more tools earlier in the lifecycle means more licenses and a potential bonanza for the software vendors. But contrast this with cost of remediation of a production outage and the consequent commercial losses as a result of that outage. Even a reduction in service levels today may have massive financial impact and, in some case, legal implications and adverse effects on the corporate reputation.
“Automate, automate, automate!” I heard George Laurie of Forrester say recently. He’s right. We have the technologies we need to bring the same rigor to application delivery for ourselves as we have been delivering to our very own finance, HR, warehousing, manufacturing, lab, sales and every other department in the organization. If we can build systems that are accurate to the penny every second of the day through automation of the processes in our finance department, we can surely turn that same skill set on our own processes.
We have extraordinary tools today for monitoring the performance of an application in production. We should turn those tools loose on the development team.
Discover new details about the New Relic APM
Dig Deeper on Application Lifecycle Management Tools and Processes
Related Q&A from Kevin Parker
Add controls to the business of delivering software, and teams will scream about delays. However, fast development is often the result. Continue Reading
Kevin Parker discusses the pros and cons of industry analyst reports and advises when it might be best to trust your own instincts. Continue Reading
Actually, application development veteran Kevin Parker says ALM is really a part of the APM process when you look at it from a distance. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.