Michael Stamback's Blog

Product: AquaLogic Service Registry 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. 

SOA Governance: When, Where, and How

SOA Governance is a complicated topic.  There are so many things associated with SOA Governance it can make your head spin.  There are technology elements, like registries/repositories, policy management, policy enforcement agents, security providers, service virtualization, and what seems like an endless list of other technologies, but there are also non-technical elements, like organizational structure, incentive models, and governance processes.  So this begs the question - with so many elements to SOA Governance, when, where, and how do I start?

 I'm in product marketing, and as such, you should expect an answer about which technology you should use, and whichever product I cover, you should assume I'm going to tell you it's that product.  After all, that's common of product people right?  Well, I'm going to take my product hat off for a moment and take an objective approach. 

There are two things to note up front.  First is that SOA Governance requires a mix of people, process, and technology.  Focus on one and not the others and you will get a partial solution to governance.  The second is that there is no wrong answer to when, where, and how to apply governance.

Let's start with when.  The simple answer is that it is never too late or too early to start applying governance.  However, the opportunity cost related to starting governance later rather then earlier is much higher.  Theoretically, you should start applying governance once you have a single service.  Unfortunately, that's not the typical case.  Many wait until it becomes a problem and their SOA introduces more chaos instead of solving their business problem.  The cost for having to course correct and apply governance once it's a problem is much higher then if you start earlier in your SOA initiative.  Bottom line, you shouldn't wait until you are experiencing pain to start enforcing governance in your organization.  If you had pain in your leg, would you wait until you couldn't walk before you went to the doctor? 

Next is the where.  SOA Governance should pervade throughout the organization, across IT and business boundaries.  Many mistakenly associate SOA Governance with governing services.  This is only partially true.  You need to govern the services that are built, both functional and business services, but you should also be applying governance across your BPM processes, as BPM processes tend to be consumers of SOA artifacts in addition to possibly being exposed as services themselves.   Finally, governance at the individual asset level can be overwhelming when trying to manage an entire project, so governance should be applied at the project level as well. 

Finally, there's the how.  This discussion could take a while considering how many aspects there are to consider, so I'm going to keep it high level at some entry points.  There are many ways you can get your SOA governance initiative started.  It really boils down to where your pain is and what you're trying to accomplish.  Here are some examples:

• You have been constructing and deploying services but now don't have visibility into what services exist, where they are being used, or what other assets they are connected to.  In this case you might want to start with a SOA Management solution to discover the services in your service network and get a snapshot of your ecosystem. 
• You're ahead of the curve and want to apply governance early on.  To do so, you want control over ensuring the right services are being produced in the right manner.  Here you might start with a registry/repository with policy management capabilities to catalog processes and services as they are developed and ensure compliance with rules on how they are developed.  
• Maybe you're an organization that is security and regulatory control conscience.  In this case, you might start by looking at a security solution.  A policy-based security solution that allows you to manage and govern your security outside the application code gives you the most flexibility to easily adapt to new security demands.   
• Next there is the notion of service virtualization.  Many organizations start here by implementing a service bus without realizing they are applying governance, although it's loosely applied.  Service virtualization is a common and efficient way to enforce change management, version control, and runtime policy compliance by breaking brittle point-to-point connections to backend processes and services and hiding the complexity associated with communication with those processes and services. 

The above are just a sample of how you can get started, but they are pretty technology oriented.  Earlier I had mentioned governance was more then just technology.  Common throughout all of the options above is the need for organizational structure and processes.  This is actually where you should start.  Without the right org structure and processes defined, the technology aspects have limited value without knowing the structure to which they apply.  In other words, the technology elements should be used as a means to automate the processes defined, and the organizational structure should be used to assign accountability and responsibility within the processes and other elements, such as vision, architectural direction, etc.

The above is obviously not an exhaustive list of everything that has to do with SOA Governance, as SOA Governance is a large and complex topic.  The bottom line is that you need to identify where your biggest pain or need is and start there.  Your SOA Governance framework can then evolve as your SOA evolves. 

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.