FTP Online
Search:
Locator+ Code:
FTPOnline Channels Conferences Resources Hot Topics Partner Sites Magazines About FTP RSS 2.0 Feed

email article
printer friendly

Build Business Service Metrics
Application architects and operations management can work together to develop self-monitoring distributed applications.
by Brian Connolly

Posted March 15, 2004

Web services, distributed application frameworks, and multitier server architectures have made it possible to develop extraordinarily complex applications. Organizations can use these technologies to offer a rich set of business transactions to their customers. On the client side, an enterprise can use Web services to formally define the services it offers so that they are available to a variety of internal and external client platforms. On the server side, enterprises can act as Web service clients, taking the services offered by external suppliers and combining them with their own internal offerings to add value for their customers.

Development organizations build these applications in a logical manner. They create business objects, transactions, and services within a distributed application development framework. This framework allows the development team to defer the assignment of business objects to physical tiers and machines until deployment time. Operations management takes over at deployment time and attempts to support the application by monitoring the physical plant, responding to events, and planning future capacity.

This logical-physical dichotomy is the fundamental operations management problem. Two different world views are in play: development's view of business objects' logical world and operations' view of physical resources and constraints. Both views are critical to an enterprise's success. The enterprise uses the logical view model to develop external business value. The physical view is equally important, because resource monitoring and capacity planning allow an enterprise to sell this business value more cheaply than its competitors.

It's important to understand this dichotomy (see Figure 1). Enterprises implement applications as a set of interacting business objects. The enterprise sells business transactions to customers, and these transactions usually involve a complex series of object interactions. Within the server, several tiers of application servers might interface with the enterprise's resources and data. An enterprise can also use external services within the transactions it provides to its customers, such as order processing, credit approval, order tracking, and shipping.

Development builds a logical model of the enterprise application and usually releases distinct components of it at deployment time. Note that from the external, service-level agreement perspective, problems are reported to operations management in terms of business transaction issues. A customer makes a complaint: "These transactions take too long in my client application." The complaint is directed to operations management, and the dichotomy between abstract transactions and low-level physical resources becomes a critical obstacle.

Tools Can Help
Tools such as HP OpenView and IBM Tivoli can provide an accurate, in-depth picture of machine utilization, hardware and software faults, and network utilization. However, this is only part of the information that operations management needs to diagnose a problem accurately. Operations management lacks the logical model of the business application, the runtime mapping between external customer transactions, and the chain of physical resources the transactions require, so it can't identify critical bottlenecks from the customer transaction perspective.




Back to top



ADVERTISEMENT

Java Pro | Visual Studio Magazine | Windows Server System Magazine
.NET Magazine | Enterprise Architect | XML & Web Services Magazine
VSLive! | Thunder Lizard Events | Discussions | Newsletters | FTP Home