They say that having a hammer in your hand makes your problem look like a nail. That’s bad if it makes you feel that pounding harder is the same thing as doing more work, even when your problem would better be solved with a welding torch — or perhaps just a tube of glue.
In the same way, having a WebMethod attribute in your programming language can make service creation look like productivity, even if your problems of service discovery and governance are growing more quickly than your savings from service re-use.
Before you start pounding out service definitions, I commend to your attention an essay by Mark Palmer on the subject of architecting services to solve your actual business problem. Mark makes some key points:
- There’s no longer a useful distinction to be made between internal and external applications
- Interface definitions should anticipate change
- Loose coupling minimizes life-cycle cost but requires more up-front design
If you’re looking for a metaphor that explains good SOA design to non-coders, I don’t think you’ll do better than Mark’s comparison of ordering shoes by phone compared to requesting and using a catalog. Abstract ideas like self-disclosing data and asynchronous communication can be tied in this manner to people’s everyday experience: the result, one may hope, will be more engagement from business process owners and stakeholders in the up-front tasks of designing both individual processes and multi-process workflows.
After all, we’re trying to make the Salesforce Platform a more capable SOA workbench, not just a bigger hammer.