Eyes Wide Open

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

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.


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.

In fact, Gartner Group has proposed a "services investment" model, based on the various factors that cause downtime. For example, under this model, committing 20 percent of available IT funds toward service contracts, monitoring, and redundancy can provide the business with an insurance policy to protect it from loss of revenue.

SLAs include terms and conditions of services including specific metrics, responsible parties for service delivery, exceptions, financial adjustments, termination clauses, and general objectives. If SLAs aren't well defined, they can create disagreements between the parties that develop into failed delivery, contention, refunds, or disagreement on terms of service. To prevent these problems, you should discuss SLAs with your legal staff for external service providers and with internal executives for internal services. The business or stakeholders of the service should be part of the contract negotiations. If multiple business stakeholders are involved or associated with the same SLA, they should also be involved in all aspects of the contract negotiations to validate their interests are represented accordingly.

The Technical Challenge

Next, your organization must start with a basic framework to identify the standards, such as using the SNMP protocol, against which the applications will be monitored. The framework process starts by bringing the appropriate technology managers together. Many organizations use outside firms to facilitate this process as they can provide expertise in specific areas (hosting systems, legal services, industry regulations, and so on).

When assembled, the team must determine the key elements of the framework, such as whether there will be common processes across the enterprise applications or common protocols and data formats, ultimately deciding on a set of common processes/protocols for the framework. The discussion must take into account not only the applications, but also the infrastructure where these applications reside (including internal and external networks and systems). Furthermore, three key items must be discussed as part of the framework: how to monitor systems without incurring significant additional costs, measure the downtime with respect to cost, and diagnose problems in a common manner across the enterprise.

The framework must take distributed applications into account and how to correlate events when external partner networks or applications are involved, when databases residing in different geographic regions exist, and disparate systems are interfaced. These complexities must be reviewed as the data elements that are captured for end-to-end monitoring are discussed. This review is imperative, because without appropriate data, root-cause analysis will be impossible.

When this committee has agreed on a framework, the process of selecting a set of tools to monitor the strategic business applications and enterprise can begin. Ultimately, a central repository for the data must be the goal of this phase. Here are the steps involved:

Review the framework; make sure you're planning on monitoring every component of your strategic business applications.
Perform a product assessment, taking shareware tools such as Multi Router Traffic Grapher into account.
Inventory existing tools to determine if any are suitable for the framework (such as HP OpenView, Computer Associates' Unicenter, and IBM Tivoli).
Determine the protocols for communication into the central repository.
When decisions are finalized, procure software as necessary.

When a tool is in place to efficiently monitor your strategic business applications, the next step is to build subprocesses in which these tools communicate with the organization's problem and change management system. This approach closes the loop and builds the foundation for more proactive communication across the business - now your enterprise help desk is contacting your CRM team when disk thresholds are exceeded in the system or subsecond responses are exceeded on the network communication to the ERP system. When a monitoring framework has been developed and the tools are selected and implemented, you're ready to go to the business to promote the end-to-end monitoring environment.

Review Your Applications

If you find yourself reading this article and thinking about Band-Aids or stop-gap measures to get some insight into the health of your strategic business applications without building frameworks, creating committees, or designing SLAs, stop right there: You're in luck. It's possible to improve the monitoring of such apps without deploying tools and enterprise frameworks.

If you've recently started your position as CIO or have been put in charge of providing health and performance information for your strategic business applications, put on the tactical hat and start prioritizing. Determine your risk and exposure based on the level of financial importance your applications carry in the organization. When you're done, determine if you should pick off the low-hanging fruit first and how and when you'll get back to planning your enterprise monitoring strategy. In the short term, utilize your current tools and put manual processes in place to monitor your applications.

It's not imperative that you invest in a full monitoring and management strategy for your organization the first day on the job. However, you must be cognizant of the fact that you will spend more in the long run if you don't invest in a strategy and build a foundation for your organization to effectively manage and monitor all systems within your organization.

Put Your Feet Up

If you've designed and implemented your management and monitoring strategy, you should now be able to sit back and put your feet up. Congratulations: The result of your new monitoring strategy for these strategic business applications will be savings for your organization. What's more, you probably saved your job for another day.