Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

December 5, 2002

Eyes Wide Open

In this age of cost consciousness, proactively monitoring and managing strategic business apps is fundamental

by Ron Beck

For many organizations, determining a strategy for enterprise application management and monitoring has become critically important as the global recession forces businesses to constrain IT support dollars. The implementation of self-healing systems and low maintenance equipment across the enterprise is becoming a standard expectation. Today, executives aren't asking themselves, "Should I manage and monitor my strategic business applications?" Rather, the question is, "What is the cost of not monitoring or properly managing these applications?"

You don't have to look far for an answer; the indirect costs associated with downtime, which are scrupulously documented, can be staggering. Recent statistics from a New England research firm show that if just 33 percent of large business point-of-sale applications are unavailable for just one hour, the loss of revenues can range between $1 million and $2 million. If that isn't enough, that same research firm indicates that if 14 percent of large business CRM applications are unavailable for one hour, it will cause more than $1 million in lost revenues.

If you're an IT or business executive, taking a detailed look at your enterprise support organization can be very enlightening. You can discern some potentially alarming metrics by reviewing system management tools that record outages, in addition to reviewing help desk logs for reported system problems.

With distributed applications and networks as complex as ever, keeping networks and data secure and reliable is extremely important. Keeping applications tuned for optimal performance is also important; to keep them running at peak efficiency, change control and change management processes must be well defined to stop rogue application or operating system installs and upgrades that may affect application performance. Furthermore, to ensure the stability of applications, you must automate deployment strategies to ensure consistency and avoid errors caused by manual processes. Adhering to these processes (such as change management) will provide stability, reliability, supportability, and most important, manageability.

The Right Approach

Without monitoring and management practices in place, the process for determining or isolating problems in a distributed environment can be overwhelming. To maximize the efficiency for your organization, you should review the following items at a minimum: application settings and configurations; network operating system (including services such as dynamic IP address assignment, name resolution, and other services utilizing network bandwidth); network configuration (specifically routing protocols and route distribution); network interfaces and utilization; and system processes (memory, CPU, and disk).

To give executive staff and management an accurate view of the health of your enterprise strategic business applications, an end-to-end management and monitoring strategy must be in place. However, each organization interprets the big picture view in a slightly different way. Some managers consider single-component processes to be sufficient (such as viewing the Oracle server running Siebel), while others consider aggregate data points the proper way to view the environment accurately.

Arguably, looking at just one component doesn't expose all data necessary to comprehensively monitor a distributed system. To effectively monitor the environment, you must have visibility into the total performance and outage environment of your strategic business applications.

Most enterprises employ a myriad of tools, standards, and resources for this job, because most monitoring software doesn't effectively watch all application components. But the real issue behind poor or ineffective monitoring strategies isn't the tools used to oversee the applications, rather, it's the lack of good IT management fundamentals.

Your organization can realize savings by effectively monitoring strategic business applications, which doesn't necessarily require expensive tools. You can do so by first determining what service levels your strategic business applications require, which will establish the objectives of the overall strategy. Second, you'll need to determine what data should be collected to meet those service-level agreements (SLAs) to set the discrete starting points for implementation of the strategy. Third, you should build a framework that sets the standards for application management and monitoring across the enterprise. Last, deploying this framework across the organization will mitigate confusion and conflicts regarding the measurements. At the very least, this approach will reduce troubleshooting time, as data should be more readily available to staff when problems occur.

At this point, caution is in order: Make sure you can walk before you run. Getting an enterprise to agree on a set of standards that meets the goals of the entire business and includes end-to-end monitoring is a major challenge. Strategic business applications are constantly changing, service levels across business units are hard to agree on, and the number of partners involved is at an all-time high, making service levels challenging to define. So let's start there.

Defining Service Levels

Defining service levels for your strategic business applications is a good idea, regardless of management and monitoring. Your organization must have representatives for each business unit set the appropriate service levels for their strategic business applications. For example, is it imperative that PeopleSoft is available 2437? What are the maintenance windows for J.D. Edwards servers? Questions along this line must be asked to determine what service levels to define.

Service levels have been around for ages, but many enterprises hesitate to develop and track them because they inherently require time and resources. Even so, service levels are crucial for both internal and external systems. Without them, business users, IS staff, and other personnel will each assume and expect different levels of availability for specific systems. Furthermore, service levels provide visibility into the service provider, and as more and more strategic business systems run in application service provider mode, they become an invaluable tool for the enterprise.

Along that same line, Web services are dictating well-defined service levels as they are, by nature, susceptible to potential performance issues. Think about it: With Web services, you're taking an application and "Web-ifying" it to support B2B, partner, and other general communication from off-site users. By doing so, you're adding additional layers that incur the overhead of transport technologies, such as the popular SOAP protocol. Those additions can lead to performance problems if you're not careful. How do you combat this problem? Service levels, service levels, service levels.

You can define a service level as either an SLA or service-level objective (SLO). The former is a signed contract between the business user and the internal or external provider of the service. In contrast, with the latter, there's no signed contract but the provider agrees to ensure specific service levels. An SLA is typically used for guaranteeing service levels with external providers, while SLOs are used with internal service providers. SLAs give the IT organization a level of insurance. Typically, the customer and service providers negotiate SLAs to a point where each party benefits and allows for financial compensation if services aren't delivered as promised.