Last month I listened to a podcast by Dan Farber from ZDNet, SAP's Shai Agassi: Unplugged, in which Agassi is promising that future releases of SAP will have ten to twenty thousands Services. A week later, in an InformationWeek's article titled SAP's Architecture Shift, AMR research analyst Jim Shepherd was quoted saying "Until they [SAP] take that giant application and break it into thousands of Web services, I don't consider the application a service-oriented architecture platform". (!)
So far I had to struggle with bespoke Services proliferation; having additional tens of thousands of services from SAP, Siebel et al., sounds to me like an IT torture fantasy by some IT Outsourcing conglomerate.
Proliferation of Services prevents a reusable, sensible, enterprise scale adoption of SOA. What exactly should I be doing with 20,000 services? Build IT Applications around them? Read their specifications? Juggle with them? Juggling is a good idea.
For one thing must be said straightforwardly: Services proliferation is not going to shorten IT Time-To-Market, nor is it about to imprve productivity or software maintainability.
Clearly, a higher abstraction-level that will reduce the number of available Services is required. I suspect, though, that the Packages Vendors (such as SAP) would argue that these Services are "already" coarse-grained and high-level and that they represent not a single function, but rather an entire Business Process (such as the "Track Shipment" mentioned by Agassi in the podcast). And in an Enterprise, thousands of Business Processes exist…
If that's the case, then we should probably rethink the whole thing: no longer a coarse-grained Service per Business Process, but rather a coarse-grained Service per Business Entity. CRUD Services on Business Entities. "Track Shipment" is nothing but a Read operation on the "Shipment" entity, asking for its "Location" attribute (+ the attribute's historical values).
Naturally, these coarse-grained Business Entities Services should be built on top of finer-grained Services – and that's fine as long as they are not exposed to application developers.