Should the APM tools be integrated with ALM tools? And if so, how?
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
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.
This was first published in August 2011