Build, protect and deploy apps across any platform and mobile device
Deliver Awesome UI with the most complete toolboxes for .NET, Web and Mobile development
Automate UI, load and performance testing for web, desktop and mobile
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate decision processes with a no-code business rules engine
Build mobile apps for iOS, Android and Windows Phone
Deploy automated machine learning to accurately predict machine failures with technology optimized for Industrial IoT.
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premises data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Trust me, I'd like to say "no, SOA governance is the key to unlocking the business agility of SOA." Problem is, it's not true -- at least the way I see most people approaching it...
One of the core "best practices" in SOA governance is to define policies that require all services to conform to a set of chosen standards. Let's say SOAP 1.1, WSDL 1.0, WS-Policy 1.5, etc. -- in addition to whatever industry or organization specific common schemas are appropriate. I often hear this said as, "I need to understand which of the standards are stable enough for me to adopt now".
Essentially, many IT organizations today are saying "by locking down the IT standards, the business becomes more agile" - and many vendors selling SOA products are encouraging this under the umbrella of "good governance". And, the business will be more agile... if the standards don't change.
The problem is, all of these things will change and evolve. In 5 years, will SOAP 1.1, WSDL 1.0, WS-Policy 1.5 really be the right standards to have latched on to? Don't kid yourself, what's stable now is in no way a predictor of which standards will matter in 5 years. New and better standards will come along, opinions will change, key vendors will change their direction, etc. I'm not saying that standards aren't important, just that the standards of today will not be the standards of tomorrow.
What this means is that IT needs to change it's thinking. Instead of saying "What set of standards should I lock myself into", IT should be saying "How can I ensure that I can easily change my choice of standards as time goes by." The funny thing about this is that, once you can change your standards easily, the choice of standards becomes much less important... because you've gained agility.
SOA What? Agility isn't only for the business. You need to think of gaining agility at every level of your SOA. Your business can't be agile unless every aspect of your IT infrastructure is also agile.
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 © 2017 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.