X
Business

Is SOA governance also its own silo?

The purpose of SOA governance is to cut across all the silos and get all the business on the same page, using the same services.However, my chum Tony Baer over at Ovum is seeing evidence that organizations may be spawning a brand-new silo in the process -- a "governance silo" that handles SOA as a special case for the software development organization.
Written by Joe McKendrick, Contributing Writer

The purpose of SOA governance is to cut across all the silos and get all the business on the same page, using the same services.

However, my chum Tony Baer over at Ovum is seeing evidence that organizations may be spawning a brand-new silo in the process -- a "governance silo" that handles SOA as a special case for the software development organization. That's because SOA requires special skills for working with common programming languages and architectural skills.

As Tony put it in his new report issued from Ovum:

"In the long run, relegating SOA to the software development organization as a special case creates the very duplication that SOA itself was supposed to eliminate."

This example of one of the unintended consequences of SOA reminds me of an observation made by Dan Woods over at Forbes last year, that the rise of SOA may mean IT departments will have more burdens to shoulder than they did by simply relying mainly on packaged applications. Then there's the other unintended consequence put forth by vendors pushing to offer SOA all in a single suite, which runs contrary to the essence of service-oriented architecture.

There are various issues at work with SOA governance silos, Tony said in the Ovum report. First, there's a perception that SOA-based technology is "reserved for elite practitioners." Of course, relegating SOA to an elite group "compounds the waste and duplication that SOAs were supposed to avoid."

Tony recommends the "cross-fertilization" of SOA practices with standard application sets. "Examples include the use of architecture-driven development for services to support reuse or repurposing," as well as the explicit awareness of runtime and use of service contracts for conventional software development, which would help make it "more accountable to the business."

The key is to start applying the principles and best practices that have grown up in the SOA space to the rest of the software development space. While standard application developers may not be up to speed on some aspects of SOA, such as Web services protocols, "governance should not be a foriegn concept to software developers, as a properly managed application lifecycle is about measuring the effectiveness of different stages of the lifecycle..."

Editorial standards