Who’s Afraid of SOA?

Identifying the “next big thing” in the software world is always a dicey proposition. Too many “NBTs” have proven to be either short-lived fads or expensive sidetracks, if not overhyped vaporware. But services-oriented architecture (SOA) just might really be the real NBT.

IBM, for one, is a big proponent of SOA. And Newtown Square, PA-based global software developer SAP has a major SOA initiative called NetWeaver that promises to open SAP to much easier integration and data exchange alternatives — which is what SOA is all about.

Technology research firm Gartner predicts that by 2008, more than 60% of enterprises will use SOA as a “guiding principle” when creating mission-critical applications and processes.

So although it is not yet a mainstream technology in the order management or fulfillment world, SOA is definitely making inroads and gaining enough traction in the e-commerce environment that it behooves us to define it, explain it, and try to make some sense of it.

DEFINING THE TERMS

What is a “services-oriented architecture,” and what do we mean by “services”?

In this context, a service is a function or collection of functions or activities that an application performs. In traditional systems that don’t rely on services, functions are hard-coded into the system itself. If the same function is used in multiple parts of the application, it would — or should — be coded once and reused or referenced in the multiple places where it is needed.

Instead of being hard-coded within an application, a function can be written as a stand-alone applet that performs a specific task and is referenced by its “parent” system as needed. This type of applet is called a component, and a systems development strategy that relies on components rather than hard-coded functions is called componentized architecture.

There are obvious advantages to a componentized architecture. It saves a lot of development time, and it assures consistency in the way data are managed. It is also easier to extend system functions by adding components than by hard-coding new functionality.

Components can be “closed” or “open.” A closed component is designed to work with one specific program or one software vendor’s group of programs and cannot be used by other systems. An open component, on the other hand, is available to any system that can take advantage of its application programming interfaces (APIs).

Thus, an open, componentized architecture is one that relies on, provides, and supports solutions that can share common components. Some of these components will have been written by the system vendors; others may have been written by third parties.

When open, componentized systems are exposed to today’s high-speed, broadband Internet, they can take advantage of components that are located anywhere on the Web — obviously with a great deal of attention paid to security and authentication issues. With such components serving up data or clusters of functionality like short-order cooks in a diner (picture the recent Visa Check card commercial with the choreographed eatery spinning out customers until a cash-paying dork brings everything to a halt), you can see why they would be called services.

There are two aspects of a services-oriented architecture that are particularly appealing. One is that it makes systems integration much easier than the laborious mapping of functionality between two or more systems to get them to work well together. If the systems are from different vendors, built with different technologies, and upgraded on different schedules, achieving and maintaining their integration can be a nightmare.

If the systems rely on SOA, however, they are designed to interact on the basis of open standards, so it doesn’t matter if one is an Oracle-based system on Unix and the other is an SQL/Server system on Windows; in theory SOA will make it relatively painless to get the systems working together.

The other especially appealing aspect is that SOA simplifies software development. If a system can make use of many already-available components, that’s fewer lines of code that need to be written for the new system.

SOA can reduce the complexity of software systems that would typically cripple business agility and add millions of dollars to the cost of system maintenance, which already consumes as much as 80% of the typical IT budget. The IT productivity gained through properly managed SOA can be channeled toward strategic goals and future business solutions, rather than bandaging past technical problems.

THE RETAILERS’ VIEW

Newton Upper Falls, MA-based Retail Systems Alert Group recently conducted a survey designed to test the hypothesis that multichannel merchants and their partners are looking at SOA to

  • deploy functionality that supports all channels and lines of business, anywhere in the world

  • integrate new functionality with legacy systems

  • reduce total cost of ownership of IT solutions

  • meet increasing business demands for IT support

  • organize IT functionality along streamlined business workflow processes.

The results: While adoption of SOA is still in its infancy, major retailers are investigating it closely and will begin SOA deployment as standards are finalized. They see rapid and easier systems integration as one of the biggest SOA benefits but also expect it to reduce their inhouse IT backlog, accelerate IT value delivery, and most of all provide “flexibility, speed, and agility” without the need to constantly reengineer systems.

