Build, protect and deploy apps across any platform and mobile device
Leverage a complete UI toolbox for web, mobile and desktop 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
Build mobile apps for iOS, Android and Windows Phone
Optimize data integration with high-performance connectivity
Connect to any cloud or on-premise data source using a standard interface
Build engaging multi-channel web and digital experiences with intuitive web content management
Automate decision processes with a no-code business rules engine
Answer: Hopefully better than the NYC Department of Traffic.
Before you laugh at them, think very carefully about your model of SOA Governance.
Gartner analyst Frank Kenny uses a slide that shows SOA Governance containing four key governable elements:
I agree with Frank's model and think that it's really important to be able to fully decouple policies from the SOA infrastructure so that they can be properly governed. Proper governance enables policies to have have their own lifecycle, and even to be owned by a team separate from the service owner.
SOA What? Why is this important? Well, governance drives policies. Governance doesn't dictate "on your next release, you must..." Rather, governance demands compliance by a certain date or in a certain time period. These policies therefore have a life of their own - a life that needs to be managed. Also, often the "policy expertise" (think security or corporate governance) is often not in the development team. In fact, distributing "policy expertise" to the development often leads to problems of interpretation... developers are left to do their best interpreting policies as they implement their services. Again, security is a good example. Not all developers are security experts. And, it's easier (and cheaper!) to have security trained staff write a good policy, than train every developer on security policy interpretation.
Fully decoupling policy has other advantages as well if the product that implements the policy has the right abstractions built in to enable dynamic policy-service coupling. For example, a policy can be written for all "external customers" -- and automatically inherited by any new external customer as they are discovered (configuration implies a prior knowledge of the customer... don't get me started on how little we actually know about what our systems are really doing). Another great example, is Actional's ability to evaluate policy once, closest to the customer, as a way of: (1) optimizing policy calculation and overhead, and (2) driving policy to relate directly to meaningful customer/business experience, rather than "arbitrary" technical statistics like CPU load or response time.
Now that you've had time to think about the policies that govern your mission critical applications, I bet you can relate a little bit more to those guys at the NYC Department of Traffic. Scary, huh?
View all posts from david bressler 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 or appropriate markings.