While it is easy to see the benefits in the idea that services expose explicit boundaries, there is still some distance between this and understanding where service boundaries should be drawn and what it should look like.  A collection or recent posts from three Microsoft Architects highlight that services work best at the business level where they can share the same logical data model and single database engine.  It's nice to see the SOA discussion break through the academic debate to this practical guidance level.

Ramkumar Kothandaraman, a Solutions Architect on the .NET Enterprise Architecture Team, talks about  implementing the service-oriented tenet that services should have a clearly defined boundary when there are issues about searching or updating the shared data.  He proposes that it can be beneficial to share a database between related services and to expose these services as a collection or business services that share the same logical data model, rather than individual services. 

I believe this is similar to Pat Helland's session at the PDC where he spoke about business services encapsulating database-resident data and that each business services' data should live in a single database engine.  If the data can't fit into a single engine then look for ways to split it into two business services but don't have a service span database engines.  If the service needs to scale then consider partitioning the data between individual database servers rather than trying to merge and replicate.

Michael Platt, a UK-based Field Architect from Microsoft, shares the view that services need to be exposed at the business level.  He provides a useful, pragmatic definition of service oriented architecture as a model or abstraction of loosely coupled business-level functionalities or services.  I also enjoyed his reflections on a recent meeting discussing SOA:

There was a lot of discussion about what SOA was: explicit boundary’s, autonomous, etc which reminded me a lot of the COM definitions but with different words. Alas there was no discussion as to what a Service should look like, how big, what level of functionality etc; this was left as an exercise for the designer.

In terms of guidance on how to architect services, he mentions a story of the good old 'component oriented architecture' days where a client had 3000 components in a system, as a warning not to go overboard again.  Michael also invokes his 'First Law' as design guidance for a services which essentially says that that services should be coarse grained because of the huge communication and network stack they have to go through.