May 2007 Archives

Michael Stamback's Homepage
Mike Stamback has been with BEA for a number of years working in a variety of technical and product marketing roles on several BEA products in the WebLogic and AquaLogic product families. Today he focuses on product strategy and positioning for WorkSpace 360, SOA Governance, and SOA Security and Management.

The Sad Truth Behind Policy Interoperability

For a little over a year I've been hearing from vendors like Systinet (now HP) and Infravio (now Software AG) about how important policy management is.  Actually, it's always been about how important support for WS-Policy is for successful governance. 

In a recent blog by Neil Macehiter and Neil Ward-Dutton, they talk about a recent demonstration of policy interoperability between the Infravio (Software AG) UDDI registry, the Systinet (HP) registry, and Layer 7.  Some might think that the use of WS-Policy to achieve this is a model for how the standard can be used for policy interoperability.  In fact, the two Neil's state

"WS-Policy does not deal with semantics: it provides a framework within which those semantics can be defined. Support for WS-Policy provides no guarantee that the way one vendor defines a particular policy can be interpreted and enforced effectively by another. That will require agreement on semantics."

I couldn't agree more with this statement.  in fact, I've been saying the same thing for a long time.  A policy, even though it conforms with the WS-Policy standard, is only valuable to the technology that understands the structure of the underlying policy for enforcement.  In other words, an SLA policy defined using WS-Policy may be able to be interpreted by AquaLogic SOA Management, but that same policy most likely will not be understood by Actional or SOA Software. 

The two Neil's summarize it best:

"For these reasons, I doubt that the three participants simply installed the products, created some services and policies and then demonstrated policy enforcement: they first had to agree how the policies would be represented in WS-Policy."

While what was achieved by the three vendors can certainly be deemed a success, the model about which it was done will be one that is hard to follow.  Not all vendors are going to comply with each other's interoperability framework, which is another reason the federated approach to policy management may be desirable, as I blogged about last week.   So until the advent of clear standards, it seems policy interoperability will continue to be difficult in truly heterogeneous environments. 

Centralized Policy Management: Is it a Pipedream?

A topic I get asked about more and more these days is policy management, especially in its relation to SOA Governance, and what BEA's story is around policy management.  A lot of what I read out on the ether seems to oversimplify this topic but does a very convincing job of indicating the need for 'centralized' policy management.  Given the complexity associated with policy management, I wonder if this is a pipedream or something we should all be striving for.

When I hear the term central policy management, I wonder what that really means.  To me, central policy management means having a central location where policies are created, managed, and potentially enforced.  In most cases, this is done through a registry/repository, but is that really the right place to administrate policy?   Maybe for policies that dictate design and implementation rules, but what about those policies that aren't enforced until the time of execution?

First, policy management requires a distributed structure.  There are many types of policies out there, each having its own method for enforcement.  For example, security policies require a much different knowledge base and enforcement then an SLA policy.  Therefore, you might use something like BEA's AquaLogic Enterprise Security product to enforce security access policy across heterogeneous resources but use AquaLogic SOA Management to enforce SLA policies.  

Second, is there really a central master policy manager role.  Or are there different policy management roles within the organization based on the type of policy?  For example, would a security policy and management policy be managed by the same policy administrator?  My experience is that these are separate individuals with distinct skill sets.   

Finally, those individuals that administrate policy tend not to work within the same environment as those that are building composite solutions.  Developers and architects are more apt to live within the registry/repository for governance of the assets being produced.  Policy administrators, at least the ones responsible for runtime policies, tend to be more operations focused, meaning they live and work within an entirely different environment.  That being said, you may have distributed policy stores that in themselves provide central management over specific types of policies, such as security, management, or routing.   

With this in mind, I think the best approach to having a complete policy management story is not necessarily to have one interface for defining all policies. Instead, I think the right approach is to have the ability to centrally manage the policy artifacts for governance, change management, versioning, etc but still allow for distributed policy authoring and enforcement based on policy type, enforcement specialty, etc, especially given the lack of adoption around any standard.  This requires an integrated approach where design-time policies and runtime policies are centrally managed as artifacts, but are authored and enforced in a distributed manner.  This is where BEA provides a strong solution. 

BEA provides solid offerings in policy enforcement with ALES, ALSM, ALSB, etc where policies can be defined and enforced within these products.  The policies created can then be synchronized back to ALER for management of the policy artifact itself for dependency tracking, change management, versioning, etc.  This, in effect, gives you centralized management of policy with distributed enforcement.  This, in my mind, is what we should be striving for as it provides a complete approach to policy management.

April 2008

Search this blog:

Archives

April 2008
March 2008
July 2007
June 2007
May 2007

Recent Entries

The Sad Truth Behind Policy Interoperability

Centralized Policy Management: Is it a Pipedream?