Service-Oriented Architecture, Part ll: Leveraging The Legacy

Expensive and dysfunctional integration stymies businesses that want to gain full value from generations of investment in application systems. By supporting a vision of end-to-end business processes, service-oriented architecture promises to be the blueprint for bridging foreign software lands. The second part of our series offers a practical exploration.

Service-oriented architecture (SOA) facilitates the creation of end-to-end business processes using loosely coupled software parts and standards, enabling businesses to profit from their investment in a generation of IT systems, application logic, and user interfaces. In Part I of this article, I focused on integration, one of the five key SOA components. I now turn to two more: synthesized computing and abstract service taxonomy. To get a handle on how vendors are implementing SOA principles, I will examine key aspects of Tibco's and SAP's product architectures.

Synthesized Computing

With the rise of XML, stringing applications together is not only possible, it's expected. Standard, XML-centric middleware offers a common way to describe data and protocols at an application level unencumbered by lower-level details. Applications can no longer be islands where mere portions of business processes are automated; rather, enterprise and collaborative business applications must comprise a collection of services that function in tandem to automate whole business processes. The SOA benefits here are threefold: standardized connectivity, the ability to build greater connectivity into applications, and a new architecture that lets application vendors reorient their packages around connectivity to improve participation in end-to-end business processes.

A typical business process spans multiple enterprise (ERP, CRM, and legacy), productivity (Microsoft Excel and Word), and collaborative (e-mail, portal, phone, and fax) systems. Almost all business processes require all three types of systems. Orders that go on a "credit hold" commonly require email messages and phone calls between sales, accounting, and customer service to determine whether to extend credit. Finance fills in spreadsheets to tally and characterize orders it's overriding. Credit-hold calculations require data and processes across ERP and CRM systems. The fact that Customer 10 cannot order a specific product is just as relevant in Excel as it is in SAP R/3.

It may be hard to conceptualize the true value of combining disconnected, "siloed" subprocesses — both automated and manual — into end-to-end business processes. After all, in many cases the result doesn't automate anything; the XML-based foundation simply provides coordination for end-to-end processes and accessible repositories. Think, however, of an order-entry system: The fact that orders, customers, and inventory are tracked by the system obviates many manual activities, even if the orders themselves must still be entered manually. Similar efficiencies are possible for most business processes when you tie together a range of manually performed tasks, including inserting reminders in calendars, completing forms, making phone calls, sending faxes, creating manual logs, and sending out (countless) emails, that someone must perform to fulfill a complete business process.

In other words, increased automation brings improvements to the intersection of people and systems, especially at the borders of siloed business processes and at the edges of the enterprise itself. Where it was once sufficient to automate just the high-volume, structured, and repeatable portions of business processes and let manual activity dominate the fringe tasks, organizations now require automation throughout end-to-end business processes to maintain a competitive advantage.

Abstract Service Taxonomy

Abstract service taxonomy (AST) is an extraction of business system and platform component functionality into a grid that serves as a logical interface on top of an SOA. This grid contains modules of enterprise applications and platform systems (which include portals, business process management systems, and application servers). The granular composition of an AST promotes interoperability through access and reuse of enterprise-system functionality, management of redundant information and functionality across diverse systems, and employment of platform functionality across enterprise processes.

Although it may be beneficial to have access to "customer-add" functionality in each application, 20 customized silos scattered across the enterprise is a problem — one that calls out for an abstracted "customer," supported holistically by an AST, to operate and enforce business rules across all systems. When searching for a customer, a business user may want to tap a specific CRM system or all systems. In either case, he or she should be able to specify parameters for the search function to query the proper data sources, including unstructured data — that is, if the system can employ the content-management system's indexing service against customer data. Holistic AST approaches also let standard event trapping capture, for example, an event occurring in a manufacturing plant and route it in an actionable format to someone in corporate finance.

Companies should no longer have to choose between a CRM system that may be tied well into their daily work but is weak in order processing, and an ERP system that is functionally strong but alienated from the rest of the user's software application experience. An AST enables much more effective use of logic and interfaces across all relevant systems.

Creating an AST involves considerable planning. The first step is to analyze all business systems to determine the functionality required and the level of granularity. Next, IT must prioritize, mainly by comparing the value of extracting the functionality with the cost. Although most enterprises have a goal of reducing the number of customer databases and other redundant functionality, it's clear that substantial repetition and redundancy will remain, at least in the near term, further necessitating AST abstraction.

