Remember the “eight second” rule. Back when Internet transactions were new, consumers attempting to purchase goods and services online were stymied by poor website performance. Service outages and brownouts occurred seemingly at random with no connection to the high availability of the underlying systems. Business managers lived in fear of service outages becoming news stories and crashing high-flying stock prices.
The issue was lack of visibility. Management systems only monitored specific parts of the infrastructure making up the tiered web applications. The end-to-end user experience of the application was a complete unknown to these management systems. Yet user performance dictated sales therefore the endless rounds of finger-pointing began. A small start-up took note of these happenings and offered a solution that provided online business managers visibility into their users’ online experience and marketed the service with a simple message that resonated with manager’s fears (i.e. eight seconds and the sale is gone). The rest is history, and Keynote now rakes in millions in revenue.
So what has this got to do with SOAs?
Companies that are using SOA infrastructures to integrate and automate their business transactions are finding themselves in a similar situation. Together SOA and Web Services provide integration flexibility, allowing enterprises to create dynamic cross-department and cross-enterprise transactions that automate business processes and relationships. If successful these newly automated transactions and processes can radically lower operational costs, reduce business-to-business cycle times, create new business opportunities. The potential financial ramifications could be hugely positive if the resulting processes and transactions operate successfully in production.
Successful operation is the key. The success of automated processes and B2B transactions depends heavily on: 1) service availability and performance, and 2) transactional validity. Having lived through the maturation of Internet consumer transactions, most business and IT staff have a handle on service-level availability and performance monitoring. However, the concept of monitoring transactional validity is still in its infancy. Here I’m defining transactional validity as the rate of successful completion of automated transactions. Think back on all the times you have clicked on a link to get more catalog information and you get a page full of Java script or a database error message or some other programming language filling the screen instead of the actual information you requested. In these cases the transaction was completed, usually well within the service performance metrics, yet by no stretch of the imagination can you consider the transaction successful.
Gaining this type of visibility will become vitally important for SOA projects. Why? There are two reasons. First, SOA projects often involve critical (i.e. serious revenue and/or cost savings can be at stake) business processes and transactions between multiple business systems. The system receiving the error message will typically just drop the transaction and move onto the next one. If an application error is generated by the enterprise’s quote-producing service and is communicated to the partner’s travel web portal then the entire B2B transaction fails. The enterprise loses the sale, not because the service infrastructure was unavailable or performing badly, but because the transaction failed to complete successfully. This scenario actually happened and the enterprise only noticed the problem because the revenue pattern of one of their long term partners became erratic. Another company noticed the number of transactions from one major trading partner drop by two orders of magnitude before starting the resolution process. Because of the criticality of these SOA transactions, more visibility is definitely better than less.
Second, when two business systems are integrated and their transactions automated there are no human users to call the helpdesk about transactional issues (yes there is a fraction of a percent of people that call rather than move on to another site). Without this human component, the onus is on companies to be entirely proactive in discovering validity problems with their cross-department, cross-enterprise transactions. Yet, most enterprises have little actual visibility into transactional validity across these automated transactions.
Not to mention, SOAs can dramatically increase the complexity of the interactions between multiple service components delivering a particular transaction. A SOA-based transaction can involve a portal application, single-sign-on application, J2EE applications, legacy mainframe applications and SOA integration software. Thus the source of the error messages transmitted along the transaction becomes hidden in the complex web of integrated services and technologies. The content of these complex interactions must become more visible for troubleshooting of validity problems.
Thus SOAs need a new rule – not for service availability or performance – but for transactional validity instead. The question is what is a percentage that can be universally applied to all business transactions? An enterprise with one very important customer dropping one percent of their transactions with that customer can translate into enormous losses whereas one percent of dropped transactions can be the norm for a different enterprise. While I’m off researching that magic number, what should be clear is that monitoring transactional validity will be as vital a part of making SOA projects operate successfully in production as service availability and performance monitoring.
