Joe McKendrick, ebizQ's SOA in Action Blogger, is a nationally published author and consultant
with deep knowledge and insights regarding trends and developments in
the technology industry. He is a contributing editor to a number of
national and international publications and Websites including
Database Trends & Applications, ZDNet, and Webservices.Org. He also
serves as analyst for Evans Data Corp., and is lead analyst for Evans'
Web services and enterprise development management issues surveys.
SOA in Action Blog
|
« Survey: Governance Makes the Difference in SOA | Main | Are SOA Vendors an Endangered Species? » April 16, 2007Can We, Should We, Automate SOA Governance? Can we, should we, automate SOA policies that are unenforceable by other means? In my previous post, I discussed the results of a new Aberdeen survey -- as well as ebizQ's own survey from last fall -- which demonstrated advantages when automated SOA governance is put into place. In a new post, ebizQ's David Kelly observes that automation is the key to effectively managing complex SOA environments. "Like many other parts of the IT infrastructure and software development lifecycle, the more you can automate your SOA governance, the more effective and efficient it will be. It will be easier to enforce, easier to use and will provide greater payback than a non-automated process." Some governance areas that could be automated include the configuration of new services for security and management, automatic compliance checking to verify whether a new or modified service meets specific compliance requirements, propagation of policies, and automatic detection of dependencies and the relationships among the different services and systems in an SOA environment. However, in a response to David's post, Todd Biske argues that automating governance essentially "is putting the cart before the horse." He notes that the purpose of automating SOA governance is policy enforcement, which is too much of a hardline approach to SOA. "Governance isn’t just about enforcement," Todd says. "Governance is about people, policies, and process. People (the legislators) set policy. Policy is enforced through process. That may be a gross oversimplification, but it’s the way it needs to work." Todd cautions that enforcement often fails "because the people, the policies, or both are not recognized." Even if you automate enforcement, he adds, "if the policies and the authority of the people setting the policies aren’t recognized, your governance efforts are less likely to be successful." I've heard it said that an uber-governance approach will scare away the very people you need to sign onto an SOA program. In fact, too much governance results in end-user groups performing end-runs and workarounds that bypass the "official" infrastructure -- and severe underuse of the infrastructure. And that means money down the drain. Enforcement -- whether its a city government or an enterprise architecture board -- is a cultural issue, Todd explains. "Tools can make non-compliance more painful, but they can’t change the culture. If you’re having problems with your governance, I’d look at your people and policies first. If you’ve got recognition on the authorities and the policies, now you can look into minimizing the cost of your enforcement through tooling. It is certainly likely that automated tools will be less costly in the long run than having to schedule two hour meetings with your key legislators for every service review." Posted by joemckendrick in SOA | Digg This | Add to del.icio.us Trackback Pings TrackBack URL for this entry:
|
