SOA Governance@work

A SOA Governance survey report was recently released by ebizQ providing some insight into the state of the SOA Governance market.  There has been a lot of buzz over the last couple of years around this topic, so it's interesting to see what the industry's take is on SOA Governance: necessary for SOA success or over hyped? 

One interesting tidbit in the report is that a majority of those polled (50%) are still in the early phases of SOA.  This report doesn't have historical year over year trend data, but if we compare that to a similar study done by IDG last year, you can see that we're still at about the same level we were last year.  However, the number of enterprise scale deployments has gone up from 21% to 35%.  There's probably some mean error due to difference in surveys, but it's still a higher maturation rate then we've seen previously.  This supports the assumption that SOA is going mainstream at an increased rate. It'll be interesting to see what results show next year.

The survey goes on to query how important SOA governance is to organizations implementing SOA.  93% of respondents indicated governance was important to their SOA success (49% of those said SOA will fail without it).  Supporting this, 97% of those surveyed are either already down the governance path or are investigating it.  Now I'm a huge advocate of the need for SOA governance, but these numbers even surprised me.  Some say SOA governance is overhyped in the market, but apparently organizations are beginning to feel the need.  If these numbers hold true, we should see a significant uptake in SOA Governance over the next year, which in turn could boost that enterprise scale SOA percentage even higher. 

The survey goes on to address the drivers and challenges driving SOA governance and the importance of change management.  You can read the results for yourself in the report, but they indicate that a majority understand the importance of SOA Governance and the benefits it can derive. While this may seem unexciting, it's rather significant as it shows the maturation in thinking amongst those attempting SOA today.

The last part of the survey I think is pretty interesting shows that less then 15% of those surveyed feel your SOA Governance vendor of choice must provide an integrated SOA platform.  Why this is interesting is that it implies a preference of heterogeneity and best of breed.  Most organizations out there have a mixed bag of platforms and technologies that must be integrated and orchestrated within their SOA. Whatever tools you use for SOA Governance must provide support for heterogeneous assets without having to use vendor x for managing assets by vendor x and vendor y for managing assets by vendor y, with no correlation. 

Based on the results of this survey, this could make for an exciting year in the SOA world.  If these numbers are true, SOA governance will be a large focus for most organizations this year.  Most agree that SOA will fail without SOA governance, so could this be the year that SOA turns the corner?

Could a 'not built here' attitude undermine the benefits that SOA has to offer?  Is the web 2.0 generation creating a new breed of developer that embraces reuse above all else?  These are tough questions that are difficult to answer.  Since the term reuse began rearing its head years ago, there's always been a bit of resistance to reusing code that someone else created.  In fact, lack of reuse is one of the leading causes for failing to realize the benefits SOA has to offer. 

It's not that organizations aren't building enough services, it's that organizations aren't encouraging the creation of enough reusable services. With SOA, we're not just asking developers to reuse code...we're asking them to utilize shared services in their applications that they have no power to modify.  That can be a little scary when you're used to having imminent domain over what you're creating. This fosters the 'not built here' mentality - the death sentence for reuse. 

'Not built here' isn't something unique to SOA.  It's a cultural issue.  I've even seen it prevail within the engineering departments of some of the software vendors I've worked for.  So how do you shift the culture so reuse is not just accepted, but desired?  How do you establish a level of trust that reusing a service will not negatively impact your service level agreement to the business?

To address the cultural aspects of reuse, try attempting to encourage the creation of reusable services.  Hold contests that reward teams for creating the most reusable/reused services or for utilizing the most reusable services within their applications.  This can foster friendly competition amongst your development teams that not only makes it fun and rewarding for developers, but benefits the business by encouraging reuse. 

There still needs to be a measure of trust, however.  To accomplish this, create a more formal provisioning process that provides a structured way for negotiating terms of usage for reusing a service.  Consumers and providers can negotiate contractual obligations, such as security entitlements and service level agreements, that guarantees the consumer a level of service provided and guarantees the provider the service will be utilized correctly.  This accomplishes two things: 1) it establishes a level of trust between the consumer and provider and 2) it creates potential new revenue streams for lines of businesses while reducing operating costs.

