SOA Architecture, Governance, and Industry Standards in the Enterprise

Paul Lipton

Subscribe to Paul Lipton: eMailAlertsEmail Alerts
Get Paul Lipton: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal, SOA & WOA Magazine, ERP Journal on Ulitzer, VITO Report

Article

The Well-Spoken SOA - How Well Is Your SOA Running?

Understanding the elements of an SOA in the context of management, security, governance, and the power of words

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.

More Stories By Paul Lipton

Paul Lipton is VP of Industry Standards and Open Source at CA Technologies. He coordinates CA Technologies’ strategy and participation in those areas while also functioning as part of CA Labs. He is co-chair of the OASIS TOSCA Technical Committee, and also serves on the Board of Directors of the open source Eclipse Foundation, as well as both the Object Management Group and the Distributed Management Task Force in addition to other significant technical and leadership roles in many leading industry organizations such as the OASIS, W3C and INCITS.

Lipton is also an approved US delegate to the international standards organization ISO, as a member of the subcommittee focused on international cloud standards. He is a founding member of the CA Council for Technical Excellence where he leads a team focused on emerging technologies, a Java Champion, and Microsoft MVP.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Paul Lipton 04/18/06 02:32:28 PM EDT

No, UDDI is not fated for the dustbin of history, but neither is it the only way to share or distribute policy information. The notion that UDDI must the the center of the universe and holder of all policy is equally absurd. It simply won't happen for practical and historical reasons. Policy will be distributed all over the place; in legacy, identity management, and operations management policy repositories, to name a few. Each of these repositories is optimized to support certain types of policy best at runtime (where it counts). We had best learn to live with that and plan for it.

SOA Web Services Journal 09/01/05 10:23:38 AM EDT

The Well-Spoken SOA Web Services - How Well Is Your SOA Running? The American comedian and actor Steven Wright once said, 'It doesn't make a difference what temperature a room is, it's always room temperature.' Words are wonderful that way. They can give you a little blast of pleasure when used cleverly, but like everything else they are subject to fashion. For example, I was speaking at a technical conference recently when I overheard a person whom I know, who is well-respected in this field, say something along these lines: 'You have to know how well your SOA is running. Knowing the overall health and responsiveness of your SOA is very important. You've got to get a handle on your governance.' The goal was laudable, but the wording was off target.