Emphasize coarse-grained business services: Business services contain more logic than component services, so they encapsulate more business value, are more difficult to create, and are more costly to get wrong. Engage your customers, analysts, and other stakeholders to understand their current and future requirements. Design service interfaces that facilitate reuse and extensibility. Focus on quality over quantity.
I wrote about business services and rules yesterday and Thomas Erl discusses them at length in the webinar I reference. One of the core value propositions of a business rules management system is the ability to let "customers, analysts and other stakeholders" directly manage the business rules in their service. This helps eliminate mismatches between requirements and implementation.
Automate as much as possible: Where possible, build services to automate manual steps to reduce costs and errors, both internally and in your interactions with customers, suppliers, and partners. Create process-driven composite applications by orchestrating services using the de-facto standard Business Process Execution Language for Web services.
The key thing here is the "build services to automate manual steps". Many of these manual steps are manual becuase they require judgment, review or expertise. These steps are really hard to automate with traditional coding approaches becuase the programmers don't have the business knowledge and the knowledgeable folks cannot review the code. A business rules management system cuts out this impedance and plugs the person who understands the decision more directly into the implementation. If you are building services to automate manual decisions you should definitely use business rules. One example of this kind of manual step is insurance underwriting.