Let me address that second point.  When it comes to reuse, there tends to be an issue of burden of cost.  Should division A carry the burden of maintenance costs for a service that is being reused by division B?  Many times this can be what leads to discouragement of reuse.  Creating a charge back model as part of the provisioning process can help to alleviate this concern.

Division B, however, may be hesitant to pay a cross charge for use of a service it does not own.  However, analysis will show that the total cost of ownership is drastically reduced through reuse.  Take a typical cost of implementation and add maintenance costs over time.  Maintenance cost is an ongoing charge that can now be shared, saving you not only the implementation cost, but reducing the overall maintenance budget, freeing up funds to focus on new, value-added investments.  Even though division B is paying for reuse of the service, total cost of ownership is still lower then building it themselves.  While operational costs for division B are reduced, this also creates a potential new revenue stream for division A, especially if externalized in the form of cloud computing...but more on that later. 

So will fostering a culture of reuse magically make SOA successful?  No, not by itself, but it's important to consider, especially given the tangible and intangible benefits it can potentially provide. 

A couple of colleagues of mine and I had a conversation not too long ago  about  whether you could do SOA Governance without technology.  I took the stance that governance was more about the process and supporting culture then the technology.  My colleagues had a somewhat differing opinion that you could not accomplish governance without supporting technology. 

My argument was based on the fact that governance is about affecting behavior in order to establish a sense of control over the environment.  At the macro level, governance is a process that enforces standards, guidelines, and controls with the purpose of ensuring your SOA stays aligned with the business goals and objectives.  It's much like building a house.  There is a specific process that must be followed: obtain permits, lay pipe, create foundation, build frame, add roof, etc.  If you don't follow this process, you end up with a building like the one in the image.   

However, in order to ensure success of your governance efforts, and hence your SOA, a supportive organizational culture must be present.  Everyone involved in the process must be aware of the business goals and objectives.  Building SOA without an understanding of the business is like jumping out of a plane and then trying to learn how to open the parachute.  Both end up with disastrous results.  Fostering the right culture in support of the governance process greatly increases your chance for success. 

As my colleagues pointed out, however, SOA governance requires a bit more, which is where the technology comes in.  One of the goals of SOA is to provide business agility for responding to change faster.  While implementing organizational change and enforcing process can certainly keep SOA aligned with the business, it can sometimes defeat the goal of agility.  This is one spot where technology like a repository and registry can help.  Providing visibility into assets and their dependencies while automating their progression through the different stages of the lifecycle is critical for obtaining the goal of business agility.  Without visibility, there is no reuse, and automation of the lifecycle can greatly reduce the need for time intensive, manual compliance reviews, as these can be auto validated in order to progress SOA projects faster. 

There's also the notion of runtime.  Application of the governance process is very intensive in the lifecycle stages leading up to deployment, but what about after the assets are deployed?  This is where governance tends to breakdown, so a heavier emphasis on technology is needed.  Governance doesn't stop after version 1 of an application or service is deployed.  Your SOA needs to ensure everything operates within the policies defined by the business requirements, so technology that automates this enforcement at runtime is essential.  Additionally, your SOA is going to evolve, so you need the ability monitor the behavior of the elements of your SOA to not only ensure everything operates as intended, but also identify areas of improvement.  This can help the business understand where additional investment needs to be made. 

So after my discussion with my colleagues, who did we think was right?  It turns out that we're both right.  Process and organizational culture are key to successful SOA governance, but so is technology in making it more efficient, automated, and ensuring SOA evolves in the right direction. 

