Tech traffic cop: SOA tries the enterprise system on for size

Having just completed an acquisition that doubled the company's size, Cohoes, N.Y.-based Mohawk Fine Papers needed to rationalize a diverse collection of enterprise applications, a manufacturing network that doubled to six sites, and a distribution network that quadrupled to four warehouses.

“With a larger network comes more pressure on us to do effective advanced planning and forecasting,” explains Paul Stamas, Mohawk's VP of IT.

Assimilating the acquired operations within 90 days, Mohawk established itself as the leading supplier in its niche in the premium fine papers segment of the market. Contending with a much more complex supply chain, the company sought to integrate its existing BPCS enterprise system with the Infor ShipLogix transportation management solution deployed recently to replace an older Logility application. And with a much larger production network, Mohawk also wanted to tie BPCS into the Datastream enterprise asset management system—also from Infor.

This wasn't Mohawk's first foray into integrating enterprise systems, but on this go-round, it wanted to avoid the pain of custom development that characterized its earlier efforts.

“The biggest problem was managing all the interfaces,” recalls Stamas. “The failures in the previous integration were point-to-point connections that nobody owned.”

Admittedly, Mohawk's experiences aren't all that unusual for companies attempting custom integration. But in today's less-forgiving market, Mohawk couldn't afford a repeat of the same risks. Instead, it took a different path, adopting Infor's Event-driven Service-Oriented Architecture (SOA) to integrate systems using a vendor-supported architecture.

SOA represents a new way of architecting software. Whereas applications tightly couple their functionality as part of a software module or package, SOA decouples it by making the service independent of the underlying application, database, or platform; and makes the service available over a distributed network through a request/response mechanism. By exposing more granular services in standard fashion, SOA could conceivably increase reuse, improve business agility, and hopefully provide a more straightforward, vendor-neutral path to integration.

The resulting services may expose a piece of a single application, or compound bits and pieces of functionality from multiple sources. For instance, a service that generates a profile of a customer may involve extracting account payment status from Oracle Financials, and interaction history from Salesforce.com.

Given the vast consolidation of the enterprise software market over the past few years, it isn't surprising that vendors such as Oracle and Infor are looking to SOA to leverage industry standards as a basis for integrating their increasingly diverse portfolios. Likewise, it's not surprising that other household names like SAP also are tapping SOA to solidify their positions as de facto enterprise application hubs for their installed bases.

SOA often is confused with Web services, but the two are not synonymous. The comparison has come about due to emerging Web services standards that have drawn vendor support to make it a common architectural strategy across the enterprise software industry.

Admittedly, support for standards may not be universal, but virtually the entire enterprise software industry has embraced several key XML-based building blocks ratified by the W3C and OASIS standards bodies. They include SOAP, a message format for building Web services requests; WSDL, protocol for describing Web services; UDDI, for specifying Web services registries; WS-Security, specifying how to attach signature and encryption headers to SOAP messages; and the WS-I profiles for testing interoperability.

Beyond these building blocks, the standards picture gets more muddled, with more than 100 proposals either ratified or making their way through the specifications process, and widely varying prospects for adoption.

Not surprisingly, in some cases—such as how to communicate trust in distributed networks and virtual business environments where intermediaries are likely to play major roles in vouching for service requests—there are several competing specifications that are only now beginning to converge. Meanwhile, other proposals cover areas such as workflow and orchestration, which are not yet in common use at the Web services level.

With the core foundations in place, most enterprise software providers are in the midst of SOA-enabling their applications—in most cases through support of Web services.

“Previously, integration vendors hard-coded their links,” notes Amlan Debnath, VP of server technology for Oracle. “This time, the integration points will be standards-based, migratable, and supported.”

Oracle's SOA strategy is built around its Fusion middleware, which is comprised of its JDeveloper Java development tools, plus business rules engine, BPEL process manager, and business activity monitoring (BAM). Oracle also is offering an Enterprise Service Bus (ESB) as part of Fusion, plus a Web services management tool for enforcing policies on exposing Web services and applying security.

Meanwhile, Enterprise SOA (ESOA) comprises SAP's blueprint for exposing services from ERP 6.0 and R/3 through the SAP NetWeaver midtier platform.

“The idea of ESOA is that we provide bus building blocks and reusable processes so customers can more easily adapt to respond,” says Fergus Griffin, VP of platform marketing. To date, SAP has defined hundreds of service blueprints, although Griffin says SAP isn't necessarily service-enabling its entire set of functionality.

“Customers are telling us they need processes like order-to-cash or procure-to-pay service-enabled,” says Griffin.

Infor has taken a different approach that uses different sets of standards than from Oracle or SAP.

“We've hidden as much of the SOA as we possibly can,” explains Jeremy Suratt, senior product marketing manager for Infor. “If you are a customer, you won't need to know the internals of SOAP or WSDL.”

Unlike SAP, which is generating its own service blueprints, Infor is relying on canonical business document definitions from the Open Applications Group Integration Specification (OAGIS) to model the services that are exposed from its applications. And rather than relying on SOAP messages and BPEL—which Oracle and SAP are using to build business processes by orchestrating multiple services—Infor will leverage an event-driven publish/subscribe model that uses JMS messages, as well as a data-driven REST model for communicating between applications and the ESB.

Unlike Oracle, which offers its own ESB, Infor will rely on Progress Software's Sonic bus.

By contrast, Software-as-a-Service (SaaS) providers Salesforce.com and Workday are using SOA under the covers. Salesforce customers typically will see the results of SOA integration as a choice of sharing data.

Event-driven service-oriented architecture (SOA) is an approach whereby interoperable applications and software components can be deployed and upgraded with little or no disruption to other enterprise systems.

In turn, Workday—which recently acquired ESB provider Cape Clear—will offer a mix of packaged and custom integrations that are managed, not by the customer, but by Workday.

“We really don't notice SOA,” says Joe Graves, CIO of Stratus Computer and a Salesforce.com customer. In the past six years, Stratus has replaced most of its stand-alone legacy applications—some of which dated back 15 years. And with applications such as SpringCM's Web-based document management and workflow system, the Web services integration is strictly under the covers.

“You provide a login and they readily integrate with your instance of Salesforce. The only time we worry about the interface is ensuring it's not a batch interface if we want something that is relatively real time,” notes Graves, referring to integration between an on-premise instance of Oracle with FT Quote, where Stratus has opted for 15-minute refresh cycles.

But one place where SOA is more visible is in Stratus's B2B integration with contract manufacturers. There Stratus uses an on-premise version of the Cape Clear ESB, where an EDI-like system is implemented by exposing requests-for-proposals using WSDL, which enforces a bid workflow with suppliers.

“We do not expect Cape Clear's acquisition to impact our deployment,” concludes Graves, “however, we can switch to Oracle's SOA solution should there be a need to move away from Cape Clear.”