In recent years, there has been a steady migration away from non-standard legacy interfaces, toward Web services. By offering a standards-based interoperability platform, Web services allow enterprises to more efficiently integrate applications and improve the accessibility of business processes for customers, partners, and internal users. Essential for both business-to-business commerce and internal business applications, Web services are increasingly used by organizations that want to improve responsiveness and efficiency.

Yet the exciting new capabilities offered by Web services arrive with some risk. An unplanned, broad adoption of Web services opens companies to uncertainty and even potential anarchy. How can enterprise architects make sure that the people who need the services will find them? Is there a way to ensure that developers are not wasting time developing services that already exist? How can management ensure that services comply with technology, business policies, and application standards? Finally, how can IT and business leaders control how the services interoperate?

Companies need the architectural benefits of SOA. An SOA can coherently map business processes with enterprise applications, inspire integration and reuse of applications, and foster effective governance of SOA services — often at dramatically lower costs and with less resources.

Still, enterprise architects implementing an SOA often realize a key ingredient is missing: business service visibility and, therefore, control. If users cannot easily find these business services, the promise of SOA is largely lost. If developers cannot readily find and reuse services, they essentially don’t exist.

The solution is a platform-neutral, standards-based method for publishing and discovering services. Using a standards-based Business Service Registry, Web services can be published as SOA business services ready for mapping and interoperability. By publishing services information, including capabilities and policy support, the Registry becomes the overall system of record for the entire SOA. Discussions with numerous SOA users illuminated several problems with using a non-registry based SOA. Following are seven of the most commonly reported dangers of not having a Business Service Registry.

Danger #1: Ineffective Applications Caused by Misalignment with Processes

A Business Service Registry provides easy-to-use tools with which business analysts can survey an enterprise's business services portfolio and determine which are available to automate processes and address pressing business needs. Whether it’s tracking down sales leads or conforming to e-government compliance, a Registry allows analysts to measure the impact of changes in business requirements on processes and services.