AST and Development

Today, applications access most business systems via native APIs or third-party adapters. Neither method is perfect. However, as organizations rewrite their business systems to offer more granular, service-oriented designs, it will become easier to interface between systems. Third-party adapter builders are already benefiting from the increased openness to extend the reach of adapters and the applications they serve.

To determine how quickly to move to an SOA AST approach, evaluate the current state — dominated by dissimilar technology and standards — against projected benefits. Moving too quickly could result in additional costs and a substandard implementation.

The following paragraphs summarize the main functional elements of an AST:

Loosely coupled services, with clean interfaces that support asynchronous communication. These services lie at the heart of an AST. Because services allow more simple access with less dependence on lower-level integration, barriers to reuse fall. Support for asynchronous transactions enables SOA applications to play a role in complicated, long-running business processes, including those that call for human intervention, which conventional systems do not support well.

User interface (UI) logic. The AST's UI logic makes possible flexible composite views that provide read/write access while maintaining fidelity among back-end systems. If a customer screen needs to access five or 10 systems, the UI components assist in abstracting this functionality and creating a read/write customer screen that can enforce business rules across the back-end applications. Portals and other systems can interoperate with the views. The AST's UI flexibility makes feasible composite views that combine, for example, a customer form with another form. In this way, the AST brings to the UI level the kind of integration flexibility becoming available in the middle tier.

Standard, cross-system event trapping enabled by functionality contained in an overarching grid. In and across enterprises, events that occur in one system are relevant to other systems. With broader event-trapping, the AST can move enterprises beyond the limited reach of past technology.

Composite applications. An enterprise SOA lets composite applications leverage layers below, providing the applications with cross-system access to data, functionality, and platform services. This raises the potential of applications to combine transactional and collaborative functionality in an enterprise context. For example, a purchase order processed with ERP and supply-chain management (SCM) functionality could, when necessary to deal with parts problems, be coordinated with email - all in the context of a transaction. Composite applications could be created with graphical modeling tools contained within, or working with the AST.

The AST signifies a new era where buying and replacing systems is largely replaced by continuous enhancement and change. The technology is now available to accomplish this; and enterprises have 30 years' worth of functionality to serve as the technology base.

Industry Examples

To better demonstrate how business and platform functionalities cohesively churn together in an AST, I will close with a discussion of the recommended architectures of Tibco, a leading integration vendor, and SAP, a leading ERP vendor. These dissimilar vendors' architectures are not identical, but they are similarly based on SOA. Their commonality is evidence of SOA's growing industry support.

First, some comments about the obvious differences. Both vendors approach the transition to a new architecture with their own expertise and vital interests in mind. Tibco accentuates the architecture itself as, for all practical purposes, the heart of modern enterprise information systems. Tibco's emphasis on the flexibility and ease with which cross-functional business processes can be created relegates enterprise applications to the background. SAP's view, on the other hand, is that SOA-based applications will sit at the hub of this new architecture and provide enterprises with what they want: the ability to combine the sanctuary of a cohesively constructed application with the flexibility to seamlessly interoperate with all IT assets.

Before discussing elements of Tibco's and SAP's architectures, I should note that most, if not all, of their respective competitors also have SOA blueprints.

Now, let's consider the key elements of Tibco's enterprise reference architecture (ERA):

In contrast, let's look at key elements of SAP's enterprise service architecture (ESA):

SAP does not put user interface logic in a separate layer. Instead, it is interspersed throughout the other layers. At each layer, users and developers can assemble objects and provide read/write composite interfaces that maintain fidelity with back-end systems.

Only a few years ago, Tibco and SAP held polar opposite views of how software platforms were supposed to come together. The fact that these vendors are now quibbling merely about timelines and other specifics is one of the strongest indicators of SOA's market endorsement.

Looking Ahead

Next issue, I will delve into some technical considerations regarding AST, then discuss the two remaining core components of SOA: business-activity monitoring and full life-cycle process. Meanwhile, consult the Web version of this article, at http://www.IntelligentEnterprise.com, for standards important to SOA implementation.

ROBERT EISENBERG, principal of RE Associates, consults, speaks, and writes on business process management and service-oriented architecture. He has owned two software companies, sold one, and held a senior IT position at a public corporation.