Welcome to my blog on SOA Governance!  I, and whoever I can con into contributing, plan to fill the pages of this blog with material, best practices, tips, and insights into different areas related to SOA Governance.  I've been working on various focus areas of governance since 2000 with the last 3 focused on SOA Governance and hope to pass on some of those experiences here.  At BEA I had enlisted the help of Bob Rhubart to publish a series of blogs called SOA Governance@work with the same purpose, and I hope to carry on that series here. 

If you'd like to take a look at some of the prevoius topics tackled when this series was part of BEA, here is where you can find them:

• 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

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 effective, 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 provides the best support for  your culture and process.

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

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

Late last year, at an SOA-oriented IT industry event held in Las Vegas, visitors to the BEA booth were asked to fill out a short survey on how their respective companies address SOA governance.  While thoroughly unscientific, this informal survey offered a glimpse into:

• What's happening with SOA Governance out in the real world, and...
• What happens to the already horrible handwriting of IT people when they are in a city that, by law, requires every adult human to be within three feet of an alcoholic beverage at all times.

Anyway, let's look at the data.

On the road to SOA Governance

Question #1: At what stage is your SOA governance program?

1. Planning/research:  64%
2. Up and running:  15%
3. Ready in 6 months:  14%
4. No plans for governance:  7%

No real surprises here. More than 90% of the companies represented in the survey are somewhere along the path the SOA governance. But what's the deal with the 7% with no plans? The next question sheds a little light on that issue.

No Governance, no SOA

Question #2: How important is governance in your SOA strategy?

1. Critical – without it, SOA will fail:  57%
2. Somewhat important – will be required at some point:  40%
3. Not important -- our SOA is flourishing without it:  3%

Again, nothing particularly surprising here, though for those who believe that SOA governance is "somewhat important," I wonder about the tipping point. Do they have a specific milestone in mind -- a certain number of services, or a certain number of service consumers --  or are they waiting until the need becomes obvious?  When they reach that point, will they regret waiting?

As to those who responded that their SOA is doing fine without SOA Governance, it's interesting to put that response in the context of the "no plans for governance" group in Question #1. If we can assume that those who responded "not important" in Question #2 represent some percentage of those who responded "no plans" in Question #1, what does that say about the SOA programs at the rest of the companies that have no SOA governance plans? 

I'm no statistician, and my math skills are exactly why my wife hides the checkbook, but the numbers suggest that there are ungoverned SOA programs out there that are doing a bang-up job of wasting lots and lots of money.  Failed or stalled SOA initiatives are hardly uncommon, but if those initiatives had placed a higher priority on governance, how might the outcome have changed?

The people problem

Question #3: What is the biggest challenge you have encountered in adopting SOA?

1. IT and Business organizational barriers:  33%
2. Learning curve / Insufficient skills:   25%
3. Cultural resistance:  24%
4. Introducing governance:  13%
5. Other:  5%

What's interesting here is that "Introducing governance" turns up so low on the list. That's not to imply that getting people to go along with SOA governance is a walk on the beach. But in the experience of survey respondents, it appears to be significantly less of an issue than cultural, educational, and organizational challenges. If the introduction of SOA governance is the path (or at least a path) of least resistance in SOA adoption, doesn't it make sense to start there, rather than approaching governance as an afterthought? 

What's in the toolbox?

Question #4: Which of the following is the most important SOA governance technology?

1. Registry/Repository:  42%
2. SOA or Web services management:  29%
3. Enterprise Service Bus:  13%
4. QA Test and Validation tools:  10%
5. Other:  6%

The registry repository comes out the clear winner here, a response that makes sense given that the registry repository has the broadest scope with regard to the entire SOA lifecycle. Overall, the responses indicate varied perceptions of what SOA governance is, and where the governance focus should be placed. That perception and focus -- and the initial selection of tools --  is undoubtedly driven by the specific, unique pain points in each organization's SOA governance experience. But the bottom line is that each of the products listed plays an integral role in end-to-end SOA governance.  So from that perspective, the right answer is "all of the above."

Note to vendors: make sense of the mess

Question #5: Which of the following criteria is most important when selecting a governance vendor?

