| |
Wednesday 30th July 2003
COMMENTARY - PACKAGING SOA
| LINKS
BEST PRACTICE REPORT -
SERVICE BASED PACKAGED APPLICATIONS
In this report we ask the question, is Web Service technology the future for packaged application delivery? Web Services offer an easy, inexpensive, standards-based solution to enterprise integration issues and mobile workforce collaboration. As such we can understand why a hosted CRM vendor might slap a SOAP interface on top of an existing API so that third party developers and enterprise customers can extend and integrate their package, but does this make it a Service Oriented Architecture? We think not. We examine two public domain examples - Amazon and Salesforce.com. Report available to Silver and Gold members at:
CBDi Report
ROADMAP REPORT -
ISVS AND PACKAGED APPLICATION VENDORS START HERE
This report looks at how Web Services will impact ISVs and how they must adapt their software packages to support both the provision and consumption of Web Services.
Report available without registration and login at:
CBDi Report | ABSTRACT: Is there a quick way to tell whether your application provider (vendor, internal project team or systems integrator) has implemented an effective SOA? We show you how to quickly recognize whether your supplier really understands SOA.
Many of the package vendors are claiming Web Service support in their products. Many internal project teams are using Web Services as the foundation of their "agile architecture". But Web Services alone do not a Service Oriented Architecture make!
Let's consider two reasonably well known products that are claiming Web Service support, and consider whether they have really understood what their customers are going to need -Amazon and Salesforce.com.
If you look at AmazonWebServices WSDL (see link below) you find a complete definition of the relevant parts of the Amazon business model. Services are named and organized as meaningful capabilities, that you and I would find useful such as AuthorRequest, AuthorSearchRequest, ArtistSearchRequest and so on. The services offered are organized and described in a manner that reflects how the consumer or user would want to use them.
In contrast if I look at Salesforce.com, (see link below) what I see is an existing API has been opened up. Example operations in the WSDL are named describe, insert, update, delete. A quick look at the technical documentation confirms the first impression - Salesforce.com has a general database CRUD API that offers basic operations on a list of entities. There is no service orientation whatsoever. Of course I "could" build a set of business objects to cluster and encapsulate the entities, but surely Salesforce.com should do that? Why should every Salesforce.com customer have to reinvent the wheel?
Based on the services on offer from Amazon and Salesforce, we can make intelligent guesses about the development processes that each organization may have followed. I think we can reasonably conclude that Amazon has followed an effective development process which is based on understanding how the services may be utilized. In contrast Salesforce has followed a defective process which is based on evolving the status quo and making minimal alteration.
It appears that Amazon has actually thought about the services from the demand side, Salesforce has only thought about the services from the supply side - based on the functionality and structure of their legacy systems and databases. Of course, this is a very common approach, not just with application package vendors but also with end-users trying to put service interfaces on top of legacy applications. Of course the temptation to wrap existing applications and to avoid invasive surgery, is great, and this is exactly what wrapping is all about. Package vendors might also comment that an entity based approach is the most flexible approach because it assumes no business purpose.
But the result of this approach is that the Salesforce services can only be used by people who buy into the specific application model supported by Salesforce - both data structure and orchestration/workflow. Salesforce therefore needs to provide these models (perhaps in the form of application templates) to support organizations who want to use their services. These services are therefore likely to have a wider dependency horizon than strictly necessary. Whereas the Amazon services do not depend on the adoption of a particular application model, and can therefore be used selectively and orchestrated to fit the business needs of the user organization.
The contrast between Amazon and Salesforce surface several important questions:
1. Is the Salesforce path a reasonable first step? Many organizations will find it easier to wrap non invasively, and this is a lower cost, incremental approach.
2. How can an organization follow the Amazon path rather than the Salesforce path?
3. What about organizations that have already followed the Salesforce path? What are the issues and cost impact? Could a suitable service bus be constructed retrospectively?
4. For user organizations - given a choice, is it always better to use Amazon-style services rather than Salesforce-style services? Are there circumstances which would indicate Salesforce-style services would be preferable? For example would more granular services offer greater flexibility?
Regular readers will be familiar with the concept of the Business Service Bus, developed by CBDI. The Service Bus is a logical service backbone that defines the common, shared and private Services and their dependencies, providing a shared business and IT perspective in an implementation independent manner. If an application supplier is merely wrapping their application and exposing services they may be able to deliver Web Services more rapidly, but they will not offer an adaptable foundation in the longer term. I seem to recall that all that glisters is not gold . . . . ! |
| | Read Full Article / Link to referenced materials |
|
Home