To improve the problem in the resolution process and ensure optimal application availability, while also lowering total cost of application ownership, a monitoring environment should provide "roll-up" capabilities that combine application events and state transitions to deliver an overall view of both application performance and the health state of individual servers, services, and applications. This environment should also allow IT operators to drill down into data at an application, component, service, or server level to determine where a failure or problem occurred.

Implementation and Testing
Developers can plan on building the application once the design of the application architecture, its components, and the infrastructure on which it will operate and be monitored is complete. Using the health model, the required instrumentation is clearly defined, as is the data that this information must expose to the monitoring system.

As code is developed, the information in the health model assists in locating faults and accelerates development, thereby reducing schedule risks and lowering development costs. In addition, if the code fails, developers can use the resulting state changes to quickly locate the fault and determine the root cause. While it's dangerous to assume that lack of runtime failures during development means that the code is fault-free, a comprehensive health model helps ensure that all scenarios are considered in terms of detecting runtime faults.

One piece of the process is testing for lack of application failures to ensure service level or performance requirements. IT operations staff should also test the monitoring systems the application will use. For example, monitoring rules created may not be correct or may contain flaws that affect certain values as a specific event category ID. Or, an incorrect discovery rule or system configuration may mean that one or more servers fall outside the expected system monitoring solution. Another potential issue is lack of connectivity, bandwidth, or connection protocol support between the monitored system and the monitoring solution.

Best practices dictate that all functions of the monitoring infrastructure be tested before and after application operation. This testing should include monitoring management capabilities, resolution process, alerting methods, and the precise information exposed for different types of problems. Complete and accurate testing ensures quick error capture and diagnosis, and promotes fast error resolution.

Integrating into Problem Management Workflow
New applications and monitoring solutions should integrate into existing incident and problem management workflows. Most monitoring solutions can provide application information in a format compatible with existing formal processes for alerting, resolving, testing, and releasing product updates.

For specific teams, such as developers or operations staff, communication channels can be designed so bug reports and feature requests go through a strictly controlled process. A monitoring solution should be adaptable enough to fit into this setting. Seamlessly integrating new applications into existing management systems, structures, and methods reduces application TCO, minimizes application downtime, and circumvents communication problems that plague companies and leave application problems unresolved.

Evolving to Serve End Users
Using best practices and principles for designing and developing applications depends on creating an accurate and comprehensive monitoring solution. This solution should provide coverage for the entire application, including its dependencies on other services and components, and it should contain the knowledge required to diagnose, resolve, and test the resolution of application errors.

Like the application, the monitoring solution should also evolve as business and end-user requirements change. The evolution of the monitoring solution can include new server discovery rules, changing roll-up rules and settings, or even adding completely new rules and alerts. By evolving both the application and the monitoring solution, organizations can realize greater return on their application development and management investments.

Resources

For information on migrating existing code and applications to .NET, see:

• Migrating COBOL Code to the .NET Framework
• Microsoft Jump to .NET

For information on health models and creating manageable applications, see:

• Health Modeling: A Key Step to DSI-Enabled Applications
• Microsoft Management Model Designer
• Visual Studio Team System Designers

Two publications from the Microsoft Architect Journal that discuss SOA are:

• Understanding Service-Oriented Architecture
• Service Oriented Architecture: Implementation Challenges

Other useful sources of information on SOA are:

• Service Oriented Architecture from IBM
• Fujitsu Service Oriented Architecture Web Services Framework
• .NET Management Pack for MOM 2005
• .NET Line of Business Application Monitoring