In this section I want to mention some additional aspects regarding the introduction of SOA.
SOA policies are the rules and guidelines necessary to establish and live SOA. These policies define what's right from both a technical and an organizational point of view.
As written earlier, policies should evolve over time, because they are only useful if they are proven to be appropriate. Nobody can see ahead of time all the different requirements, contextual details, and flavors of a SOA strategy.
Note that there are two kinds of policies: those that are mandatory and those that are goals. Or, as Anne Thomas Manes describes it in [Manes07], a policy might be a "law" or a "guideline":
A law is something that you have to
follow. Laws should include all requirements that are key for the
SOA objectives. For example, you might require that each service
provider has to use a specific protocol (such as the Web Services
protocol with the binding
document/literal wrapped). This should
be a law in case all infrastructure components are implemented
according to this constraint.
A guideline is something that you recommend, but that it might be possible not to follow. For example, a guideline might be that a service should be stateless or idempotent.
Discussing whether policies are mandatory or just recommended usually leads to several clarifications about processes and tools. Laws lead to simpler solutions, because you can skip other possibilities. On the other hand, ...