Few have one, but every enterprise seems to want one. Service Oriented Architecture (SOA) is IT's hot new strategy.
| print comment
|Enterprises are adopting web services for short-term benefits. Defining an SOA strategy comes later, if at all:
- Most web services adoption is tactical
- Existing assets are easily converted to a services model
- As services spread, management is often a late afterthought
- Some companies implement SOA first
- Others recommend a mix of tactical deployment and strategic overview
Glossary terms: SOA, web services, XML, J2EE, EAI, lookup tool
Adoption of web services is providing the impetus. But web services vendors are the first to admit that few implementations take place in the context of an SOA strategy.
"Many of the uses of web services today are fairly unsophisticated, and yet they're bringing a lot of value," says James Phillips, senior vice-president of products and marketing at web services software vendor Actional. "What we're seeing is just tactical utilization of the technology a more pragmatic approach to get the things done that need to get done."
In a fully-fledged service oriented architecture, every software component makes its functionality available on demand, ready to be combined and rearranged with other participants in any number of different ways. The vast majority of today's web services deployments are but a pale reflection of this all-embracing vision, typically consisting of a simple link from one application to another.
"Inevitably a lot of the early web services projects are very much around point-to-point integrations," says John McGuire, vice-president of products at Cape Clear Software. "What they're getting is probably not ideal in terms of a service oriented architecture, but it's probably what they're trying to move towards."
Even those small first steps are providing evidence of the interoperability and flexibility claimed for SOA, he adds. "The reason customers talk about service oriented architectures is the early success of the point-to-point projects. They've shown that this kind of thing can work."
In part, the excitement stems from the realization that it doesn't take much to add a service-oriented veneer to existing infrastructure. Web services adapters now exist for the majority of legacy systems and enterprise application suites, while the J2EE-based web servers that run many heavy-duty e-business applications are even easier to convert for web services.
Once the functional logic has been exposed as a service, it remains available to other applications. "You only have to do the packaging as services once," explains Ishmael Ghalimi, co-founder and chief strategy officer of BPM vendor Intalio. "Everything appears as XML ... All your backend services are available as reusable services."
The unifying data model of XML is the key foundation. Irrespective of the original source or how it's being accessed, once the resource has been defined as a service it can be reused and combined in different ways. Provided the service definitions are standardized and consistent which the use of web services standards such as SOAP and WSDL helps to ensure then the promise of SOA can start to be realized.
Vendors are keen to point out that this doesn't require a huge development effort or a new layer of expensive middleware technology. Intalio maintains that in most cases its business process management suite will plug in directly on top of whatever's already in place. "That first step can be fairly simple," says Ghalimi. "We have the ability to integrate all the services and wrap them with a services interface." That allowed Intalio's customer BAe, the British aerospace and defense contractor, to skip a layer of EAI software when it automated a complex order management process, he says.
The ease with which a services infrastructure can come into being has left some customers scrambling to add a management layer to keep tabs on an expanding pool of services. "What customers tend to end up with is environments that are unmanageable," says Actional's Phillips, who points out that the ability to discover and use services on demand often puts unexpected stresses on the underlying systems.
That is the point at which the service oriented infrastructure has to become a properly managed architecture when the SO gains its A. "The first manifestation of an SOA is usually the appearance of UDDI or something similar," says Ian Bruce, spokesman for web services vendor Systinet. "From having tactically deployed web services, a need grows for advertising and discovering these services which also serves management's need for control and to promote reuse."
Some enterprises are not prepared to wait. A recent survey by specialist analyst firm CBDI found that 70% of its subscribers are already committed to using or adopting SOA. "Many CBDI subscribers are pursuing an SOA strategy without yet adopting web services," says principal analyst Lawrence Wilkes. "SOA is more about good design and architecture than it is technology."
But although web services is not a prerequisite, it makes the job a lot easier, he explains: "Web services adds the icing to the SOA cake by providing a better interface technology in which to make the services available. Besides platform independence it provides a richer specification, and is going on to provide a more complete set of protocols for security, transactions, orchestration, etc."
Think big, start small
The middle way is to pursue both simultaneously. Vinod Khosla, general partner at leading VC firm Kleiner Perkins Caufield and Byers, advises rolling out web services within the context of an SOA strategy, but not as a single, all-embracing project: "I just don't think one can renovate the whole company. So the way to do it is in short 90 day projects that drive towards the target of an SOA."
The key, he says, is to "think big" in terms of the overall SOA strategy, but "start small" with a rapid succession of short projects that each achieve a defined objective. "It's much more guerilla warfare than a big war," he says. "Start doing it selectively and get to harder and harder things later."
Web services software vendor Systinet has its share of customers who discover a need for an SOA long after embarking on service-based implementations, says Gregg Bjork, senior vice president of products and services. "We also have those who have an effort in place to build an SOA as quickly as they can. But that doesn't obviate their ability to do tactical implementations. They can do both." For example, the company is working with the architecture group of a financial services customer to develop an SOA, at the same time as implementing a smaller departmental project within the organization.
Initiating an SOA strategy as early as possible seems to make sense. According to Intalio's Ghalimi, it can also make it easier to sell web services adoption within the enterprise.
"The ROI for web services is not clear," he says. But put it in the context of a service oriented architecture, and it becomes a foundation to enable more agile process automation: "You're selling continuous process improvement, and XML and SOA becomes just another technical detail."
Nor should an SOA strategy attempt to put a brake on web services adoption just like earlier grassroots technology trends, it's unstoppable, insists Actional's Phillips. "This adoption's going to occur in an ad hoc manner. It's going to get into the organization regardless like the PC got into the organization."
More on this topic
"Which comes first? SOA or web services?" Phil Wainewright posed this question to Lawrence Wilkes ...
The legendary Silicon Valley VC is right on the mark ...