A true measure of a technology's usefulness is its transparency to users. For defense contracting giant Raytheon...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Co., the service-oriented approach to application development easily passes that test.
Service-oriented architecture (SOA) is at the core of a Web service that Waltham, Mass.-based Raytheon uses to connect a parts-tracking application with data stored on its mainframes. Rob Vettor, a senior business technologist in Raytheon's enterprise applications group, said that users "don't really understand or care that this is service-oriented architecture." All they know is that they can access data about parts regardless of what system they are using.
The business case for SOA is based on its potential to allow enterprises to reuse components of an application for other purposes. These become "services" that can be shared by other applications on a network -- hence the term "Web services." While SOA dates back to the 1980s, it wasn't until Web-based applications popped up during the Internet boom that the programming concept gained widespread attention.
Meanwhile, SOA's predecessor, object-oriented programming (OOP), is beginning to fall out of favor, as more business transactions become computer-to-computer communications.
Heavy versus lightweight protocols
"The thing about object-oriented architecture is that it's really meant for operation on a single machine," said Ronald Schmelzer, a senior analyst with ZapThink LLC, in Waltham, Mass. "Things started to break down when people tried to extend the notion of object [oriented] programming across multiple machines."
That's because object orientation is built around "heavy" protocols such as Common Object Request Broker Architecture (CORBA), Internet Inter-Object Request Broker Protocol (IIOP) and Distributed Component Object Model (DCOM). "These things were not very good for operation across the Internet," Schmelzer said. SOA, on the other hand, uses lightweight and flexible protocols such as Hypertext Transfer Protocol (HTTP) and Simple Object Access Protocol (SOAP).
Anne Thomas Manes, a research director for Midvale, Utah-based Burton Group, said that she's been promoting the idea of SOA for about 25 years. "The service-oriented approach is the way to build systems if you want them to be flexible and adaptable and you want reusability," she said.
Incentives needed for reusability
The problem is that developers don't have an incentive to build applications as reusable services for other IT projects. Thomas Manes said that there are two ways to break this mindset. The first is to provide a financial reward to those who make the extra effort to create reusable code. The second is a disincentive. For example, one of her clients, the CIO for a financial services company, grew tired of seeing resources wasted through duplication. In one instance, he told his developers that if he saw two people creating the same "open an account" application, they'd both be fired.
As harsh as that sounds, it's sometimes necessary, she said. By creating a single "open an account" application with reusable components, that company could more easily build related applications for portfolio management, commercial accounts, warehouse accounts and 401k accounts, Thomas Manes said: "It's much, much more challenging to create a reusable service than it is for a specific purpose."
The importance of changing mindsets was a lesson that Raytheon learned from its parts-tracking Web service, an internal service that bridges the gap between Web-based applications and the mainframes where critical data about parts resides. The service, built using Verastream integration software from Seattle-based WRQ Inc., was first tested with business units based in North Texas, and has since been rolled out in Florida and California.
Adjusting to a new IT paradigm
Besides the technical challenges of creating reusability, Rob Vettor's group had to convince other IT professionals that it was a good idea. "It was a paradigm change to get people to say, 'Hey, it's OK to let people write a service that goes against the mainframe and populates data in a Web application,'" Vettor said. "I think everybody in IT is adjusting to that paradigm."
That was also the case for an IT project manager with a Fortune 100 financial services firm who asked that he and his company not be named. The company, which will put two internal insurance-based services into production in March, had to obtain buy-in across a number of "touch points," including developers, infrastructure administrators and database administrators.
Surprisingly, business-side buy-in for SOA was much easier for both companies. For Raytheon, which has 78,000 employees in its six business units, the return on investment was proved through the efficiencies that were created using the tracking service. The ROI for the financial services company's IT organization was its ability to create a service for a fraction of the cost and time of a traditional enterprise application integration (EAI) project.
"A single [service] project now can basically justify the cost of something you can use, [from] an enterprise perspective," said the Fortune 100 company's IT executive.
Give developers the proper training
One other major challenge to adopting SOA is finding developers with the right skill sets to actually create service-based applications.
John Robbins, a co-founder of the Knoxville, Tenn.-based Windows consultancy Wintellect, said that IT developers have gotten pretty good at writing client applications during the past two decades, but they face a steep learning curve when it comes to writing the high-volume server applications required by SOA.
"Many of the performance problems we are called in to debug are directly related to developers' using the client-application mindset to a service-architecture problem," Robbins said.
He said that wise companies will make sure their developers have the proper training and experience in service architectures before they undertake a major SOA-based project.