Identifying Service Candidates

Here's some points taken from the book, Java SOA Cookbook.

These are the set of question one needs to answer before embarking on the quest of marking a software project as a service candidate. They are not really the ONLY guideline but its just few of the many things that you should consider asking first. Consider it sort of a checklist before moving on further in the game.

1. Could this functionality be appropriately designed to satisfy the definition of a service as stated in this chapter?

2. Is this service likely to be consumed across multiple platforms? Does it need to interoperate? Would external business partners have any use for this service? Does it need to cross functional barriers or firewalls? Can it use a popular protocol such as HTTP or SMTP?

3. Would implementing this functionality as a service help you break an integration barrier? Would it wrap or replace a proprietary point-to-point interface? Would it operate in front of ERP, CRM, financial applications, or other systems?

4. Does it clearly map to one or more business processes? Or is it simply a program? (It is generally accepted that services can map to a single process, but mapping to more than one process can offer more opportunities for reuse.)

5. Does the function that the proposed service represents cross business domains? This could point to a greater opportunity for reuse.

6. Does the service exchange business documents or fall readily into one of the three general service categories identified in Section 1.5.

7. Would a business person be interested in reports on the output of this service? Would IT be interested in monitoring its life cycle or runtime? Or perhaps it represents a functional or utility service that in the long term could increase general business agility. (If none of these, it may be too small an operation to merit a place in the service catalog.)

8. Does it offer business value? Is there an existing service commodity that already performs this function?

9. Is the proposed service the right level of granularity? (If it is very fine-grained, this will weaken the interface aspect of the contract, shrink the possibility of reuse, and promote undue chattiness. If it is very coarse-grained, it could be a candidate for a process service that decomposes into other entity or functional services.)

10. Would making this function a service allow it to be composable? That is, can it participate as a seamless blackbox with other services behind a unifying contract (like an orchestration)? Or does it represent just an isolated function, with little relation to other system components?

11. Does the candidate represent an idea with an identifiable life cycle? Can the business define the interface?

12. Is it advantageous if the software can be discovered dynamically (as from a registry/repository)?

13. Does it present an opportunity to aid in the goal of providing a "single version of the truth"?

14. Depending on the implementation, would the benefit derived from using XML to represent your data outweigh the performance hit for marshaling and unmarshaling to and from XML? Is human-readability of the documents exchanged a factor?

15. Would implementing this as a service lower the cost of future integration projects? Would it facilitate new products or business services?