SOA: Getting Good Service

By Michael Fitzgerald  |  Posted 10-13-2006

SOA: Getting Good Service




SOA can help IT departments become more efficient while allowing them to put together systems that can boost their company's business.
At many companies, IT falls on the cost side of the ledger. Which is why so many technology executives are attracted to the idea of SOA, or service-oriented architecture.

SOA is basically a computing architecture built around services—computing components that can be flexibly reused and recombined. In an SOA environment, which leverages standard mechanisms including eXtensible markup language (XML), software components advertise themselves on the corporate network as offering a service, such as a verification message, that other applications can discover and use. This makes IT more productive because, in part, it's much simpler to change a service, such as a verification message, than to change each verification message in every application that has one.

At Railinc Corp., a transportation logistics firm based in Cary, N.C., Garry Grandlienard, director of enterprise architecture, notes that many of his company's applications draw on certain basic information about railcars, stored in one main database. Before SOA, changing one element of that database might have meant changing 100 applications. With SOA in place, he may not need to make any application changes at all, since he can change the service layer and it will translate the database change for all applications.

Farmington Hills, Mich.-based RouteOne LLC is an exchange established by the finance arms of General Motors Corp., Ford Motor Co., DaimlerChrysler AG and Toyota Motor Corp. to provide auto dealers with access to a variety of financing options and services. Here, SOA gives CIO Joel Gruber a cost-effective way to make changes to his internal infrastructure without disrupting all the firms that use the exchange. In August, RouteOne began piloting an electronic contract feature, called eContracts, to allow auto dealers to forego paper contracts. Key to the eContracts pilot is a service the company built to test its messaging environment. At RouteOne, a transaction, such as an auto loan application, is treated as a type of message, and the testing environment lets the company see if new message types will cause any problems. "It doesn't sound like a service," notes Gruber. "But it's a utility service that means we don't break anything for our customers when we change something."

The kinds of efficiencies being realized at Railinc, RouteOne and elsewhere are leading corporate America to embrace SOA technology. Forrester Research Inc. predicted in April that more than half of all large U.S. companies will be using SOA by the end of this year, and of those currently using it, almost 70 percent intend to increase their use of it in the future.

And many of these companies—46 percent—are looking at SOA for more than just cost-cutting. They believe it has the potential to make a strategic impact on their businesses, helping to expand partnerships, connect more effectively with customers and suppliers, and develop entirely new offerings. IBM Corp. claims that about two-thirds of its 2,700 SOA customers are using the technology to help create new revenue streams.

That's what Automatic Data Processing Inc. is trying to do. Best known as a payroll processor, Roseland, N.J.-based ADP is using SOA in part to create a portal that gives the same look-and-feel to the dozens of products it offers, ranging from its famous payroll processing application to human resources administration tools.

Its product line, built in part by acquisition, uses many interfaces, which makes it harder for ADP to sell multiple applications to clients, who would have to train employees to use each one and remember different passwords. Now ADP is moving to put a common interface on its applications, using SOA behind the scenes to call up application data through the service layer.

Bob Bongiorno, senior vice president and CIO of ADP's Employer Services unit—the company's largest, encompassing payroll, tax and compliance, benefit, and human resources administration, each of which has multiple products at ADP—says SOA allows the company to offer bundles of its products to potential customers, as well as expand the number of products used by existing customers.

While he's careful to point out that SOA does not by itself generate revenue, Bongiorno says that the Web portal has been a success. And he notes that ADP's revenue growth is solidly back into double digits since the portal went into place—the company grew 11 percent last year, and expects to grow another 10 percent in fiscal 2007.

Meanwhile, last year ADP started selling payroll services through Microsoft Corp.'s Small Business Accounting Package. ADP's payroll product for small businesses is hooked into the Microsoft package using a service architecture to exchange data. And the Microsoft partnership is a harbinger of more such arrangements to come, Bongiorno says.

Despite ADP's successes, however, Bongiorno cautions other CIOs to beware of the hype, and make sure the technology fits their business needs before going down the SOA path. But how do companies make sure SOA fits their business needs? For ADP, it was simple, since most of the company's applications involve similar data: name, address, employee ID number, phone number. Each bit of information is a transaction, and ADP can write a service for it that

applies to all its applications. By adopting SOA, the company also created the potential for partnerships like the one with Microsoft. "The technology we have now has opened up a world of opportunities," Bongiorno says.

Ask the business side:

Will creating data services help you more effectively cross-sell products?

Ask developers:

Which data is most easily represented as a service?

Click here to download a PDF of our SOA fact sheet.

Next page: Implementation

1 | 2 | 3



It's difficult to measure the impact of many services, making it a tough sell to the business.
While SOA has real promise, business managers may turn a jaded ear to the latest wonder acronym. After all, many new technologies require years of heavy spending on complex projects that fail as often as not. And SOA faces additional hurdles: Its promise of faster development and reusable code is nothing new, and the concept can be hard to explain. "SOA is a very broad hand-waving term," says John Devadoss, director of architecture strategy at Microsoft.

