Global MBT:
Login  |  Register          Free Newsletter Subscription
 
Email
Print
Reprint
Learn RSS

Get ready for SOA

Regardless of approach to purchasing technology, service-oriented architectures will infiltrate all IT shops

By Erik Keller, Contributing Editor -- Manufacturing Business Technology, 11/1/2006

For the foreseeable future, any company deploying new IT systems—or upgrading existing ones—will need a service-oriented architecture (SOA) strategy. Why? Because all business software vendors are embracing SOA.

It doesn't matter whether the vendor markets packaged applications that can be used out of the box—like an Oracle or SAP—or if it follows the IBM model of selling tool kits for customers seeking to develop custom solutions. SOA is underpinning all new product offerings.

The nagging question for software buyers is whether the SOA approach will deliver the promised benefits. That answer will emerge over time. Meanwhile, it makes sense for manufacturing executives to develop at least a basic understanding of SOA and its potential impact on a business.

Gartner, the Stamford, Conn.-based IT research and consulting firm, coined the term service-oriented architecture in the mid-1990s to describe a specific approach to application programming. In recent years, so much has been written and said about SOA that it can be difficult to assess its true potential for delivering business value.

All hype aside, there are a few core concepts that business executives should keep in mind when assessing SOA's potential value. These are the chief concepts:

  • Ease of integration;
  • Software reuse;
  • Faster time-to-market; and
  • Lower cost of ownership.

Consider how each of these factors can impact a business. Ease of integration is an expected result of the SOA design approach that permits different pieces of a software program to be built in small, discrete components. These components—called services—can easily be connected through the use of high-level standards that are being adhered to by developers across the industry. The ability to, in effect, swap services into and out of an IT infrastructure—rather than having to write programming interfaces—can drastically reduce the complexity of integration projects.

Once a service is created, it can be reused any number of times. For instance, if a service is developed for retrieving customer information, it can be invoked for any process that requires that information. Previously, separate pieces of code would have to be written each time that functionality needed to be included in a new process.

The ease of integration and reuse of software combine to potentially deliver a faster time-to-market and lower cost of ownership for all SOA-based applications. The prevailing theory is that SOA will auger in a new generation of speedy and agile software systems—a claim that has yet to be proven (see Preventing IT SOS when pursuing SOA).

The prospect of these potential benefits was enough to spur many different vendors to offer SOA-based solutions that are impacting the market in two ways. First, the major ERP players—Oracle and SAP—are pushing their customer bases to upgrade current solutions to their next-generation SOA offerings. Second, SOA tool kits emerging from software infrastructure suppliers such as IBM, Microsoft, and BEA Systems are encouraging buyers to supplement existing packaged applications with solutions that are built and supported internally. Therefore, as companies look to adopt SOA-based applications, they will have to choose between building those applications themselves, or buying them from an application vendor with its own SOA platform (See Dueling SOA approaches).

Industry leaders embrace SOA

Perhaps the earliest proof points for SOA have come via large and innovative end-users who have built their own solutions. Over the past few years, leading names such as Motorola, Amazon.com, American Express, and eBay have been exploiting SOA within their operations for two purposes: to build applications not yet available on the market, and to upgrade strategic legacy applications through the creation of a highly architected set of services that can be combined in any fashion to support new business processes. A recent CIO survey from New York-based Merrill Lynch indicates nearly 90 percent believe deploying an SOA will be a key future initiative.

The positive results of SOA adoption have been reported in a variety of industry studies such as San Francisco-based Sand Hill Group's Web Services Impact on Fortune 500 Companies, and Westport, Conn.-based Saugatuck Technology's SOA Adoption: Business Benefits Drive Strong Demand. At Sand Hill's recent Software 2006 conference, Toby Redshaw, a Motorola IT executive, told the audience how Motorola is aggressively rolling out nearly 1,000 services that are being used corporatewide to create a large array of applications and processes.

"As we roll out more [services], we will selectively be turning off many of our packaged applications," said Redshaw. In the past four years, he added, Motorola cut its annual IT budget from $1.4 billion to under $1 billion.

Nearly all enterprise software vendors are aggressively deploying or redeploying their application suites using SOA and Web services as they claim that SOA permits faster building of applications, quick reconfiguration and deployment, and lower overall costs. WebSphere, a platform for building and deploying SOA-based applications, is one of IBM's best-selling products. Vendors selling SOA tools—including TIBCO and BEA—continue to grow at faster than average market rates. These factors indicate how quickly companies are supplementing the "buy" option with that of "build."

Besides just selling customization tools and services, IBM also has put SOA to use internally as it has a wide variety of sharable and reusable services in production. By using SOA, IBM—like Motorola—reduced the number of internal applications by 75 percent.

Core application building block

