EDABlog

Lots of books and posts have been written but IMHO they fail miserably.
- They involve a new language/diagram
- They use propriatry tools
- Focus heavily on BPEL and you need services to drive the BPEL (mmm)
- They are overly complex. and hence violate the  most important rule KISS.

I prefer a loose guideline like the following.

1. Consider the large-grained logical services your systems represent (such as Accounting, Sales, Manufacturing, Design)
2. Ignoring political / divisional boundaries, consider each large-grained logical service and conceptualize how it should be broken up into finer and finer grained services (Accounting could be factored into Purchasing, Banking, Operational Finance, Expenses, HR Finance, etc)
3. Repeat 1 and 2 until you have a fairly detailed map of the system under consideration. Remember, Services are fractal - one service decomposes into more services which decompose into more services ...
4. Now, (again, ignoring political / divisional boundaries) try and identify common shared services - even though they may presently be siloed duplicates. Now consider what your system would look like if they were all consolidated into a single service instance (which of course may publish one or many service interfaces and the associated methods)
5. After consolidating as much as makes sense, map out the kinds of message exchange patterns between services. One-way (fire and forget), Request-Reply (blocking calls), Full Duplex (bi-directional async). Don't focus on transports or protocols here, talk about the higher order semantics "this link needs to be secure", "this link needs to be reliable", etc.
6. Refactor services  so services that communicate frequently are upscaled eg if you have a Order service and seperate service for OrderItems refactor them into the same service
   
7. Now map out the data structures that should be passed between services when actions are requested and the responses when complete.
8. Now consider what will be your organization's strategy for inter-service communications? Are you homogenous? What is the strategic direction of the platform(s) on which you build systems? If you have to interop, what will be your strategic direction? Remember, whatever lies INSIDE a service is irrelevant to the outside world, so let's not consider service internals here.
9. Once you know how your services will hang together, you can then start deciding on how to wrap/expose existing systems to the outside world, and where and with whom you want to bet on strategically to deliver the platform(s) for your future needs.
10. Wrap existing services before writing new ones.

based on Richart Turners original post