informa
/
News

Service-Oriented Architecture, Part ll: Leveraging The Legacy

Expensive, dysfunctional integration stymies efforts to gain full value from generations of investment in application systems. By supporting end-to-end business processes, a service-oriented architecture (SOA) promises to bridge foreign software lands.

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):

  • Enterprise application and data systems. This layer contains enterprise applications and platform functionality, making available for repurposing 30 years of accumulated enterprise functionality in CRM, ERP, and legacy applications. Tibco includes content management — considered part of SAP's platform functionality — in this layer.

  • Data services. Consisting of adapters, data-modeling technology, and legacy extraction software, this layer captures the data and functionality from the enterprise application and data systems layer and makes them available to subsequent layers in an abstracted form that renders it unnecessary to connect to back-end systems.

  • Application services. Application servers, messaging software, metadata repositories, Java, and .Net are included in this layer, which provides much of the infrastructure needed for scalability, security, and platform support.

  • Business services. This layer contains functionality usually contained in BPM packages, such as rules engines, business-process modeling, and human work flow. Features of this layer use the functionality in preceding layers to allow the creation of composite applications that consist of system and human activities.

  • Presentation and interface. This layer contains Web portals, mobile devices, and XML formats linked with the data, functionality, and business processes in the ERA to provide rich user interfaces.

  • Event services. At this layer, the system traps events across the ERA and provides them to other layers in actionable formats. For example, a billing error can be routed to the accounts-receivable portal for correction.

  • Enterprise lifecycle services. This is where developers and end users create composite applications using all the simplified interfaces that have been wrapped around the enterprise functionality in the ERA. Data modeling, transformations, metadata, and other elements brought in at lower levels help streamline the interfaces and make modeling software a reality at this layer.

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

  • Source systems. This layer contains enterprise applications and platform functionality contained in CRM, ERP, and legacy applications.

  • Adapters. This layer brings data and functionality into the ESA. Enterprise systems lie outside the ESA. In the future, as they become natively service-oriented, they will reside within the ESA and will not require adapters to bring their functionality into the ESA.

  • Base-level objects. In this layer, developers can create objects, services, and processes from data and functionality retrieved by the adapters. The adapters enable access to this information within the confines of the ESA; but objects, services, and processes are still structured very much like their native package representations. For example, customer objects from CRM and ERP systems remain independent entities within the ESA in this layer.

  • Platform component systems. Content management, data warehouse, enterprise application integration, portals, business-process management, collaboration, and mobile infrastructure are made available in this layer to cohesively participate in the overall architecture.

  • Standardized objects. This layer wraps similar objects, services, processes, and customers across multiple similar occurrences to provide one unified object, service, or process interface. Standardized objects may include unstructured and structured data, human and system work flow, business rules, and other functionality made available in the platform component systems layer.

  • Comprehensive model. SAP's standardized objects, services, and processes are supplemented here with metadata that describes their interrelationships. The metadata enables the creation of business processes via modeling, as opposed to frequent coding.

  • Composite applications. Using the preceding layers, end users and developers can create, assemble, and reassemble applications. ESA emphasizes this layer as the fruit of its offering, where applications are quickly created via configuration. In SAP's view, this paradigm largely represents the future of enterprise applications.

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.