"SOA is a tough sell on the business side," seconds Matthew Quinn, chief technology officer at SOA vendor Tibco Software Inc. He says smart CIOs should instead emphasize how they can change business processes.

But that's easier said than done, adds Railinc's Grandlienard. He says it's difficult to measure the impact of many services, and metrics tend to focus on things like faster turnaround times or less need for quality-assurance testing, metrics not always obvious to business units.

Ron Schmelzer, an analyst at ZapThink LLC, believes that IT needs to make it clear that SOA allows the business to increase its control over software. "The business process becomes the application in a way that it wasn't able to before," says Schmelzer.

But SOA is not a panacea. It can create headaches, such as the need to store, catalog and manage hundreds or thousands of services so they can be reused. It will help business applications that change frequently, such as those in financial services companies, but may not be worth the effort for other kinds of applications, Schmelzer says, such as those that don't handle many transactions.

And many of the benefits of SOA mean little to business departments, says Randy Heffner, an analyst at Forrester Research. He says that much of SOA currently involves what he calls "service with a lower-case S," mostly good for application integration and other IT uses, rather than more strategic applications of SOA, such as that being done at ADP.

Indeed, developing an SOA strategy requires the IT department to have a deep understanding of how the business works. Yet, combining business knowledge with tech savvy is an uncommon skill—the most significant reason why companies tend to get better at using SOA over time.

Tell the CEO and CFO:

SOA's benefits go beyond easing IT's burden.

Tell business managers:

Think about services as a strategic tool in your business.

Next page: The Future

1 | 2 | 3

The Future

The Future

IT departments implementing SOA will need people who truly understand the business.
While lots of hot new technologies take years of hard work to deliver on their promise, that's not true for SOA. Once up to speed on the technology, an IT staff can churn out dozens of useful services. Part of SOA's value is that it doesn't take six months to design a Web service and implement it, only to discover a design flaw that requires a major fix. As IT gets more familiar with services, the way it applies them is likely to shift toward uses that are sophisticated, complex and business-changing.

Still, many CIOs stress patience in implementing SOA. Stuart Johnson, general manager for integration and service-oriented architecture at Commonwealth Bank of Australia, says that when the bank began building services in 2002 and 2003, his staff quickly got up to speed on "atomic" Web services—services that perform a single function. These proved the concept and the developers quickly started to push for building complicated composite services that would combine many services, but Johnson held off.

"I wanted to keep the technology as simple as possible. SOA is already the next buzzword, but a huge SOA architecture will make it difficult to build anything," Johnson says. He wanted to make sure the bank understood how to manage SOA.

Commonwealth Bank links technical and business analysts together to develop new products, and many of them were pushing to use services to expose more data online to customers and to partners on the Bank's back-end systems. Johnson was leery at first, due to data security issues. Also, the bank is in the midst of a major systems initiative it calls CommSee, which now has close to 2,000 separate services. So before he started with SOA, Johnson spent time with Microsoft discussing SOA frameworks. It wasn't until 2004, after almost a year of working with the services concept, that the bank started to build the first of what it calls "orchestrated" services, in which it used a series of services working in concert.

The bank's first orchestrated service was designed to help customers open a direct-deposit account. Opening an account requires a series of steps that can take as long as six weeks, and Johnson says the bank may access up to 40 different data sources. Commonwealth Bank used SOA to see if the customer had filed appropriate documents (to verify identity, for instance), to make sure there was money in a checking account before a checkbook was issued, and to issue a bank card.

Initially, the bank designed the system to kick it back to the customer if there was an application error. As the system rolled out to more branches, that became vexing to customers, and Johnson's group built services to make the system handle it. "It would've been difficult to do from day one," Johnson says.

Like many IT managers, Johnson knows there simply aren't enough technology types who truly understand the business side, so many of his developers focus on business rules and specifications. Other IT organizations have done things like split into groups that are attached to their business functions, to make sure the services match business needs.

Railinc, for instance, is moving toward creating a committee of business and technology managers to help it set priorities on which services to build. The company has more than 60 services in use, but is only now developing a service to handle all its e-mail notifications, which it sends out in multiple formats.

Commonwealth Bank's Johnson says the technology was "quite painful" at first, in part because he was building basic elements of his infrastructure that will soon be built into vendor offerings like Microsoft's Web services platform, Indigo. He is cautious about over-blowing the impact of SOA at his company, especially since the firm has gone through a huge technology upgrade and an internal reorganization. But the service architecture is clearly valuable, and he says he's looking forward to SOA "becoming a commodity."

Ask your architects:

What are the first steps we should take toward SOA?

Ask the CTO:

How will SOA change the company's entire infrastructure?

1 | 2 | 3