1. Support for heterogeneous/best-of-breed environments:  34%
2. Vendor expertise and experience with SOA and governance:  29%
3. Provides an integrated SOA platform:  18%
4. Provides a broad, end-to-end governance solution:  17%
5. Other:  6%

While the responses to Question #4 may indicate some uncertainty or even confusion about the specifics of SOA governance, the responses to Question #5 offer some indication of a broader understanding of the general issues, or an indication that the respondents at least know what they don't know. Even without a calculator, that adds up to the need for overall solutions that will help companies fit SOA governance into their respective ecosystems.

Common goals: agility and efficiency

Question # 6: Complete this sentence: SOA governance will help my organization become…

• The words "agile" and "efficient," or various synonyms thereof, appeared in the overwhelming majority of responses.

Among the responses -- virtually all of which expressed the idea of better, faster, cheaper response to business requirements -- more than 30% of those who reported no plans for governance in Question #1 responded  in Question #6 that SOA governance would result in improvements in agility and efficiency. One possible explanation is that the people who responded to the survey understand the need for SOA governance, but their bosses do not.

What does it all mean?

This modest survey paints a picture of widespread recognition of the importance of SOA governance, and a general migration toward SOA governance in some form. That's good news. The indications of confusion about SOA governance are of some concern, but experience is an excellent teacher.

What's your experience?

How does your experience with SOA governance compare to that of the people represented in this survey?  How would you respond to the questions?

Other 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

A significant part of getting your SOA to do what it's supposed to do is getting the people involved in the SOA to do what they're supposed to do. While you're thinking about that, consider that "Don't Tase me, bro!"  was recently named the most memorable phrase of 2007. Coincidence? You be the judge.

Anyway...

In our last installment we looked at incentives and their role in getting people to get with the SOA program.  Developing the right incentives is important in that effort, but one of the most effective strategies for getting people to do the right things is to make the right things easy to do.  One of the right-est things in SOA is the systematic use of available services.

A service-oriented architecture is comprised of a network of distributed services -- chunks of self-contained, loosely coupled functionality that can be quickly and easily combined and re-combined to form a new breed of composite applications. SOA represents a far more agile alternative to developing applications the old-fashioned way, with picks and shovels and coal and steam and everybody wearing filthy overalls and getting all sweaty writing lots of new code.

There is some debate as to whether the use of services in this new kind of application development should be called "reuse," or just "use," or maybe even "sharing." Call it whatever you like, but one of the ways SOA improves agility is by making it easier to use what you already have, rather than building from scratch. The more systematic the use of available services, the more successful your SOA will be, and that increases that chances that your next holiday bonus might be something more than a calendar or a coupon for a free pizza.

Requiring development teams to seek out available services for use in projects is one strategy, but it leaves a lot of wiggle room, particularly for teams or individuals who have not entirely bought in to the SOA.  And even with the most committed of teams, the need to search for and evaluate candidate services can slow things down or even discourage service use. That's why prescriptive service use is a better strategy.

The process, in a nutshell, involves shifting the evaluation and selection of services to the project planning stage of the SDLC. This requires project planners to have visibility into the service portfolio, and an understanding of what is available. The appropriate services can then be selected and assigned to the project. The development team tasked with that project is then presented with what is essentially a bill of goods that includes the services and other software assets to be used. With the right tools in place, the services and other assets can then be presented to developers directly, via the IDE, saving time, saving money, and speeding application delivery. 

Prescriptive service use requires an enterprise repository to provide project planners with the necessary visibility into the service portfolio, and to integrate with developer IDEs to provide direct access to the prescribed services. 

In the highly dynamic, everything-is-connected SOA environment, decisions about which services to use in a project are ultimately architectural in nature, with potential alignment repercussions. Prescriptive service use allows those decisions to be made when they will do the most good, and when they will make the greatest contribution to SOA governance efforts.

