Michael Stamback's Blog

Technology: Service-oriented Architecture Archives

5 Tips for Buying SOA Governance

SOA Governance is hot these days. It’s widely believed that governance is required if you want to succeed with SOA, which is a correct assumption. It’s ironic though that agility and simplicity comes at the cost of complexity. That almost seems contradictory- the efficiency that SOA offers breeds complexity – so what are you to do? Governance is the answer. Manage the complexity in a controlled manner and the benefits SOA offers are much more obtainable.

However, customers, analysts, vendors, bloggers…everyone seems to be talking about governance, so how do you get through the FUD to make an accurate buying decision on supporting your governance needs. Here are 5 tips for buying governance.

Tip #1: You can’t buy governance!

That’s right, you can’t buy governance. Governance is a process, not something you buy. The technology that vendors are offering out there should be used to automate the governance process, but technology can’t solve the problem on its own. In order for governance technology to be affective, you need to first establish what it is you want to govern and how you are going to govern it. The technology should then be applied to automate that process. That being said, the rest of the tips will focus on identifying the right technology.

Tip #2: Look for a vendor that can explain how their technology is applied

This one is key. You need to look for a vendor that not only has governance technology to offer but can also walk you through how their technology is applied to the governance process. Don’t go for a vendor that only explains what their technology does. For example, many vendors will tell you that you need a registry/repository for visibility. While this is true, you also need to understand where in the lifecycle it’s important to have that visibility and how it’s achieved. Is it a manual process, which reduces the possibility of adoption? Or is there some way to automate the collection of artifacts at different triggering points in the lifecycle? Remember, you’re trying to automate the process as seamlessly as possible, not create more work.

Tip #3: Beware of the kitchen sink!

Trying to establish control over your SOA is hard enough without making it more complex by adding a truckload of more software. Don’t look at solutions that make you feel like you need to buy the whole store to get the one comfy chair you really need. Doing so only has you buying technology for technology sake without the understanding of how to apply it and when. This ultimately leads to failure for the governance program because it’s too complicated. It’s rare you’ll need a whole giant stack of products to address governance, at least in the beginning. The KISS principle definitely applies here. Don’t try to over govern early on.

Tip #4: Start small and expand

When looking at governance, focus on what is causing you immediate pain or frustration and then expand from there. Make sure you invest in the right technology that can not only solve your tactical pain, but can also help you strategically down the road when looking at the bigger picture. For example, excel spreadsheets might work fine in the near term for cataloging assets, but what about long term? How well will it evolve as you evolve? Start in the area that you see the most value to your governance program and then expand as your needs expand or as you start to realize the value of adding additional components.

Tip #5: Look for an integrated solution

Having an integrated solution just makes the governance process that much easier. You want to eliminate as many manual points as possible, as governance should be something under the covers that gets applied to the environment. This will enable higher rates of adoption for your governance program as it appears less disruptive to those that are being governed. Look for vendors that provide a solution whose technology components are integrated to support the lifecycle from end to end, regardless of the number of products they throw at you.

Keep these 5 tips in mind when evaluating purchasing decisions surrounding governance. Remember that governance is more people and process then it is technology, so make sure the technology you choose supports your culture and process the best.

The Choice: Innovation or Extinction

What is innovation? How do you achieve it? Does it come in a box? Today's market is one of increasing competition, with the spoils going to those who stay ahead of the innovation curve.

What does it take to really be an innovative leader in your market space?  All one needs to do is take a look at history to see that organizations that bring business and IT together to address the core business model tend to thrive, while those that do not open the door to competitors and fade into extinction. 

What do FedEx, Amazon.com, Nucor, and Southwest Airlines have in common? Each of these companies is widely recognized within the industry as having taken steps to combine business with IT, and to leverage that combination to disrupt their respective market spaces with innovative ideas.

FedEx developed technology that not only gets your package to its destination faster, but also tells you exactly where that package is along the way, reducing the potential for loss. The company is so successful that “FedEx” is often used as a verb to describe package delivery in general, regardless of the carrier.

Amazon.com did something similar, developing a new storefront that not only robbed traditional brick-and-mortar book stores of market share, but sparked a revolution in how companies connect with consumers.

Southwest Airlines, one of the few airline companies to avoid bankruptcy, broke ahead in a crowded industry by combining business and IT to create an easy-to-use online reservation system and innovative active email campaigns to promote cheaper flights. 

Steel producer Nucor utilizes an innovative combination of business and IT to keep the company profitable and growing – in a declining industry with multiple casualties.   