Out of 95 survey respondents, only 4% have completely reengineered their enterprise along SOA lines, while 12% have introduced SOA in some departments or business units. Seventeen percent have pilot projects, and 23% are evaluating SOA for their organizations. Outdoor gear merchant REI and boating supplies cataloger/retailer West Marine are among the early adopters, according to IBM (which is a heavy proponent of SOA).

What are the barriers they see to SOA deployment? Forty percent say the technology is still full of risks and difficult to explain to management. A third can’t readily find SOA programmers; another third say they can’t identify specific benefits to SOA adoption.

REALITY CHECK

To be truly effective, SOA for any one system should be part of a larger services-oriented environment. Yet this is not always the case in the real world of enterprise applications.

A parallel issue is whether services are used as an opportunistic method of facilitating specific data exchange rather than as the foundation of the design of entire solutions. For the moment, at least in the multichannel world, the former way of thinking seems to prevail. What this amounts to is traditional systems that make limited use of services, rather than implementation of an enterprise architecture based on solutions consisting largely of service components. Such enterprise systems don’t yet exist, nor do the services they would need to realize their potential.

Take the PRA multichannel platform from San Francisco-based Pinnacle Rock. Though the system is written using Microsoft’s .NET tools (a major SOA resource, along with rival J2EE in Java), it makes use of services only for exchanging customer, inventory, and order data with e-commerce platforms (not a trivial implementation, to be sure); checking inventory status with warehouse management system applications, and interfacing to third-party credit-card processing and sales tax service bureaus.

Other vendors such as Escalate Retail, Junction Solutions, CommercialWare/Datavantage, ProfitCenter Software, Sigma Micro, and Natural Solutions make similar use of services. In Sigma’s case, its use of the Windows Communication Foundation supports advanced Web services connectivity.

A somewhat more robust implementation, this time on J2EE (with full support for .NET) is encapsulated in EDGE, the hosted multichannel management system from Tampa, FL-based Jagged Peak. The system relies on services to support its API gateways for retrieving customer data and product pricing from third-party systems, while its Enterprise Application Integration layer supports a wide variety of services-oriented transaction-based exchanges. One EDGE user interfaces to Siebel’s CRM application to update dealer and broker data thousands of times a day. Others exchange large volumes of transaction data packets in XML format with their inhouse ERP systems or other applications on a daily basis.

MAKING SOA HAPPEN

Ultimately the key to realizing the value in SOA is management. The transition to SOA takes time and requires considerable planning. Moreover, SOA management extends beyond the availability and performance of individual services. It will also entail

  • making services part of the overall organizational “ecosystem”

  • promoting SOA as a primary objective

  • managing Web services and service usage from design through run time

  • measuring and communicating the value of SOA.

It is probably safe to say that with SOA, it’s not a matter of “if” it will become a widespread reality but “when.” So the more you know about it and the more you have prepared for it, the easier the transition will be.


Ernie Schell is director of Marketing Systems Analysis, a Ventnor, NJ-based consulting firm.

SOA’s RFID opportunity

What might a more comprehensive services approach look like? Apart from the “nirvana” of fully services-oriented componentized applications in a services-rich environment — which may not happen for many years, if ever — a practical initiative that could lead to much wider SOA adoption might take place in conjunction with implementations to support radio-frequency identification (RFID), another emerging technology.

RFID potentially encompasses a broad spectrum of users and systems that need to hand off and track information about inventory as it moves through the supply chain and the demand chain, from manufacturer and distributor to wholesaler, multichannel merchant, and finally to end user. A services-oriented architecture would make the management of RFID data automatic, seamless, and “intelligent,” so that, for instance, store replenishments or warehouse transfers could be triggered automatically according to user-defined business rules.

Internet-based providers are a few steps ahead on the SOA front. Amazon Web Services, for instance, offer developers a growing set of useful tools. Amazon E-Commerce Service (ECS), specifically, exposes Amazon’s product data and e-commerce functionality to developers, Website owners, and merchants to leverage the data and functionality that Amazon.com uses to power its own e-commerce business.
ES