hile watching application development practices evolve over the years, I have noticed a monumental shift in the way companies approach cost reductions throughout the application lifecycle. The bottom line is, of course, return on investment, or TCO. Whatever they call it, organizations are developing and maintaining applications at an unsurpassed rate, hoping to make gains in employee productivity, increase company revenue, and improve customer satisfaction. The ultimate goal is to achieve operational efficiencies and reduce costs. However, companies always face a trade-off: the business value of the application vs. its development and maintenance costs.
The arduous task of maintaining and managing in-production applications accounts for up to two-thirds of an application?s total cost of ownership (TCO). In other words, for every dollar spent developing an application, an organization will spend two dollars maintaining it in production.
That’s a big consideration?especially in today?s economy. Therefore, architects, developers, IT professionals, and technology executives are now also considering the future costs and manageability of applications when making decisions throughout the application lifecycle. Best practices are evolving quickly, and some of the most progressive and cost-conscious organizations in the world are implementing the strategies outlined here.
Developing on .NET
Microsoft?s .NET framework provides a compelling platform for building robust distributed applications, providing benefits to developers, businesses and users. Organizations are turning to the .NET framework both to replace legacy applications and to develop new applications, because .NET-based development and maintenance costs can be 20 to 25 percent less than those for J2EE-built applications (from the Giga/Forrester study: “The Total Economic Impact of Developing and Deploying Applications on Microsoft and J2EE/Linux Platforms“).
The framework consists of namespaces containing classes with methods that cover a large range of common programming needs in a number of areas, including user interface, data access, database connectivity, cryptography, web application development, numeric algorithms and network communications. The framework is built on open standards and embraces a wide range of programming languages, including not only Microsoft languages such as C#, VB.NET, and Managed C++, but also some third-party languages (Ruby, Python, Lisp, SmallTalk, etc.). See the sidebar “Why Use .NET?” for more information.
|
Other platforms provide similar, although often less-integrated platforms. Still, it is simply not enough to choose one platform over another. Organizations must consider several strategies that can reduce costs throughout the application lifecycle, from planning and development, to testing, deployment and support. The common thread: enabling the ability to monitor and measure application behavior and health throughout the application lifecycle.
Framework Considerations
The first consideration when developing or migrating an application to a new framework is to determine the business rules being automated. These rules may simply be specifications for extracting and displaying data, but more likely have added complexity for reading, querying, manipulating, and storing data; interacting with users and other systems and services; and providing management and monitoring functionality. Therefore, it is imperative to ensure that business rules are not only implemented correctly, but also that they meet current business and end user requirements. Extracting and verifying these business rules provides the basis for application architecture, letting organizations correctly match the architecture with the hardware and programming techniques required to successfully implement and deploy an application.
An Apple a Day
In addition to examining business rules, modern principles and best practices dictate that architects create a health model, or blueprint for application behavior. As one of the initial considerations during development, the health model defines a process for individual services and application components to change states, typically using simple indicators such as “working normally,” “performance degraded,” or “failed.” The health model enables proactive problem resolution by configuring a monitoring solution that adheres to the blueprint, avoiding the problem resolution costs associated with manually detecting and diagnosing problems.
Using a health model is a best practice in application development because it offers the potential to dramatically lower the application?s TCO later in the application lifecycle. It does that by 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 allows developers to write appropriate instrumentation (or appropriately configure a monitoring solution), and helps operations staff to better deploy and manage the application.
Further, the health model helps determine what information needs to be collected to troubleshoot the degradation or failure. Because such information is specific to each individual component and service, collecting it properly is essential to ensuring optimal performance and reducing the problem resolution cycle. Increased uptime and improved data collection when applications behave unexpectedly equate to lower TCO.
Plan Your Application Monitoring Strategy
Traditionally, monitoring and capturing diagnostic information about an application?s behavior has been a development exercise that involves writing information to a log file or publishing it to the system event log. The development team 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 monitoring to a proactive application performance management approach. To do this, it is vital to understand how collected information is interpreted throughout the problem resolution process and to standardize the presentation of that diagnostic information across all applications. Using a standard platform for monitoring and data collection throughout the application lifecycle reduces TCO. In addition, using a standard monitoring and data-collection platform shortens development cycles, because developers are able to focus less on instrumentation and more on core application logic. Time-to-market is improved as well, due to reduced cycles in development and QA.
Imagine an application that requires access to a file on the fileserver. What happens if the IT department changes a security policy and causes an “access denied” error? The health model rules will note an application state of “failed” and automatically notify the appropriate team within the IT department. Additionally, it would typically collect supporting diagnostic information that help indicate the type of problem, specific information about this particular instance of the problem, and 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.
This example illustrates how the health model enables management of well-known potential application problems. However, this approach 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?one that provides 24/7 detection and diagnosis of both expected and unexpected application problems.
To improve the problem resolution process, ensure optimal application availability, and lower the 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.
For example, a business application is likely to depend on at least four separate areas of functionality: a data tier, application tier, interface tier, and utility services such as Active Directory, DNS, and networking. Suppose the application encounters an error stemming from a problem with a database server that became corrupt or ran out of memory. The health model would indicate a “failed” state for the application. If the IT operator cannot see the performance data and error messages relating to the database server, it will be difficult to diagnose the problem accurately. A similar type of problem occurs when an application component relies on a web service exposed by another organization for its source data. The health model will indicate a “failed” state even if it is the web service that has failed, and is not due to the application.
Integration With Problem Management Workflow
Integration is the next requirement. 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. A monitoring solution should be flexible enough to fit the needs of individual teams. Developers or operations staff should have formalized communication channels, so bug reports and feature requests undergo a strictly controlled process. Seamlessly integrating new applications into existing management systems, structures and methods minimizes application downtime and circumvents communication problems that plague companies and leave application problems unresolved.
As code is developed, the information in the health model assists in locating faults and accelerates development, thereby reducing schedule risk, and lowering development costs. In addition, when the code fails, developers can use the resulting state changes to quickly locate the fault and determine the root cause. The health model contains all the state changes, so developers are better assured that their instrumentation will detect any errors.
Evolution
Adhering to best practices and principles for designing and developing applications depends on establishing 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 ensure the resolution of application errors.
Like the application, the monitoring solution should also evolve as business and end-user needs change. When adding new features or code to an application, the health model should reflect those changes. The monitoring environment should also evolve as the application and business needs evolve. Monitoring solution evolution might include new server discovery rules, changing roll-up rules and settings, or even adding completely new rules and alerts. By ensuring that both the application and the monitoring solution are scalable and can evolve, organizations realize greater return on their application development and management investments.
Organizations today are looking at the same thing they always have: return on investment (ROI). In the application development world ROI is tightly linked to TCO. Efforts to shorten time to ROI and lower TCO pose their own risks and challenges, such as how to maintain and manage applications cost effectively as both end user and business requirements change and potentially render the application obsolete. Implementing the correct policies and application performance monitoring solutions are proven strategies for mitigating risk and helping organizations reach the goal of the often elusive ROI.