Innovation, however, is more than riding a wave. Today, innovation requires the agility to constantly redefine and refine the business, finding new ways to do business that keep the competition in catch-up mode. To accomplish this, you need a technological foundation that supports sustained innovation. BEA AquaLogic platform can provide that foundation.

BEA recently completed the next evolutionary phase of the AquaLogic platform.  When originally launched in 2005, BEA AquaLogic was positioned as service infrastructure for SOA.  Over time, and through the acquisition of Plumtree, Fuego, and Flashline, the AquaLogic platform evolved to address SOA and beyond.

Today, BEA AquaLogic delivers the SOA, BPM, and Enterprise Social Computing capabilities that allow organizations to achieve and sustain true innovation through the creation of next-generation dynamic business applications.

Applications have continuously evolved since the mainframe days to provide more and more value to the business, at increasingly rapid pace. Gone are the days of monolithic applications that are simply packaged and deployed on top of an application server.  SOA brought about a revolution in applications, breaking them into discreet, consumable parts that could be assembled and reassembled to meet new business demands.  On a parallel course with SOA, BPM, social computing, and other trends provide the business with more direct influence over its business systems.  Dynamic business applications are the next generation of applications, the convergence of all these trends.

Dynamic business applications allow business and IT to align in a more efficient, collaborative manner to bring about true agility.  They consist of bite-sized pieces and parts that are assembled in a process that allows easy modification of application behavior through changes to individual parts of the assembly, without having to go through a rigorous IT change control process. 

The prospect of this kind of agility might be a little unnerving to IT, since lack of control over this type of capability can breed chaos, which hinders business agility.  Here too the BEA AquaLogic platform provides a solution. With built-in, comprehensive governance over the entire life cycle of dynamic business applications, BEA AquaLogic can provide IT with the confidence that innovation doesn’t come at the cost of control. By allowing the business to make changes based on business decisions, IT can free itself to focus on more strategic issues. 

Dynamic business applications represent the next wave in business agility.  That agility breeds business innovation, and that innovation allows a business to be a force of change in the marketplace, rather than merely reacting to competitors.  BEA AquaLogic provides the foundation that allows the enterprise to take advantage of dynamic business applications, and to complete and sustain the transformation from spectator to innovator to market disruptor.

Gaining Adoption of SOA Governance

In my last blog, I mentioned that SOA Governance is a complicated beast that requires a mix and match of technology and non-technology elements.  When speaking with some customers recently, a common complaint I heard was that they have implemented a registry or repository but no one uses it or the quality of information is found lacking.  While some are looking to the technology to solve this problem, it's generally a problem of adoption within the organization or resistance to being governed. 

It is a natural tendency for people to resist change and even more so, to resist the notion of 'big brother', which is how many see governance.  In fact, at the Gartner AADI summit last month, Paolo Malinverno had asked the audience how many people felt governance was a necessity within their organization - everyone rose their hand.  His follow-up question was how many people wanted to be governed - 80% of the people put their hand down.  So herein lies the problem.  Governance without enforcement provides no value, but how do you make sure the process established is adopted and followed to ensure compliance?

I will admit that there are certain things that technology, such as registries and repositories, can provide to ease the resistance to adopting governance.  There has to be an easy, automated way to have what you are producing get populated into the central catalog, for example.  However, the best approach I've found to getting governance adopted is to establish an incentive model.

There are multiple approaches to establishing an incentive model, but the carrot and stick approach I've found tends to work the best.  Some use more carrot then stick, while others use just stick.  For example, one customer I've spoken with in the past months used a pure stick approach by making governance activities a part of their developers' performance criteria.  Those that didn't follow the governance model were let go.  That's probably a little extreme in my opinion, but it works for that customer as it's an expected part of the developer's job. 

However, I've found that a mix of carrot and stick works best.  For example, some customers use funding as their carrot.  Development teams or projects that follow the governance model established are ensured of receiving additional funding to continue to evolve their projects.  Those that don't follow the established process risk losing funding.  Another approach is that the architectural review committee will stop deployment of applications and services that have not followed the proper governance activities, such as populating the registry or repository with relevant artifacts and metadata. 

It's through these types of approaches, along with having the right technology in place to make the process less painful, that organizations have had the most success in gaining adoption to SOA governance.  So if you're having trouble getting your organization to populate your registry or repository, try establishing an incentive model that rewards those that follow the process and discourages circumnavigating it. 

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.