Should the APM tools be integrated with ALM tools? And if so, how?
It is odd how the words of our mentors continue to haunt us decades after their wisdom was delivered. My first chief programmer once said to me, “If it isn’t fast enough, small enough and easy to maintain, it doesn’t pass.” Never has that been truer than today, when we are once again trying to deliver sophisticated solutions to topology limited platforms.
Today’s application lifecycle management (ALM) tools provide us with an infinite array of capabilities that help us meet the execution needs of the target environment. However, once delivered, the app is on its own in a dynamic, changing environment. This is where application performance monitoring (APM) tools provide us with the ability to create early warnings of changes in behavior that put the application outside its desired performance profile.
It has long been our habit in IT to follow the adage, “if it ain’t broke, don’t fix it.” With APM tools available to us, it is now possible to redefine what “broke” means and switch from the reactive break-fix mode to being proactive, timely, intervention mode. Obviously, when an application fails we need to step in and fix it. But what happens when an app slows over time, has unaccountably poor response time on Wednesdays and takes longer to start after a database reorganization? Is the app broken? Of course not. And the symptoms may not be symptoms of an imminent failure either. But something in the environment has changed, and this is having an impact on the application and the users who depend on it.
When applications start to operate outside their normal parameters, it is time to act. Using the APM early warning capabilities to automatically open investigative tickets in the development team’s inbox is a minimum level of integration that we should seek. The diagnostic capabilities of these tools mean that much real-time evidence of the change can be delivered to the developers to speed their diagnosis and remediation of the issue.
If it is determined that a code change is responsible for the new performance behavior, then using the end-to-end traceability of modern ALM tools, it is possible to identify the who, when and where of the change. This is not for any “blamestorming,” but to allow for process review and tool reengineering, preventing similar errors being from made in the future. This level of integration and process remediation is only possible when large contiguous portions of the software development lifecycle (SDLC) are automated.
Many events can undermine the performance of an application. Early detection, diagnosis and remediation mean that apps can be fixed before they fail. Uptime and availability are no longer a goal-- when was the last time you heard anyone talk about “six nines?” They are the de facto reality. We must do anything we can to ensure it. Integrating our APM and ALM tools is one thing we can do today.
For a comprehensive resource on continuous integration, see Continuous integration: Achieving speed and quality in release management.
Dig Deeper on Topics Archive
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