I understand that it's important to be proactive about monitoring performance
in order to prevent problems further down the road. But how can I find the time to be proactive,
when I'm swamped with resolving today's problems?
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
Proactive performance management is a classic chicken-and-egg problem. When you are managing
proactively you have more time to do proactive management, which is extremely frustrating for folks
that are barely keeping their heads above water.
The only way to make the transition is to put some capabilities in place to automate a lot of the grunt work that must get done to resolve today's problems. For example, attempting to recreate a Web application problem in a test lab is a time-consuming effort that usually fails. Investing in a solution that captures the problematic transactions directly from the production environment saves time doing this. Another example is augmenting an existing rules-based correlation engine with a product that automatically baselines performance and creates alarms only when behavior is abnormal. Not only will the number of alarms decline (staff will spend less time clearing nuisance alerts), but staff will also spend less time writing basic correlation rules in general.
The key with this approach is that the capabilities must slide into your existing management environment without requiring a lot of staff training and integration effort or integration maintenance. Haphazardly bolting together different products for each capability is a recipe for disaster in terms of maintaining the integration. Successfully climbing out the reactive management hole requires that each capability is selected for its time-saving value but implemented with integration and reuse in mind.
The only way to make the transition is to put some capabilities in place to automate a lot of the grunt work that must get done to resolve today's problems. For example, attempting to recreate a Web application problem in a test lab is a time-consuming effort that usually fails. Investing in a solution that captures the problematic transactions directly from the production environment saves time doing this. Another example is augmenting an existing rules-based correlation engine with a product that automatically baselines performance and creates alarms only when behavior is abnormal. Not only will the number of alarms decline (staff will spend less time clearing nuisance alerts), but staff will also spend less time writing basic correlation rules in general.
The key with this approach is that the capabilities must slide into your existing management environment without requiring a lot of staff training and integration effort or integration maintenance. Haphazardly bolting together different products for each capability is a recipe for disaster in terms of maintaining the integration. Successfully climbing out the reactive management hole requires that each capability is selected for its time-saving value but implemented with integration and reuse in mind.
This was first published in August 2008