Service Oriented Architecture--Is It Alive or Dead? [Title Updated]

Following a sequence of links on service-oriented architecture, came upon an interesting discussion of the insurance industry vis a vis IT and this (in the context of the problems of developing "services" which apply to multiple situations):

Practices like this prevent any form of "standard insured" from being developed in the insurance industry. No insurance businessman will support this because there are nuances and implications built into the idea of an "insured" that are different for each product type. To see this, what happens when a covered person has no brain activity but is on a life support system; are they dead and does a life insurance policy have to pay, or are they alive and the medical insurance policy has to pay. In reality, life insurance policies assume you're dead when a death certificate is written, because doctors will only sign a document for people they pronounce as "dead". All of the language in a life insurance policy surrounding the word "insured" assumes this to be true. But some medical insurance policies assume you're dead when your organs can be harvested for transplantation, even without a death certificate. And all of the language surrounding their term "insured" works to limit the medical policy's liability within this context. So such a person is neither alive nor dead, and it will take a court case to decide which policy is liable. A software service could only deny all payment given these rules.

These kinds of "business context" assumptions are ultimately coded into the business rules of the systems and they make it very difficult to identify the differences between systems and the data resources the systems manage. As a result, it is difficult to decide what a "service" is and what it should do. 

Software developers need to understand that a service can only exist within an operating context; business people need to understand the an address is an address every place it appears. And while software systems might be able to standardize the data of an "insured", and they may be able to standardized the relationship between a policy and its "insured", the business context will always limit how the data is used, and the service will always have to include this business context. This means that every service will either provide just data, or the service will be specific to a business context, but unless the business itself is defined to use standard contexts, the services can never be shared between contexts.

It's this sort of thing which also causes problems in merging organizations, in handling silos, etc.