It's often said by street corner philosophers that the only two certainties in life are death and taxes. If you are a customer of one of the major enterprise application vendors, you can add another inevitable item to the list: Service-Oriented Architectures.
Like major enterprise application providers that jumped en masse onto the client/server architecture bandwagon in the 1990s, SAP, Oracle, PeopleSoft and Siebel today are all embracing SOA with the passion of the newly converted. Each of the so-called "Big Four" enterprise application providers has begun to detail its own SOA roadmap and product offerings, and each has put customers and independent software vendor partners on notice that SOA is the wave of the IT architecture future.
"All of the big enterprise software vendors are embracing the concept," says Eric Austvold, research director at AMR Research in Boston. "Each, in one way or another, sees SOA as a way to expand use of their product set within the enterprise."
So what does the arrival of SOA mean for IT managers at manufacturing companies? In the not-too-distant future they will need to make some fundamental decisions about when and how to implement SOA products and technologies. Key questions they must answer: Should they rely on their current enterprise application vendors to define and implement their SOA for them? Or should they instead lean toward assembling best-of-breed SOA elements from a variety of vendors such as Microsoft, Sun, BEA, webMethods, IBM and a growing collection of start-up software providers? The short answer, experts say, is that, today, only large manufacturers that are heavily dependent on a single enterprise application provider should rely on product sets, such as SAP's NetWeaver, to define their enterprise Service-Oriented Architectures.
Smaller manufacturers and those with more heterogeneous environments should either bide their time or opt for a more independent approach using products from best-of-breed providers.
"In the end, a lot of the answer will boil down to skill set alignment," says Sharyn Leaver, research director at Forrester Research in Cambridge, MA. "If you already have a best-of-breed approach and you're used to the Websphere environment or developing your own [Microsoft] .NET apps, you might want to stick to a more independent SOA approach. But if you're already 80% SAP and you want to extend there, it might make a whole lot of sense to consider NetWeaver."
NEW SPIN, OLD IDEA
Service-Oriented Architecture, while a new name, is not a completely new concept. In the mid-1990s, infrastructure heavyweights including Microsoft, Sun and IBM battled to win support for their own versions of what was then known as distributed computing architectures. Competing distributed computing implementations such as the Common Object Request Broker Architecture (CORBA, backed by Sun) and the Distributed Common Object Model (DCOM, backed by Microsoft) were both designed to allow applications-or pieces of applications-to communicate with one another, using common request/response messaging protocols, and to share common services such as object naming or discovery services. These distributed computing architectures were touted as ways for developers to reuse software, break up increasingly unwieldy, monolithic applications and promote standard interoperability between systems from different vendors. Fragmented vendor support, among other things, eventually hampered both DCOM and CORBA.
Many of the same concepts, however, are at the heart of SOA. Frameworks such as SAP's NetWeaver and Oracle's Information Architecture, for example, use common messaging protocols that allow application modules-a plant maintenance application, for example, or a bill of material-to communicate over a network and share common services.
The big difference is that these core SOA-enabling protocols are designed to work over Internet technology and use widely recognized Web services standards such as the XML-based Simple Object Access Protocol (SOAP), the Web Services Description Language (WSDL) and the Universal Description, Discovery, Integration (UDDI) registry.
Tools to develop services using these standards are available from Web services technology vendors such as Microsoft and Sun. To form a complete Service-Oriented Architecture, however, these core Web services technologies are surrounded by a host of other software modules that allow services to be created, deployed, secured, orchestrated, monitored and managed in a consistent way. (For a more complete definition of Service-Oriented Architectures, see sidebar on p. 22 and SOA comparison chart on p.25.)
SOA'S UPSIDE
The primary benefits of SOAs, vendors say, will be software reuse and much better, easier application integration. Since, in an SOA environment, applications communicate as services on a network, they can be loosely coupled, used when they are needed and widely shared. So, for example, a manufacturing company could create a single product pricing calculator and allow it to be accessed as a common service by several different applications, such as SOA-enabled call centers or e-commerce systems. That would enable a manufacturer not only to reuse software; it would provide common, consistent pricing numbers to any customer-facing application.
Connectiv Power Delivery, a Washington, D.C.-based power utility, has begun taking advantage of SAP's NetWeaver SOA infrastructure to consolidate key plant maintenance information into a single service-oriented application. Before deploying the VIP enterprise asset management application from NRX Global Corp. (Toronto), Connectiv had plant maintenance information spread out among several systems, including SAP's plant maintenance module and the PI System plant information management system from OSISoft Inc. (San Leandro, CA).
"Because the information was kept in different siloed systems, people spent time going from system to system looking for the right information," recalls George Muller, information technology manager at Connectiv, a unit of $1.5 million Pepco Holdings Inc. "We wanted to bring all the information together, but we couldn't justify ripping out SAP."
The VIP application that Connectiv is using has been deployed as what SAP calls a xApp, a Web service that links natively into NetWeaver. So far SAP has announced eight such xApps developed by third party suppliers. Using NetWeaver infrastructure products such as the SAP Web Application Server (WebAS), SAP's Exchange Infrastructure integration product and predefined collaboration process flows, NRX's VIP application is able to operate as a shared service in the SAP environment. Users can tap into plant maintenance information residing in the SAP or PI systems from the VIP user interface. The result, says Muller, will be reduced unplanned maintenance outages and improved productivity.
The other immediate benefit of SOAs is streamlining application integration. Since SOAs use standard Web-based protocols to enable program-to-program communication, it is fairly easy to retrofit even existing legacy applications, replacing complex point-to-point integrations based on application programming interfaces with, in effect, standard, reusable Web services adapters that can plug into any other application. This can dramatically reduce the number of individual integration links that must be developed and maintained.
Computer manufacturer Fujitsu Siemens Computers Ltd. (Munich, Germany) has begun using SOA tools from its CRM application vendor, Siebel Systems, to more easily integrate SAP and legacy applications. Until about a year ago, the only way for Fujitsu Siemens to get updated product and pricing data held in those systems out to its reseller partners and customers was to manually merge data onto Excel spreadsheets and e-mail or fax them to partners.
Although the company was already using an integration server from webMethods Inc. (Fairfax, VA) to integrate other applications, the company decided it would be too expensive to create additional custom point-to-point integrations just to solve its catalogue updating problem. Instead, Fujitsu Siemens opted for a pilot implementation of Siebel's Universal Application Network SOA tools.
UAN uses third-party application servers including webMethods', but it also includes design tools and process libraries that allow companies to author Web services-based business processes that integrate disparate applications at the semantic level. So, for example, two different applications would not only be able to connect using Web services but would also be able to understand the others' different terminologies and data models. According to B2B manager Martin Powell in Bracknell, UK, Fujitsu has used the tools to successfully integrate its product data and pricing systems and is now considering using them to replace existing traditional API-based integrations.
As useful as some of these SOA-based tools seem, however, the reality is that your major enterprise application provider may not be your best bet for defining and supplying your company's Web services-based architecture and tools of tomorrow. For one thing, enterprise application providers-particularly the Big Four: Sap, Siebel, Oracle and PeopleSoft-each see SOA and the problems it can solve quite differently. Therefore, an enterprise app vendor should only be considered for your SOA tools partner if its SOA vision matches up with your own. (For a complete comparison of the SOAs from the Big Four, see chart and sidebar on opposite page.)
WHOSE SOA?
PeopleSoft, through its AppConnect infrastructure, and Siebel, through UAN, see SOA primarily as a means for enhancing integration both inside and out of its own application suites. Both vendors provide Web services-based application integration service software and common object models that run on application integration servers from major third party providers. In Siebel's case that's IBM, SeeBeyond, Tibco, Vitria and webMethods. In PeopleSoft's case it's BEA and IBM.
On top of the integration server and integration services layers, both Siebel and PeopleSoft have added business process models that spell out how, from a semantic and workflow point of view, a Siebel or PeopleSoft CRM module, for example, would integrate with SAP's order processing module. Users can employ these models and reference implementations to turn modules from different application vendors into coordinated composite applications.
According to Nimish Meta, Siebel's UAN group vice president, his company chose to focus on integration because it was the biggest problem facing both Siebel and its customers. Creating point integration connectors between each Siebel module and between every application to which it might need to connect "would have been a programming nightmare for us," says Meta. "So, completely out of selfish reasons, we created an application-independent services layer that puts a services wrapper around every application. That integrates with a common object. Then we write processes that do all the orchestration on top of it."
Oracle has a slightly different take on how to use SOA technology to solve integration problems. Like other enterprise application vendors, Oracle has been replacing proprietary application programming interfaces in its core application products with Web services-based technologies, beginning with the suite's 11i Version 8 release.
Like other enterprise application providers, Oracle also provides access to all those integration services through a standards-based interface repository. Rather than layering a business process orchestration layer on top of all that, as PeopleSoft and Siebel do, Oracle links its SOA architecture to what it calls a Customer Data Hub, a bi-directional data repository intended to be the central hub for all customer data generated by Oracle and non-Oracle applications.
"We've tried to keep it real simple as far as what we offer and linking it to solving real business problems," says Bennet Yen, senior director of applications at Oracle in Redwood Shores, CA. "We're saying the Customer Data Hub solves data fragmentation and data quality, which are two huge business problems that all organizations face ... This is where Oracle is going and differentiating itself."
Yen says Oracle will follow the Customer Data Hub with a series of other Web services-enabled data repositories focused on specific business processes. Oracle is currently working, for example, on an employee data hub that would include a common business model and repository for all HR-related data, Yen says.
AMBITIOUS GOALS
While its major competitors have focused their SOAs on solving relatively discrete, common problems faced by most manufacturing companies, SAP's SOA vision is much broader and more ambitious. Rather than concentrating on data consolidation or application integration, SAP's collection of SOA infrastructure technologies-collectively marketed as NetWeaver-and the company's forthcoming higher-level process modeling and implementation tools-called Enterprise Services Architecture-are being positioned as nothing less than a complete SOA; on top of which enterprises can build a new class of Web services-enabled applications whether or not they also use SAP's applications.
What's more, unlike Siebel and PeopleSoft, SAP has elected to supply much of the infrastructure software underlying its SOA itself. That includes its own application server, integration server, portal, business intelligence and master data management tools. This puts SAP, for the first time, into direct competition with best-of-breed application and integration server vendors such as BEA and webMethods. "SAP is in transition from a company that used to do applications to a company that does applications but also provides a platform for applications," says Peter Graf, SAP's senior vice president for product marketing and collaborative solutions.
While NetWeaver will work with non-SAP infrastructure, says Graf, it will work best on top of the WebAS application server and other SAP infrastructure software. "There is a huge difference between building one platform compared to having a variety of vendors and branded as one thing," says Graf. "The value to the customer is that, as they're trying to put these technologies into play, it requires the collaboration of the portal with the business intelligence with the exchange infrastructure ... We can build this integration into our stack."
For some manufacturers, that argument makes sense. Utility Connectiv, for example, is planning to expand its use of NetWeaver to integrate more existing packaged and home-grown legacy applications. According to Muller, the company has a long list of phase two integration projects for which it plans to use NetWeaver, and the company is considering using the Enterprise Portal portion of NetWeaver to provide user access to integrated applications.
"Over time," says Muller, "I'd expect NetWeaver to become our core SOA environment."
Other manufacturers, however, say they are concerned about getting locked into a single provider for both application and SOA infrastructure. Moreover, they say, they're not inclined to tear out existing application servers and other integration infrastructure just in order to support something like SAP's NetWeaver SOA.
THE BEST OF BREED SOA
Computer storage vendor Network Appliance Inc. (Sunnyvale, CA), for example, is assembling its own SOA out of tools from a variety of vendors including Siebel, Tibco and Oracle. The company has completed a major centralized customer data master repository project in which it used Siebel's UAN to orchestrate the consolidation of customer data from Oracle and Siebel systems. NetApp uses Oracle's Customer Data Hub as the Web-services-based customer repository.
"We see SOA as simply the evolution of a good architecture that the marketplace supports with a variety of tools and services," says NetApp Senior IT Manager Michael Ryan. "We don't want to buy into a particular SOA stack. We want to compose those technologies that will benefit NetApp and our customers ... Different tools and platforms have different strengths."
Many independent software vendors are similarly concerned about getting locked into a single vendor's SOA architecture. Most of the Big Four enterprise application providers have been encouraging ISVs to support their SOAs. SAP, for example, has been soliciting ISVs to develop xApps that work via Web services with all of NetWeaver's infrastructure pieces. In exchange, SAP offers to put ISV products on its sell list.
While that's attracted a few small ISVs with industry-specific applications, others say they'll pass on the opportunity to get into bed with NetWeaver. "Make no mistake about it, NetWeaver is a wolf wearing sheep's clothing," according to John Beans, vice president of marketing at Datasweep Inc. (San Jose, CA), which recently upgraded its own MES product suite around Web services using Java tools. "SAP wants to control the SOA environment, and NetWeaver is all about SAP having dominant mind share and taking over as much of the infrastructure space as possible."
Other ISVs say that's simply not going to happen, at least in the short term. "If you look at middleware market share, SAP is by far the minority player," says Paul Farrell, senior director of product marketing at ERP provider Epicor Software Corp. (Minneapolis), which is currently in the process of Web services-enabling its product suite using Microsoft's Biztalk server and enterprise service bus technology from Sonic Software Corp. (Bedford, MA). "The struggle SAP will run into is that many customers already have message-oriented middleware installed, and they won't want to replace it," Farrell adds. "So we believe SOA infrastructure is more likely to be supplied through third party middleware than SAP or another enterprise software company."
Manufacturing companies considering an enterprise software provider as the source of their SOA infrastructure may run into another problem, again at least in the short term: SOA product sets such as NetWeaver or PeopleSoft's AppConnect are relatively immature, particularly compared to SOA technologies from independent integration server companies such as BEA, Tibco and webMethods, which have been at this longer. SAP, for example, is only now beginning to roll out business process content, services that can be used to orchestrate the interaction of different applications at a business process and semantic level. SAP, which calls these Enterprise Services, says the rollout of a repository of these services will take place between now and 2007. PeopleSoft is ramping up a similar content rollout.
PLANT FLOOR CONNECTIONS?
The absence of such high-level business process orchestration services is causing some important ISVs to withhold support for SOAs such as NetWeaver. Manufacturing automation provider Rockwell Automation, for example, has been busy deploying its Factory Talk data model, which exposes interfaces to its factory floor control systems as Web services and uses emerging standards such as the S95 Business-to-Manufacturing Transaction specification as the high-level business process definition. Until SAP supports the same standard, however, Rockwell will remain lukewarm to SOAs like NetWeaver, says Steve Briant, product manager for collaborative framework at Rockwell in Pittsburgh.
SOAs from the Big Four enterprise application vendors also remain weak when it comes to tools for monitoring and managing the runtime performance of Web services and tools that can be used to wrap existing legacy applications with standard Web services interfaces. All of those capabilities will likely find their way into SOA technology stacks such as NetWeaver over time, says AMR's Austvold. SAP's recent partnership with Microsoft, for example, will give SAP developers the opportunity to use Microsoft Visual Studio.NET tools to develop in the NetWeaver environment.
While SOAs from enterprise software providers have some growing up to do, experts insist that's no reason for IT managers and ISVs to put the migration to SOAs on hold. In the long run, Service-Oriented Architectures and the underlying Web services technologies that support them will help enterprises build much more flexible, robust, easier-to-integrate applications. And all application providers will eventually support SOAs, pulling customers along with them like it or not. You might say it's as inevitable as death and taxes.