I continue to be surprised by the number of enterprise architects I talk to that think that the way to implement design-time governance is to have a checkpoint, before a service goes into production, to validate the service meets the requirements and rules.
The key problem with this approach is that it's already too late. By the time a service is ready to be deployed, it's well past "design-time" (technically, it's actually "deployment time"). So, one of two things happen: The service meets the requirements so it can go ahead, or it doesn't. If it doesn't, it's back to the drawing board for a redesign (or the project gets deployed anyways because it's more important than following the rules set by the enterprise architect).
While it's definitely valuable to have deployment-time validation "checkpoint," you shouldn't confuse this with design-time. Real design-time SOA governance happens when the service is being designed (surprise!), so that you avoid problems before they are baked in and expensive to change.
If your design-time governance approach consists only of checkpoints at deployment-time, you should really call it what it is: "redesign-time governance".