SOA Governance@work

Part of the SOA Governance @ Work Series

To describe security as an important part of SOA Governance is bit like describing water as an important part of the lives of fish, which is to say, it's an obvious point. Like everything else in SOA governance, security is a multifaceted issue. But SOA security boils down to knowing the answer to one simple question: Who is using your stuff? 

Each service deployed within your SOA represents a significant investment, and significant potential ROI. One of the fundamental goals of SOA governance, of course, is to insure that the use of each service generates the expected return. Key to realizing that return is controlling who has access to those services, and controlling how those who have access actually use those services. In order to do that you want security measures that are more effective than the guy in the photo.

The control of access to services relates directly to the issue of the balance between governance and agility, an issue discussed in this blog and elsewhere.  Agility, of course, is one of the primary objectives of SOA. The ability to mix and match services in response to business requirements is one of SOA's defining characteristics.  But that ability, the freedom to access services and combine them in innovative ways, doesn't require throwing open the doors to the enterprise service portfolio.

In SOA -- as in anything else -- trust is a two-way street. While those who might use a particular service in a development project need assurance that the service will perform as expected, those responsible for creating and maintaining that service in the first place need assurance that the service will be used as intended. Overarching those concerns is the fundamental issue of architectural integrity. The appropriate security measures will insure that who does what with what within the SOA is in direct alignment with architectural guidelines and standards.

By assigning the appropriate privileges to the appropriate users, teams, or roles, administrators can restrict access to services to the right people, providing the assurance that those services will be used in the intended manner, and in line with business objectives.

Access, however, isn't necessarily a binary yes/no issue. Since visibility is such a key issue in maintaining a healthy SOA, security measures must take into account the value of allowing restricted access to certain assets by certain users.

For instance, inadvertent redundant development can be eliminated by restricting a development team to access to a limited spectrum of metadata about a particular service, as opposed to the service itself. Access to that information tells the team that the functionality provided by the service in question is already available, so there's no need to reinvent the wheel. That kind of security can go a long way toward preventing service sprawl and keeping your SOA as limber and agile as a yoga instructor.

For SOA security, the better analogy, perhaps, is the big, intimidating security guy who controls the velvet rope outside a really hip, popular nightclub. His job is to let only the right people into the club. Your SOA security measures must be capable of sorting out who gets to dance with the valuable stuff in your service portfolio.

Previous posts in the SOA Governance@Work series:

• SOA Governance is a matter of balance
• Survey Says... SOA Governance is Happening
• The SOA Governance Prescription
• Wielding the Carrot and the Stick
• Peeling the Policy Onion
• Policies: The Nuts and Bolts of SOA Governance
• SOA Visibility: Keeping the Wheels On

Part of the SOA Governance @ Work series

Writing in Wanted: new term for SOA ‘governance’, Joe McKendrick continues a blogosphere conversation about labeling SOA governance, and about the balance between SOA governance and agility. (See the posts by  David Linthicum, Michael Meehan, Dan Foody, and Todd Biske.) Joe says:

I’ve even heard of cases where SOA governance itself has tended to go too far, strangling the innovation that service orientation and loose coupling is supposed to promote. One vendor executive I recently spoke with said he saw customers pull back on governance when they realized that the restrictiveness stifled the ability to effectively deploy and reuse services.

This warrants another visit to the Todd Biske post I referenced in an earlier post.  Here's Todd's take: 

If your goal is to be a very innovative company, but your command and control structures prevent you from doing so in a timely fashion, that’s not a problem with governance per se, but with the governance model you’ve chosen.

Todd is dead on, of course: It's all about the model.  SOA governance is the means by which you ensure that the SOA delivers business value. Agility and innovation are certainly part of that value for any business, but the specifics of where and when that innovation actually happens depends on the environment within the organization. 

In designing the appropriate model, it's important to remember that SOA governance has to  cover a lot of territory, but that doesn't necessarily mean that governance has to be applied with equal pressure over the entire service lifecycle. 

For instance, if the objective is to allow unbridled innovation in the reuse of available services in the creation of composite applications, more control may be necessary over the design, development, and delivery of the services to be made available for that purpose. In that model, it's a matter of providing a limited portfolio of high-quality, high-performance services and letting development teams mash-up at will. Provide the kids with a clean, well-lighted sandbox and let 'em go nuts.

If the objective is more tightly controlled service consumption in the creation of composite applications, more SOA governance pressure may be required at that point in the life cycle. In this situation, the portfolio of available services may be much larger than in the previous scenario (and maybe even less consistent in terms of quality and performance), but the actual selection of the services to be used in specific app development projects will be made at the architectural level, and not left to the app development teams.  This follows the prescriptive model discussed in a previous post.

The right SOA governance model for any organization depends entirely on the specific goals and the specific environment: available tools; skill levels; general level of SOA education, maturity, and commitment; and a plethora of other factors affecting the people, processes, and technologies involved in the SOA.

It's important to remember that the dynamic nature and interplay of these various factors makes the SOA a living thing. For that reason, governance must be equally organic. In the end, the right governance model is a matter of sustained balance rather than static, either/or decisions about where to apply the most stringent policies. Maintaining balanced SOA governance is a dynamic process that requires holistic visibility and understanding of what's going on in the SOA. That information will a provide the basis for decisions about how to evolve the SOA governance model in order to maintain alignment with goals that are very likely to be moving targets.

Other posts in the SOA Governance@Work series:

• Security: SOA's Velvet Rope
• SOA Governance is a matter of balance
• Survey Says... SOA Governance is Happening
• The SOA Governance Prescription
• Wielding the Carrot and the Stick
• Peeling the Policy Onion
• Policies: The Nuts and Bolts of SOA Governance
• SOA Visibility: Keeping the Wheels On