This health model helps minimize the TCO of applications by better enabling designers to understand the relationships and interactions between application components and the impact of individual component failures on the health of the entire system. A health model also provides the means for developers to optimally write the appropriate instrumentation (or appropriately configure a monitoring solution), and allows team members to deploy and manage the application more efficiently.

In addition, the model helps determine what information has to be collected to correct the degradation or failure. As this information is specific to each individual component and service, it's essential to ensuring optimal performance. Lower TCO can be achieved through increased uptime and improved data collection when applications behave unexpectedly.

Considerations for Service-Oriented Architectures
The health model for applications has been evolving, and so too must design practices. Considering the distributed nature of business, modern design principles favor a scenario that allows for a distinct separation of functions into discrete and reusable components that can interact remotely with each other, and with remote and disparate systems and services.

Web service technology is independent of platform, operating system, and language, and allows application components to communicate over any network, including the Internet, using standard ports and protocols such as HTTP and HTTPS. This service-oriented architecture (SOA) approach to application design leverages the advantages of Web services to enable communication across all tiers of an application.

Greater value can be realized in terms of increased application flexibility and interoperability, along with easier integration with remote services and external business partners, by enabling architects and developers to disconnect certain tiers of an application. Despite this impact on cost of ownership, SOA does present some challenges that must be considered. These challenges include the location, segregation, and orchestration of services, along with the implementation of a suitable system for monitoring the performance of these components to adhere to service-level agreements (SLAs) and operational requirements.

Plan Your Approach to Application Monitoring
So far we've addressed business rules, health models, and Web service design principles. All of these strategies have the potential to lower the TCO of applications. However, their successful implementation is dependent on reliable application monitoring to ensure business rules and application components are yielding the desired results.

Up until now, monitoring and capturing diagnostic information about an application's behavior has been a development exercise of writing information to a log file or publishing it to the system event log. The development team, in this case, is responsible for deciding what information to collect. In this scenario, organizations rely on end users or QA staff for problem detection and notification, and log files provide the diagnostics. Lowering the TCO for an application requires moving beyond this method of retroactive monitoring to a proactive application management approach. To accomplish this, it's vital to understand how collected information is interpreted throughout the problem resolution process and how to standardize the presentation of that diagnostic information across all applications.

The health model provides a template for how an application is expected to behave. This model plays an integral role in the monitoring approach since it should also define the capture of information that's meaningful to the problem resolution process and provide corresponding corrective actions.

Consider a situation in which an application requires access to a file on the file server. What happens if the IT department changes a security policy and causes an access denied error? The health model rules will note a "failed" application state and automatically notify the appropriate team in the IT department. At the same time, supporting diagnostic information is collected to indicate the type of problem, specific information about the particular instance of the problem, and the steps required to resolve the error. The diagnostic information collected would likely include the specific file being accessed, the security error, and the precise permissions required to restore normal application behavior and performance.

This example illustrates how the health model enables efficient management of well-known potential application problems. This approach, however, can be costly from both a design and development perspective because it does not necessarily accommodate unanticipated problems. A more cost-effective and proactive approach is possible by marrying a health model with an always-on application monitoring solution that provides 24/7 detection and diagnosis of both expected and unexpected application problems.

From the perspective of manageability, the final architecture should allow developers to expose instrumentation - as defined by the health model - that captures errors and generates information that can guide operations staff to the source of the error. Where an application uses services that are not locally controlled or installed, such as a Web Service exposed by a supplier or delivery transport provider, local routines that access these services should include facilities for configuration and monitoring that will provide information to help identify availability and performance of these remote services.

Organizations can considerably reduce the amount of code (instrumentation) that developers must write while still providing full state change and performance monitoring capabilities by implementing a health model and a carefully planned architecture.

Applying Your Monitoring Approach to the Whole System
Now that an application monitoring approach has been evaluated, more extensive reduction in total application costs can be achieved by leveraging that approach to implement system-wide monitoring.

IT operators typically require a comprehensive view of the performance and issues within an entire system and infrastructure to diagnose and resolve problems accurately. For example, a business application is likely to depend on at least four separate areas of functionality: the data tier, application tier, interface tier, and utility services such as Active Directory, DNS, and networking.

Suppose our health model indicates that it's in a "failed" state in a business application. In addition, suppose this failure is actually due to a problem with a database server that may become corrupt or run out of sufficient memory. Or, consider an application component that relies on a Web Service exposed by another organization for its source data. If that Web Service fails, the application state will show "failed." However, if the IT operator can't see the performance data and error messages relating to the database server, or analyze the time taken for calls to the Web Service, it will be difficult to diagnose the problem accurately. Therefore the organization will end up spending more reserves than necessary to determine the root of the problem and resolve it.