In my opinion one of the things that are holding back the wide adoption of SOA is the abstract concept of service. It conveys really vague meaning that you are asking someone to do something for you. But, what is that? Most of the people interpret the service as Remote Procedure Call (RPC) or sending a message.
I believe that we are going to make a breakthrough in SOA adoption if replace the term service with concrete service types that developers and business people can relate to. For example we build applications:
– data;
– operations – programming logic;
– presentation component;
We can define standard interfaces for data service, operation service and presentation component service.

It is much easier to approach the business saying:
– Which data do you want to standardize? Customer, Order, etc. We do not need to discuss specific methods (like how to search for customers). It is handled by data service interface. At some point we need to define the access control to data for different user roles.
– Which business operations do you to standardize? Check customer credit, address validation, etc.
– Which presentation functionality do you want to standardize? Those are coarse-grain presentation components that implement certain workflow like: Make payment, Select cell phone plan, etc.

Conceptually every enterprise application can be a client or server of such services, but it also may make sense to deploy the services in specialized enterprise repositories.

The benefits are really obvious when coupled with an application-level architecture that is based on the same service types. For example it gives developers the flexibility to get a data object from locally implemented data service (using access to DB), another application or Enterprise Data Repository.