It's becoming increasingly clear to me that there are two different opinions about what SOA is. I'll call them project-level SOA and enterprise-level SOA. Here's what the difference appears to be...
Project-level SOA is, as the name implies, about the architecture of a single project. The project usually involves service enabling a number of existing backend systems, then building new "front-ends" on top of these. These front-ends may either be other services or new user interfaces. Often what spurs these types of projects are a lack of consistency in the existing front ends (e.g. no single view of a customer) or a lack of flexibility in the existing front-ends (making it hard to add new tailored offerings). Often, the services need to be made available via multiple "channels" (e.g. call center, web self service, voice response, or even 3rd party aggregators).
Of course, calling this "project-level" isn't denegrating it at all - these projects can be massive efforts that are core to a business (such as Startwood's SOA rewrite of their entire reservations system).
The interesting thing about project-level SOA is that, in many cases, it doesn't actually require web services. The reason is that, since it's a single project, run by a single team, running on a well defined set of platforms, this team can choose whatever messaging/integration technology is appropriate (e.g. works on the specific platforms the project needs, etc.) and every part of the project can be versioned in conjunction with one another.
There are really two cases that spur the need for web services in project-level SOA:
If the services need to be exposed to the outside world (e.g. for electronic access by partners)
If this is the first phase of an enterprise-level SOA...
Project-level SOA is centered around solving very specific business pain points, so the set of services required is well defined and well scoped in-advance.
Enterprise-level SOA, in contrast, is about overall business efficiency and aligning IT with business. Enterprise SOA focuses on reuse, consolidation, elimination of redundancy - all of which lead to lower cost of ownership and quicker turnaround of new initiatives. Enterprise SOA is not a "thing", it's an architecture - a way IT projects should be structured. You never "finish" building an enterprise SOA (unlike a project-level SOA).
While the mechanics of project-level SOA and enterprise-level SOA are fairly similar (building and using services), enterprise SOA departs in a number of key respects. Some examples:
Enterprise SOA generates interdependencies across projects (where the projects may be run by different teams, roll out on different schedules, use different platforms, etc.)
You don't know about all of the uses for a service when the service is created (people will find other creative uses for your services once they are published - I've seen examples of a service built for 5 well known uses, but where it ended up getting used for an additional 30 unexpected cases!)
These differences, while they sound small, have a profound impact on the way you need to run an enterprise SOA initiative (including issues of SOA governance, compliance, separation of responsabilities, design-for-reliability, etc.). I'll touch on some of these in future entries. For me, personally, I find enterprise SOA to be a significantly more interesting (and challenging), in large part because the challenges aren't just technological, they are organizational.