Shifting service selection decisions to a point much earlier in the SDLC also means more proactive awareness of gaps in the service portfolio. Better to learn of such gaps long before the project team wastes time looking for services that don't exist.  This awareness aids in service prioritization and planning decisions, and helps to insure better alignment and business value as the SOA evolves. 

We'll talk more about service prioritization and planning in future posts.

Other 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

While noodling around the A2A blogs I found this bit of wisdom quoted in one of Steve Bennett's old posts:

“Hope is not a viable SOA strategy.”

I don't know the original source of that quote, but it's worth printing on a t-shirt, or maybe a tattoo.  Because in order to make SOA work, hope will get you only so far. You need governance, and any good SOA governance program has to include effective incentives.

The term "SOA governance" covers a lot of territory, but it ultimately comes down to the measures an organization takes to insure that its SOA does what it's supposed to do. In this blog and elsewhere you've no doubt read that SOA governance must involve people, process, and technology. Guess which of the three represents the biggest SOA governance challenge?

Hint: It's the only one that gets depressed.

In any organization, the transformation to SOA can represent significant changes in roles and responsibilities. Some people resist that change, in much the same way a lobster resists being plunged into boiling water with a dash of salt and maybe a lemon slice.

That attitude is just plain silly. SOA governance won't turn your exoskeleton bright red and render what's inside snowy-white and succulent. Still, getting people to go along with SOA governance measures is not an easy sell.

Mike Stamback recalls a presentation this past summer when Gartner analyst Paolo Malinverno asked his audience for a show of hands of those who believe that governance is essential to SOA success. The response was unanimous -- every hand went up. Malinverno then asked who wanted to be governed. Every hand went down.

So even among a bunch of people who recognize and understand the need for SOA governance, there were no volunteers.  Imagine that.

"Voluntary governance doesn't work,"  Mike advises. "You will get spotty adoption and then only parts of your SOA implementation are under control."

So what works?  A carrot? A stick? What about Tasers?

Mike describes how one BEA Oracle customer in Europe uses the stick approach. Compliance with the SOA governance process is a condition of employment. That's about as ambiguous as a roundhouse kick to the face, but it's effective. Another customer uses a carrot, in this case monetary incentives for those who comply with the governance process.  Nice, but there's a downside: there are no repercussions for those who choose not to comply.

Mike believes that the best approach combines the carrot and the stick. For instance, those who follow governance processes are rewarded with future project funding. Those who thumb their noses at SOA and governance risk having their project funding yanked.

A combined approach, Mike explains, can also include enough flexibility to allow those who elect not to follow a process to defend their actions. If the offenders can make a compelling case, the flawed governance process can be modified. This approach allows SOA governance to evolve in a controlled manner, which is important, given the continued evolution of the SOA and everything else. Governance should be tough, but it should also be reasonable.

In a recent InfoWorld Webcast,  the head of the global SOA program for an international financial services organization explained how that organization has implemented its version of the carrot-and-stick approach.

As part of its SOA program, the company's mandatory project funding form has been updated to include line items that ask whether the project will create reusable SOA services, or reuse existing services.  Every project is then subject to the approval of a representative of the SOA program, who is armed, figuratively, with a stick: projects that will create and/or reuse SOA services have a much better shot at approval.

The carrot, in this case, involves the annual performance plans for all of the company's IT employees. These plans include goals based on the creation and reuse of SOA services. In order to help employees meet these goals, the company provides SOA training courses to insure that everyone understands what the program is, how it works, and what its goals are. However, failure to attend these courses comes back to haunt the absentees when annual bonuses are handed out. As the program's project head describes in the Webcast, those who bail on the training get hit where it counts -- right in the wallet. With the carrot, apparently.

Whatever works. And based on the information presented in the Webcast, this company's SOA program appears to do just that.

Check out the entire InfoWorld Webcast -- it's good stuff.

In future posts we'll look at other aspects of SOA governance incentives, including steps you can take to make it easy for people to do the things they should be doing. 

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