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".
View all posts from dan foody on the Progress blog. Connect with us about all things application development and deployment, data integration and digital business.
Copyright © 2018 Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks for appropriate markings.