There's no time like the present, said some compulsive, annoying person who apparently never procrastinated.
But is that really true with SOA governance? Could you actually thwart your SOA implementation by throwing in governance too soon?
David Linthicum raised this question Monday after doing a podcast with Burton Group VP and Research Director Anne Thomas Manes. Wrote Linthicum:
"... I had one takeaway from the conversation that's been bugging me for a few days: In essence, instances where SOA governance is actually distracting to the progression of SOA."
As I read on, I began to suspect that Linthicum really thought the problem wasn't so much adding SOA governance too soon as adding packaged SOA governance technology too soon, particularly when I read this:
"The issue is that SOA is about getting things right from the foundation to the higher level processes, and SOA governance technology has a tendency to muddy up the water in the early stages of the project when forced into the mix. I know of a few projects that are in trouble because they chased SOA governance as defined by the technology they purchased, and did not focus on the fundamentals."
That may be a problem for some companies, but it strikes me as one of their own creation. From everything I've read, SOA governance technologies and SOA governance are not the same thing at all, a fact I recently discussed during an interview with Todd Biske, a working enterprise architect, blogger and author of "SOA Governance."
We'll be publishing the full interview soon, but I asked Biske if buying a SOA governance solution was a good first step for SOA governance -- would it even get you to full SOA governance? Biske responded:
"It definitely does not get you governance and so a couple of times in my blog I've jumped all over this whenever I've seen people taking the approach of, you just need to buy this tool and you get governance. No matter what we look at, tools are there to support the processes and make them more efficient. They very seldom give you the processes and the same thing applies in the case of governance."
Or at least, that's what the transcript says. I must have a hearing problem, because what I heard (in my head) was, "Yeah right. In your dreams."
Biske recently posted a response to Linthicum's piece, agreeing that you should not let the SOA governance technology drive how you approach SOA goverance. But he also warned against starting too late on SOA governance:
"If you are adopting SOA to change the way you approach solution development, you need to make the desired behavior known early and often. If you wait until a team 'misbehaves' before making them aware of the correct behavior, it will create animosity."
I wonder: Is it timing -- the when - that is really a stumbling block? Or is it the details -- the what, where and how - of SOA governance that really matter?
Aberdeen recently released for public viewing an Aug. 2008 report titled, "SOA Governance: Separating Success from Chaos," which I found just before I saw Linthicum's post. After reading this report, I have to think there are many little details more important than timing.
If you're familiar with Aberdeen's reports, you know they like to separate companies into Best-in-Class, Industry Average and Laggards. This report is based on interviews with CEOs, CIOs and other IT workers at 120 enterprises using SOA governance. (The complete details of Aberdeen's Research Methodology are on page 18 of the report.)
The report gives this admonishment about success with SOA governance:
"Truly effective SOA governance infects itself into the organizations' DNA, with roots in both technology solutions, and internal processes and procedures."
That's a great line, though the verb choice - infect - is a little disturbing. But let's look at what that means in practice. What, specifically, do Best-in-Class companies do that the rest do not? Here's a partial list, taken straight from the report:
- "... the top strategic action Best-in-Class organizations take to advance their SOA governance initiative is to ensure executive level commitment to the SOA implementation (62 percent)."
- "Best-in-Class organizations are 87 percent more likely than Laggards to establish clear roles and responsibilities for the staff assigned to the SOA governance initiative."
- "Best-in-Class organizations are twice as likely as Laggards to supplement and enhance the clear delineation of roles and responsibilities with extensive communication channels and procedures."
- "Seventy-seven percent of Best-in-Class organizations responded they have established a registry/repository of all web services in support of their SOA governance initiative - 2.6 times more often than Laggards."
- "Best-in-Class organizations are 93 percent more likely than Laggards to incorporate defect tracking and reporting tools..."
- "Best-in-Class are over 6 times as likely as the Industry Average to use SOA performance reporting software or appliances."
- "Best-in-Class are also more likely than Industry Average and Laggard organizations to incorporate SOA acceleration technologies (39 percent) into their governance strategies."
I probably don't need to point out that the Best-in-Class also reap big dividends on these moves. For instance, in the area of integration alone, the report notes:
"By incorporating technology that provides visibility into how services are performing, their defects, and subsequent remediation prioritization, Best-in-Class organizations are 108 percent more likely than Laggards to report a decrease in integration costs."
Now, Linthicum references his conversation with Manes, who does field research. I suspect and hope the podcast has more information about what she's found in regards to timing and SOA governance in her research. The Aberdeen report did not specifically mention timing as a factor in successful SOA governance, so perhaps they didn't look at it.
The report does make a point of saying these organizations pursued SOA governance because they wanted to reap wider business benefits with SOA - so perhaps they were already past that timing pain point Linthicum referenced.
But with all due respect to those in the field, I'd have to say after reading the Aberdeen report, I'm left with the impression that the sooner you start SOA governance, the better -- provided you're driving governance and not expecting some packaged solution to do all the heavy lifting for you.
In fact, you could probably use Aberdeen's Steps to Success, which starts on page 15 of the report, as a guide for avoiding the very problem Linthicum points out -- letting the technology drive your governance -- and still start SOA governance very early in your implementation.
I say this because the recommendations for laggards urge you to first get your business ducks in a row by assigning clear roles and responsibilities for those involved with SOA and measuring the effect of your governance framework based on business processes. It's hard to see how, even in the earliest stages, that first step to SOA governance could cause you to stumble.
This suggests to me that there are more important questions to consider with SOA governance than when you should start. For instance, ask who's driving SOA governance (you or the technology tool)? Where should you begin (the report provides a hint that it should be with securing executive business support)? And what steps should you take now to support long-term success?