Some analysts use the term “lights out” to describe these integration scenarios, but lights out doesn’t necessarily imply hands off. Once companies set up the necessary business to business (B2B) and application to application (A2A) links using integration software, they look for ways to easily and accurately monitor these automated processes.
Integration platforms incorporate business activity monitoring (BAM) tools to monitor transaction-processing activity. These tools generally maintain information in textual event logs. Administrators can review these logs to ensure that service levels are being met; and they can generate reports about transaction volume, throughput and exceptions. But in the age of e-business, textual event logs are no longer sufficient. Organizations are ramping up their online trading activities, and they are demanding analytic reporting capabilities to analyze the huge amount of information that’s being exchanged. Instead of a simple command-line interface, they favor web-based dashboards that present domain-specific information about system activity, business activity and trading partner activity.
Advanced integration platforms include these dashboards, along with embedded business intelligence (BI) capabilities to help administrators quickly troubleshoot problems, detect anomalies and conduct capacity planning exercises. In addition to auditing trading partner exchanges and sending alerts that trigger process adjustments, these BI solutions can alert individuals to changes and exceptions that may require action, as well as provide aggregated insight for strategic planning.
Integration platforms with embedded BI tools are ideal for presenting and analyzing real-time transaction information. This article suggests what to look for in a complete integration platform and how to use BI technology in conjunction with BAM tools to achieve zero information latency and self-correcting processes.
Electronic Trading: The Rise of B2B
Let’s begin by examining the business and technology trends that are bringing these issues to the forefront of data center operations, most of which center around electronic trading and e-business.
Clearly, e-business has evolved to include much more than using the web as a storefront. Today’s e-business applications support electronic business models that enable companies to link their internal and external data processing systems very efficiently. E-business is more than just e-commerce. It involves business processes spanning the entire value chain: electronic purchasing and supply chain management, processing orders electronically, handling customer service and cooperating with business partners. Companies use e-business applications to shorten supply chains, streamline distribution processes, reduce inventory carrying costs and many other online activities. Typically, these organizations set up electronic linkages to synchronize activities with suppliers, minimize on-hand inventory, reduce distribution costs, and to bring buyers and sellers together through electronic means.
While there are costs associated with setting up and maintaining these electronic links, the savings far outweigh the costs – especially if you have comprehensive monitoring tools to manage and audit these processes. For example, if you are automatically restocking inventory as partners place orders for merchandise, you need to make sure that each restocking request is responded to in a certain period of time. If not, an administrator needs to be notified to take immediate action.
There are two aspects to this process. In the first case, administrators need to be apprised of how their transaction systems are running so they can ensure that service levels are being met. In the second instance, they must be able to query the log files and generate reports about transaction volume, throughput and exceptions.
Straight Through Processing: Who Turned Off the Lights?
The culmination of these e-business activities is often referred to as straight-through processing (STP) since they enable trading processes to be conducted electronically without requiring an administrator to re-key data or intervene in the workflow. STP technology began in the financial services industry within capital markets, extended to payment-based transactions, and now impacts many other industries including manufacturing, insurance, energy and banking.
In some cases, electronic trading activities entail complex life cycles and a labyrinth of carefully coordinated processes. In the brokerage industry, the goal is to minimize settlement risk by executing trades then handling settlement and clearing simultaneously. In other industries, the objective is to speed the movement of funds, streamline the flow of goods, or automate the exchange of information. While common business processes like issuing a claim or restocking a warehouse might take several days from initiation to settlement, STP generally implies same-day processing or faster, often taking just a few seconds.
Historically, STP solutions were devised to help financial firms achieve same-day settlement of equity transactions, particularly in response to the explosive growth of online trading. Today, the basic concepts of STP are being applied to a variety of business domains to expedite trading relationships, reduce operational risks and create an audit trail for regulatory compliance. When properly deployed, all parties benefit from shortened processing cycles, reduced settlement risk and lower operating costs.
EDI and its Derivatives
EDI refers to the transfer of structured data, by agreed upon message standards, from one computer system to another without human intervention. It includes a variety of standard structures that emulate documents, such as purchase orders to automate purchasing. EDI transmissions can use many methodologies including modem (asynchronous, and bisynchronous), HTTP, AS1, AS2 and others. As more and more trading partners use the Internet to exchange messages and documents, some of the traditional EDI transmission methods are being replaced by Internet protocols such as FTP, telnet and email. But regardless of the transmission method and protocol chosen, administrators need a way to keep an eye on e-business activity.
The Rise of Business Activity Monitoring
The goal of business activity monitoring is to provide real time information about the status and results of various operations, processes and transactions.
BAM applies integration and business intelligence (BI) technologies to automated processes to continually refine them based on feedback from operational events.
BAM software enables an enterprise to make better business decisions, quickly address problem areas and take full advantage of emerging opportunities.
By proactively identifying problems and sending alerts accompanied by relevant information to appropriate systems or individuals, BAM solutions enable organizations to quickly resolve issues before they become critical – or take advantage of opportunities while they are still hot. For example, an administrator might want to fire off a query to view pending orders or see a list POs that haven’t been acknowledged within the last two hours.
BAM solutions can audit any business process in real time and provide feedback and associated data to improve e-business processes. This is an essential aspect of online trading relationships. For example, a BAM system might automatically generate an alert when a trading partner does not acknowledge the receipt of a purchase order within a pre-defined period of time. These alerts can be set to notify designated individuals by email, phone calls or text messages.
Setting Up Trading Partner Relationships
In order to see how a BAM system might work in an e-business context, consider a typical midsize company with a few dozen trading partners. This company probably exchanges hundreds of types of transactions. Each transaction includes four to eight messages, creating a great deal of interactions that must be managed.
When setting up mechanisms for interacting with each trading partner, IT pros must first answer a variety of questions:
- What protocols do we use to communicate with this partner (e.g., AS2, FTP)?
- What document formats do we use (e.g., XML, CSV, EDI)?
- What document types (e.g., EDI 850, RosettaNet PIPs)?
- What process do we execute while sending or receiving information (e.g., priority handling, different types or levels of information, etc.)?
- How do these processes relate to existing services?
For example, a process might call a service hosted by Supplier A using FTP, comma-separated value (CSV) files, and basic user id/password security. Calling Supplier B’s service may require AS2, XML formats and digital certificates.