There were a couple of good questions on my last blog entry about policy:
Can you compare and contrast policy with standards
How is governance tied to policy
How do you enforce policy
I'll try and answer them here...
When talking about standards, there are really two different types: industry standards and corporate standards. As far as corporate standards go (e.g. what platforms are allowed to be used, etc.), this is pretty closely aligned with policy. That is, the company has a policy that only the standard platforms will be used.
As for industry standards, the good thing about standards is that there are so many to choose from... when faced with conflicting standards, an organization should decide on the ones that are appropriate and make those the standards (again, the policy is that only those standards should be used).
SOA governance is often associated with schema policies, but in reality, SOA governance applies to all types of policies. Essentially governance is how you make sure policies are being followed.
Depending on the type of policy, there are different approaches to ensuring the policies are being enforced. For schema policies (which are really more "design time" than "runtime" policies) you can introduce a "checkpoint" into your development process that can't be avoided easily (e.g. at service rollout, when central IT gets involved in bringing online the production systems). As a part of this checkpoint, you validate that all schema policies are being followed. Of course, a checkpoint is a point-of-last-resort. It's wasteful to catch too many services at these checkpoints. So, it's best to use platforms and tools which make following the policies the path of least resistence (for example, by automatically filtering out options that are not allowed by corporate policies).
For communication and behavior policies, while these could certainly be hand coded into Web services and validated at the checkpoint, this is typically inefficient. It's often better to use infrastructure which will automatically enforce these policies for services. This not only reduces the development burden, but improves overall efficiency by allowing communication and behavior policies to be changed centrally, without having to version the services themselves.