Many stand-alone SOA management systems available today maintain, at best, a shallow form of integration with enterprise management systems through the use of simple SNMP traps, but this is not adequate. It allows for things like simple text information to be conveyed through the enterprise management system to its central operations console. However, such limited information is usually insufficient for the sophisticated automated event correlation needed to determine the true root cause of high-level service disruption or delay.

Today's complex distributed systems generate a vast cascade of interrelated events that must be analyzed and understood by enterprise management systems, and SOA will add to this. SOA management systems that are not deeply integrated with existing enterprise management systems cannot easily determine the underlying cause of a problem. While SOA management solutions from enterprise management vendors are, by their nature, deeply and appropriately integrated and aligned with the rest of that vendor's enterprise management solution as a matter of course, other SOA management vendors will have to consider the huge development overhead of attempting to integrate with each of the unique interfaces of the leading enterprise management vendors, while at the same time responding to increasing pressure to differentiate themselves in more and more esoteric ways.

SOA management solutions from enterprise management vendors also benefit from natural alignment with the semantics, message terminology, and user interface provided by the enterprise management system - since a business's operations staff is already familiar with the enterprise management and security system. If an enterprise decides to deploy a second system for SOA that is not fully aligned with the existing enterprise system, this forces the operations staff to deal with error messages, terminology, and a user interface design that is different from the familiar enterprise systems that they are already using. In this case, it is important to factor in the added complexity, overhead, and cost of training operations staff in the particulars of two different management systems: one for the SOA and one for the rest of the business.

Governance
Governance is an increasingly popular term and with good reason. Recently, some management vendors have tried to leverage the upswing in interest in governance by coining terms such as "runtime governance" for their management products, but to me those terms merely confuse the issue. Management and security, as we have discussed, are essential cornerstones of the SOA. The runtime health, safety, performance, and reliability of your SOA are most significantly a function of effective SOA management and security, not governance.

See Figure 1

This invites the question of what exactly is governance. A very simple but practical explanation is that governance is the management of development artifacts (some people would use the word assets instead), such as Java code, HTML, XML, COBOL copybooks, deployment descriptors, WSDL, etc. Governance is primarily about tracking and controlling development artifacts through their life cycles; from creation to archiving (it is usually not a good idea to destroy an artifact). Good governance is an important part of creating an effective SOA. While good governance is also dependent upon development discipline, architecture, and best practices at a number of levels, governance products can also add significant value and an important level of enforcement to that development discipline, and to the quality and usefulness of an SOA, especially as it evolves and responds to changing business conditions.

Good governance products manage the entire process, including human aspects such as human approvals for moving something from one stage (like test) into another stage (like production), checking that only the right persons can use or make an artifact public, and more. Governance products usually can make sure that artifacts that are deployed or created at certain stages of development for particular projects conform to company standards for that type of artifact and that project, and can track the location of those artifacts, which may reside in change configuration systems, databases, and other repositories. Some governance systems also provide their own repository, thus allowing certain or all artifacts to be centrally stored. The ability to interoperate with other repositories, registries, and other tools is also important.

In an SOA, registries based on UDDI are already starting to be used to facilitate discovery of services and obtain other relatively static information about those services, such as security policy requirements. In the future, I believe that more distributed, peer-to-peer mechanisms based on specifications such as WS-MetadataExchange will afford services the option of sharing information about themselves directly with their consumers at runtime without the imposition of a central intermediary. Depending upon business and architectural needs, many implementations of SOA may eventually use both approaches.

UDDI registries already contain pointers to important artifacts related to SOA such as WSDL documents, and can also point to many other types of artifacts. Because of this, many UDDI registry vendors have recently begun to market themselves as a governance solution. Their advantages include the fact that they are Web services standards-based and are already useful for discovery in an SOA. Of course, as they start to extend their core UDDI capabilities with custom governance enhancements such as approval screens and life-cycle processes, repository capabilities to store artifacts centrally, integrate with multiple development environments, and so on, they transform themselves from a pure, simple, standards-based discovery tool to a more complex Swiss Army knife of both standards-based and proprietary capabilities.

More traditional and established IT governance vendors are coming from the opposite direction. They often offer better integration with development tools, more sophisticated process mechanisms to manage the artifacts, and superior support for legacy artifacts such as mainframe systems, diverse languages, etc. However, they are newer to the world of Web services and SOA. They typically do not offer UDDI capabilities themselves and may not support or may not be as up-to-date on some Web services standards. Rather, they often choose to interoperate with UDDI repositories much as they do with other mechanisms that are external to their systems, but the focus is usually on governance and the development organization itself, rather than on the SOA and standards.