SOA Governance@work

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

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