Implication of $200-a-barrel Oil on Application Management

I recently read this article by Bill Detwiler of TechRepublic that increasing cost for transportation will prompt more workers to work remotely, and IT organizations should prepare to support more remote workers.

I can certainly identify with this. It costs me at least $12 a day in fuel and toll to get into the office by car, up from $5 a day just a few years ago. If I do not have face-to-face meeting at the office on a particular day, I might as well work from home. To be effective, however, I need to get good response times out of the applications that I use. This need brings up the issue of managing applications for remote workers.

As I discussed in “Comparing Application Management and Traditional Systems Management”, a key thing that IT must measure in managing applications is end user experience, as it is the ultimate measurement in the operational effectiveness of an application. Managing end user experience becomes so much more challenging when part of your extended application infrastructure lives outside of your corporate network in the forms of the public Internet and your workers’ home networks.

To manage application performance for remote workers, you need to adjust the tactics that you use for monitoring end user performance. For example, since most people have Internet connections that offer asymmetric bandwidth, you have to make sure that your applications function well in the lower bandwidth environment. You might want to test application access from remote workers’ homes to make sure that response time is reasonable. You might even want to deploy synthetic test drivers from those locations or from a monitoring service provider if a significant percentage of your workers are remote.

To make it easier to isolate application performance problems caused by external networks, you should also deploy your synthetic test drivers at key WAN entry points to your internal network. If there is an application response time problem, and you are able to determine that response time is within target from your internal access points, you can isolate the problem to the external WAN more easily.

The trend toward more telecommuting is not a new thing. Increasing transportation cost just adds another motivation for people to work remotely. With increasing globalization that requires people to access applications from their home after conventional business hours in order to collaborate with colleagues half way across the world, with proliferation of readily accessible mobile computing technologies, telecommuting arrangements will continue to become more popular. IT needs to adapt its application management tactics to help make sure that remote workers continue to be productive.

Building Application Management into Your Capacity Plan

One of the most common questions that I get asked when showing Oracle Enterprise Manager to customers is the amount of processing overhead the tool introduces to the environment. It is a valid concern. After all, you don't want a management tool that is supposed to help prevent performance problems to introduce new performance problems of its own. However, treating management as purely “overhead” may not be a productive way to think about the problem either.

First, let me state that it does take resource to run management tools. It takes CPU cycles, memory, disk space and I/O bandwidth to collect and process information about the health of an application environment. Since all these resources cost money, it means that it costs money to use management tools. But costs isn't the problem. It is whether you recuperate the costs through the benefits that the tools deliver. In other words, it is about return on investment.

What would be the alternative of not incurring the management costs? You would have to try managing the systems manually with no data. You would have to sit in front of the terminal yourself to watch everything to make sure things are working. If something breaks, you would have to take many guesses to try to fix the problems, which would probably take you much longer, forcing you to stay longer at work and missing other important things in life. Meanwhile, your application's availability goes down, your end users productivity are impacted, and your organization might even lose business because of that. Would you rather incur these costs over the 5% or even 10% of CPU cycles that you dedicate to running your shop properly?

So as you do capacity planning for deploying or upgrading an application, build in a capacity budget for management as well. You'll be glad you did.