What is an Application in SOA?

A colleague of mine recently turned me onto Clemens Vasters blog (Thanks Rob!). Clemens latest post was entitled "SOA" doesn't really exist, does it? It led to some interesting thought but I'm not convinced that any architecture really exists in the true sense of the word when it comes to "SOA". I did agree with most of what he had to say in his blog and that most people use "SOA" as a label for the engineering components of "SO" which really isn't what Service Oriented Architecture is all about.

Another perspective to overlay on this discussion is the notion of an "application" in SOA. In SOA you have a federation of co-operating services that are orchestrated to achieve a well defined goal or objective. This is a completely different architectural model from what we have traditionally considered an "application" to be.
 
Traditional application models grew from from the notions of task automation that originated in the late 60s and the 70's. They were narrow and deep in their scope, and typically bounded by an organization unit's accountabilities. This led to a vertically organized monolith of function all the way from the UI down to the database calls. This has turned out to be somewhat limiting from the current perspectives of how businesses want to operate; companies are generally larger, more diverse, and re-organize more frequently than was common at the time these models were developed.
 
When applying SOA it makes more sense to bundle services by affinity of capability rather than by "set of tasks" or "org unit accountabilities". In some ways this is similar to the data concept of organizing data by "subject area", rather than application use. For example, if you think about the original implementation of SAP, it was focused on the needs of the Finance Department with "transaction extensions" for other organization units. Some failings of this model were that SAP was an "intrusive burden" to org units other than Finance, and it couldn't support decentralized business models (just any of the decentralized companies that tried to implement it!). Today SAP is re-focusing and exposing it's core services to be consumed by other applications.
 
But what if the architects for SAP had applied SOA from the get-go? The actual architecture would have been defined as several aggregations of financial capabilities (like accounts, money movements, and so on) with appropriate service contracts. It would have also included a collection of capability that would be needed by the finance functions of a typical organization, again with appropriate service contracts. It would have have included some UI capabilities (Web Parts if they were really on the ball) that could consume these services (and indeed other services from different providers) and have the "appearance" of a traditional "application". However, as architects we would recognize that what the user thinks is the "application" is really just a thin facade to the orchestrations of functions they need. An important additional capability is to easily orchestrate other services that are not part of SAP (for example, a service with AMEX to get your credit card statements that can augment expense reports).
 
So the idea of SOA is to design in this set of patterns and paradigms from the initiation of the concept. Thoughts? Feedback? Pizza?