Following a recent posting on a SOA success story http://blogs.oracle.com/davidchappell/2008/04/soa_helps_you_move.html , I got some important feedback http://tech.groups.yahoo.com/group/service-orientated-architecture/message/10092 on how the writeup was a bit slanted towards highlighting the use of the tools and infrastructure such as BPEL and ESB, and didn't talk enough about the services themselves. The point being made that Service Oriented Architecture is about service orientation, and all too often the folks who live and breath the supporting infrastructure tend to gloss over the part about the services themselves.
I plead guilty.
So as part of my retribution, I would like to provide some nuggets of wisdom on service design that came out of the Move project -
The Prospect to Cash business process includes a number of very large applications (PeopleSoft, Siebel, Oracle Customer Data Hub, and a variety of fulfillment applications). CSC used the following criteria to identify service candidates:
- Is there similarity in the type of data that needs to be passed to various applications? If so, then the business logic in each respective application that operates on that data is a candidate for service enablement. The resulting collection of related services are also candidates for participating in a canonical data model.
- Does the business require part of an application to be used by both internal as well as external customers and partners - what are those parts and can they be broken into smaller atomic functions?
- Here is one that is bound to be a subject of discussion - A key service design consideration is that there is no direct interaction between two services. They are self sufficient atomic functions that can be used to build orchestrations by the business e.g. - customer data needs to be created in Siebel, PeopleSoft, Oracle Customer Data Hub and the fulfillment system. Each one needs a different component of the data. This raises a question - is "Create Customer" a service or should it be broken into "Create Customer, Create Address, Create Contact, Create Fulfillment Profile"? The answer largely depends on whether each of these services is complete in itself, and depends on the nuances of the business. On first thought, for instance, it may appear that an address without a customer may not be very useful. But if you are someone like Move the rules are different in this case. When they display a house on their website, they don't display the name of the person, they only display the address and the fulfillment profile. So for Move it makes sense to have them as separate services and business can decide how to string them together via BPEL to achieve business results they are intending to achieve.
A similar example can be given about the external customer who needs to consume these services. If you want to update some information about your house, there is only specific information you can update. So that would help determine what the service interface would look like.
The overall experience from the team about building the SOA at Move, Inc is that it is very easy to get carried away into JBOWS (Just a Bunch Of Web Services) mentality, without having proper checkpoints in place in order to ensure that the right services are being built for the right reasons. To do it right really requires proper analysis and a "business case" for each logical function to make it candidate for being Service. If you follow this practice judiciously, you will not end up with JBOWS.
Dave
