The Second Key to IT Change Management: Understanding The Impact of Application Changes

In my last post we discussed the importance of understanding your application topology and how vital it is to effectively managing change:

Today, I’m going to expand on this point by discussing the impact of application changes to IT stakeholders. Clearly, any smart, curious and capable IT pro will want a complete understanding of the application changes they’re making. The key issue however is to understand the impact before pushing them live into production. Also, thanks to the law of unforeseen consequences, a worthy goal should be to minimize any surprises.

When testing in UAT,  you need to make sure you have as accurate a comparison as possible. So, when things don’t go as expected you can accurately diagnose and remedy problems. A complete picture of cause and effect will be necessary to succeed.

Let’s look at load testing as an example.You’re about to release a new application in your UAT and you pump in 1000 “users” to measure the change in response time. The load testing tool gives you the difference quite easily. Let’s say the change in response time goes from 1 second to 1.5 seconds. Pretty pedestrian stuff. However, more important than the what, the actual difference in response time, is the why, as in why exactly is this slowdown happening?

Another example is improving application performance  Perhaps you want to optimize the search functionality of a specific application. You can optimize at the application level by moving some of the load to the database. In effect, you gain improved performance at one level for decreased performance at another. These manifestations are troubling, perplexing, and require a lot of time and attention to fix. The law of unintended consequences rears it’s ugly head again.

These examples point to the importance of getting a full understanding of the cause and effect in applications changes. Some tools simply don’t give you the granularity that you need. This is why IT pros should strongly consider having production ready analysis.

With production ready analysis, you’ll be able to detect and isolate problems in the testing stage which would otherwise go unnoticed if you’re just monitoring hardware components, looking only at the code, or load testing. Testing with this type of analysis ensures what happens in UAT does in fact happen in production. Or, that whatever problems are discovered in UAT are understood and corrected 100%. That way you don’t have to waste time dealing with surprises.

When conducting change impact analysis, rolling out new applications, or simply trying to improve application performance, make sure you have production ready analysis capabilities available to gain full insight into cause and effect across your application components.