These benefits are not lost on application sellers as they look to create their own solutions, and make their product offerings more than just a set of functional modules. However, it has been difficult for many vendors to succinctly articulate the tangible benefits of SOA.

One of the better discussions of the benefits comes from SAP CEO Henning Kagermann, when talking about the 2007 release of Enterprise Services Architecture (ESA), SAP's version of an SOA platform. Here are key points Kagermann cites:

  • With SOA, software configuration and setup moves from a technical process to a business process;
  • Systems can be set up five times faster;
  • The total cost of ownership will be cut by 50 percent; and
  • The speed of change—e.g., introduction of a new type of business or process—will be 10 times faster.

If Kagermann's claims prove true, SOAs will indeed produce long-term tangible benefits—specifically, large IT costs savings. These costs savings can stem, in part, from tasks normally requiring systems integrators, and large internal support groups being automated away by the SOA. Kaggermann's vision of SOA's potential also is in line with the tenants of an IT "applistructure" (see MBT In Perspective, Applistructure: Hard to say, but of general interest), which could lead to companies having more resources to devote to innovative uses of IT.

 

Preventing IT SOS when pursuing SOA

Like many disciplines, the theory of service-oriented architecture (SOA) can be much more attractive than its practice. Here are a few things manufacturers should watch out for before embarking on an SOA project.

  • SOA isn't easy. Rather than hacking together code and systems to get solutions up and running, SOA requires a very disciplined and long-term view.
  • SOA by itself does not generate a return-on-investment (ROI). Any technology solution by itself does not generate ROI, but rather it is how the technology is used that will bring the benefit. That said, companies should not start any SOA effort unless they have a good idea of how it will be used, and how it will bring benefits.
  • SOA requires advanced effort. Much like the prep work to design, dig, and pour a foundation for a house, SOA requires that business users become involved in its early stages to define and create services that can be used around the company. If the business unit wants something fast and narrowly focused, it may not want to put in the extra effort required for a longer-term SOA benefit.
  • SOA requires centralization. A key goal of SOA is standardization of services and components. The best way to accomplish this is through a centralized group or small team that manages the architecture.

A morass of standards

Though service-oriented architecture (SOA) is supposed to make programming easier and software much more flexible, to get there, an array of standards and specifications needs to be deployed. These can be divided into three groups:

  • Syntax: This describes the formatting, location, and function of a service. This area has received the most interest, and encompasses many different technical specifications and standards—the most important being eXtensible Markup Language (XML); Simple Object Access Protocol (SOAP); Web Services Description Language (WSDL); and Universal Discovery, Description, and Integration (UDDI). Like the syntax of a sentence, technical protocols create a simple structure that permits easy inclusion and substitution of software services. The structure also permits two different pieces of code to connect with each other.
  • Context: This describes the meaning of the message. These efforts fall under what is broadly called business semantics that standardize concepts such as customer and address. Much of this effort is occurring via industry-specific groups such as RosettaNet (high-tech); CIDX (chemical); and cross-industry groups such as ANSI X12, and the Open Applications Group (OAGi). This group of specifications facilitates a common language and vocabulary that can be used by different systems.
  • Notion: This describes the notion of the message. For example, two companies may agree on the concept of a customer, which is defined by a context standard, yet they must come together on what the notion and definition of "good credit" or "expedited shipping" is. In these examples a combination of business processes and references must be created by the communicating parties. Notion is being addressed by the aforementioned standards groups, as well as above as well as WS-BPEL and BPEL4People, which that are creating process definition languages.

To be clear, these specifications merely scratch the surface, and do not reflect the company-specific takes on them as sold by Microsoft, IBM, Oracle, and SAP.

Email
Print
Reprint
Learn RSS

Talkback

We would love your feedback!

Post a comment

» VIEW ALL TALKBACK THREADS

Related Content

Related Content

 

By This Author

Sponsored Links



 
Advertisement

More Content

  • Blogs
  • Webcasts
  • Podcasts

Blogs


Sorry, no blogs are active for this topic.

» VIEW ALL BLOGS RSS

Podcasts

Advertisements





NEWSLETTERS
Plug in and get the latest MBT news, trends and industry updates delivered directly to your inbox!

Mid-Day Report (Twice Weekly)
MBT Europe (Twice Monthly)
White Space (Monthly)
Innovation Strategies (Monthly)
Intelligent Manufacturing (Monthly)
Lean Enterprise (Monthly)

About Us    |    Advertising Info    |   Site Map    |   Contact Us    |    FREE Subscription    |   Affiliate Links    |    RSS
©2009 Reed Business Information, a division of Reed Elsevier Inc. All rights reserved.
Use of this Web site is subject to its Terms of Use | Privacy Policy
Please visit these other Reed Business sites