*Editor’s Note: For the first part of Motti Vaknin’s special ebizQ series on SOA governance, please visit, http://www.ebizq.net/hot_topics/soa/features/5731.html
Even the simplest engineering task can highlight the substantial complexity involved in developing to an SOA.
Here is an example: An independent engineer is trying to develop and expose a Web Service out of a specific CRM legacy application in order to integrate it with the company portal. The engineer will typically use a development toolset that was designed to help that engineer develop a service implementation quickly and simply.
The engineer will generate a new set of XML artifacts that this engineer has never created before like XML Schema, WSDL, SOAP messages, UDDI publications, and other related WS-* artifacts. In exposing this service to the enterprise and creating these artifacts, the engineer will have to take into account many additional parameters like: business requirements, design patterns, metadata and semantics used to define the service, interoperability and usability issues - all standards that must be applied to integrate with the larger enterprise framework. There are additional requirements like versioning, deployment issues, quality of service, service level agreements, and of-course security.
What happens in most (if not all) the cases, faced with these layers of technical, architectural, and business requirements, and due to pressing deadlines and lack of tools and expertise, the engineers and project teams will always revert to implementing only the projects business requirements and will neglect all the other elements that are so critical for the creation of enterprise quality services.

Figure 4 - Developing to SOA is a New Paradigm
Challenged with these new realities, companies are ending up with poor point-to-point XML and Web Services-based integration solutions that do not support reusability or scalability beyond the scope of their original design. As business evolves and new business requirements are defined, the inability to reuse existing assets will create a ripple-effect of cost and complexity. As a Fortune 500 executive recently stated during a roundtable discussion at the SOA Forum: “We already have legacy Web Services.”*1
Companies today are unable to control and govern the Services that their developers, contractors, and vendors are developing, deploying, and operating in their environment.

Figure 5 - Ungoverned SOA leads to new silos
-1-