"Which comes first? SOA or web services?" Phil Wainewright posed this question to Lawrence Wilkes, principal analyst with CBDi Forum, in the course of researching the Loosely Coupled feature article published today, Tactics, not strategy, drive SOA adoption. His reply was immediate and detailed, so we have agreed with CBDi to publish the full text of Phil's enquiry and Lawrence's response.

	express delivery
	• print  • comment
	The application of web services protocols doesn't guarantee the delivery of good services. SOA is about the proper design and architecture of good services. Lawrence Wilkes is a principal analyst at CBDI, an independent analyst firm and think-tank focusing on best practice in business software creation, reuse and management. CBDI recently published Moving to SOA, a draft chapter from the firm's forthcoming Web Services Roadmap Report.
	Glossary terms: SOA, EAI, SOAP, lookup tool Sponsored links: your text link here

Phil asked: Which comes first? SOA or web services? There seems to be a lot of service encapsulation already implemented in enterprises, irrespective of whether web services are being used. Is there a 'tipping point', some kind of critical mass of services, at which an SOA comes into being, whether planned or not? ... based on your research of customer experiences, what elements of existing enterprise infrastructure, leaving aside web services, are already in place that form part of an SOA infrastructure?

Lawrence replied:

1. Service is the important concept. Web service protocols are just one way to implement them. Probably the best way though.

2. Good services are a facet of design, not the application of any particular technology.

3. It is very easy to build poor web services, and many people unfortunately will. The application of web service protocols does not guarantee the delivery of good services. In the same way that the simple application of Microsoft COM or Java EJB did little to guarantee the delivery of well architected, truly reusable components.

4. SOA is (or should be!) about the proper design and architecture of good services. A good service will be properly abstracted away from the implementation, and hence more meaningful to the consumer of the service at a business level. Whereas just wrapping an existing interface with SOAP might make it a web service, and might remove some of the technology dependencies, but it is probably no better or meaningful a service than it was before.

5. 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. These protocols will also provide a mechanism to better express some key SOA principles, like contracts, SLA, pre/post conditions, etc, which were rarely provided by existing interface mechanisms.

6. Many CBDI subscribers are pursuing an SOA strategy without yet adopting web services. SOA is a natural evolution of good [Component-Based Design] CBD practices, so we would expect our mature subscribers to do this. Several of them wanted to participate in the survey but didn't because they were not implementing web services yet. Had they done so, then the 70% commitment to SOA would have been higher. Though I guess I would admit that we have a self-selecting survey here - we would expect subscribers to a forum for best CBD and web services practices to be pursuing best practices :-)

7. The challenge for them (6) is how to deliver their services without point 5.

8. Tipping point for using SOA would be things like:

   • recognition of need to deliver cross functional systems
   • with need to reuse existing assets
   • understanding that long term agility comes from focusing on the delivery of services and assembly of solutions from them, not the implementation
   • understanding that (current) technology solutions alone don't deliver the agility required. E.g. EAI solutions end up locking you into a proprietary EAI product.
   • recognition that approaches like EAI are too focused on the current implementation. E.g. EAI helps you integrate Siebel and SAP, but isn't really addressing the problem of integrating Customer with Sales Order. A subtle, but important difference. Long term agility comes from shifting focus to a higher level of abstraction of customer and sales order services, not on the Siebel and SAP interfaces.
   • SOA does become more critical the larger and more diverse the organization. You would tend to see larger organizations pursuing SOA first, similar to those who did proper CBD. They recognise need for architected solution.

9. Then the tipping point for web services would be

   • solutions and services need to span diverse technology
   • need to deliver services where the consumer has no access to, or visibility of the implementation. This is perhaps primarily External, but is equally applicable to Internal usage of the services. The only thing they can see is the service - hence you need web service to provide the more complete, more rigorous specification. (etc)

10. Challenges with adopting SOA tend to be

    1. Investment. Business is often more interested in solving current problems, than providing a better foundation for the future. Just connect Siebel to SAP please, we will worry about the future tomorrow...
    2. Skills. Too many developers focused on low-level implementation, not enough on higher level abstraction. It is a different skill.
    3. Techniques and tools. SOA best practices, and their encapsulation in tools only just emerging.

11. In terms of existing infrastructure (not web services) being used for SOA, then it is varied. As stated, SOA is more about good design and architecture than it is technology. As such it can easily be practised with 'old' technology. We saw the same phenomenon with CBD. Some of the best CBD practitioners were (and still are) continuing to use their mainframe technology as opposed to COM or EJB. 'Bus' type technology is useful such as message queuing and/or ORBs, as these can provide a measure of implementation platform independence that takes a step towards delivering more useful services, as opposed to platform specific interfaces like COM, J2EE.

Hope this helps
Lawrence Wilkes, CBDI

More on this topic