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

Build Business Service Metrics (Continued)

Here's how the enterprise application could incorporate business metrics recording (see Figure 2; new components appear in blue). Client applications automatically record metrics on each transaction requested by the customer. When a transaction completes, a metrics report is attached to the next requested transaction. On the server gateway, the server strips off these metrics reports and queues them for posting to a metrics database. Within the server, client business objects also record metrics on the server objects they use, which are queued to the metrics database as well.

Add Metrics Payloads
You can extend client/server application protocols to add these optional transaction metrics payloads. A typical payload has this information:

  • A unique external transaction identifier.
  • The start and end times of the transaction from the client's perspective.
  • The start and end times of the transaction from the server's perspective.
  • Application information on the transaction, including the business transaction type and any associated transaction parameters. This allows an after-the-fact classification of transaction complexity and the server resources required.
  • The physical identifier of the machine that initiated the transaction.

Typically, a business transaction involves many steps. A customer client application initiates a transaction. Internally the server decomposes this transaction into more primitive operations, each of which involves an exchange between one internal server client and one server resource. You can extend the client/server payload to record metrics on those dependent operations as well. To do this, pass the external transaction identifier (which uniquely identifies the triggering business transaction) along with internal resources, and augment it with identifiers that uniquely identify each of the internal resource requests involved.

Development and operations must team up on the metrics design, and some additional physical plant is required for the metrics queue and database.

How Operations Benefits
Operations management gains significant benefit from these metrics. Now it has a near realtime view of arriving transactions. Operations management can map transactions to resources to physical machines and identify the critical bottlenecks. The transaction types and parameters allow operations management to distinguish complex transactions, which are expected to take longer, from simple transactions that should be dispatched quickly. Operations management can use the metrics history to examine past transaction rates and compare them with marketing forecasts and past predictions, leading to more accurate forecasts of future demand.

Perhaps most importantly, metrics provide evidence to decide whether a customer problem is attributed to software problems, internal bottlenecks, or delays from external service providers. The uncertainty sometimes results in tension between operations and development staffs. By collaborating to design and implement a general business transaction metrics infrastructure, development and operations can work toward the common goal of better serving their customers.

About the Author
Brian Connolly is an independent consultant and author whose specialty is enterprise transaction systems. He has designed international financial trading systems for the foreign exchange and futures markets. You can reach him at brian@ideajungle.com.



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