Everybody wants governance, but nobody wants to be governed.
That statement by Ron Schmelzer sums up the conundrum faced by SOA advocates: governance is desperately needed to keep SOA projects on track and in focus. What happens, though, is SOA governance gets weakened and watered down by vested interests, or lack of motivation to make SOA work.
SOA governance needs more automation to reduce the 'chaos'
I recently had the opportunity to moderate an ebizQ panel on the topic of SOA governance, which genarated a lot of discussion on the challenges of selling governance to a skeptical audience that may not want to be governed. The panel consisted of a stellar line-up of industry experts including Anne Thomas Manes, vice president and research director with Burton Group; Ron Schmelzer, managing partner with ZapThink; David Bressler, SOA evangelist for the Actional products at Progress Software; Ed Horst, vice president of marketing and product strategy for AmberPoint; Frank Martinez, senior vice president, product strategy for SOA Software; and John Michelson, a founder and chief scientist of iTKO LISA. (Archived audio replay available here, full transcript here.)
When promoting SOA and SOA governance, the question that comes up across the enterprise will be 'What's in it for me?' Why should developers reuse someone else's code when they're perfectly capable of creating their own code that may better suit the needs of the project at hand? Why should a business unit share its code -- which it paid for -- with another business unit that didn't pay up front for the development work? Why should the department manager pay more for a project with the promise that it will cost less to build the next time around? Why should a business executive get excited about standardization across interfaces?
As Anne Thomas Manes put it, 'What's in it for me?' can be a showstopper question for SOA and SOA governance. "Anytime you want to get somebody to do something for you, you have to answer the question what’s in it for me? If you’re trying to ask the business guys to give up a certain amount of self-determination by accepting the use of another service, or if you’re asking them to perhaps give up something special that they wanted for something more generic, why are you asking them to do this, and why would they even consider doing that if they have to give something up? then it’s really important to explain what’s in it for me.. and here's what you want to do.
Anne urged that the governance effort be made as user-friendly as possible. "When it comes to a governance program, if you can make the governance program helpful to the people who are required to adhere to is, as opposed to something onerous, then they’re going to be a lot more happy about following the rules," she said.
A decentralized, federated approach to SOA governance may fare better than a centralized structure. When it comes to acceptance of governance, Jon Michelson points out that all good governance is local. Even if the policies are heavy-handed or nonsensical, people may be far more willing to accept governance at a more decentralized, "local" levels, versus more centralized approaches, he said. "We are more tolerant of greater control closest to us than we are far away. So if there’s this very distant group of people who decides on how were supposed to build and consume services, then we will tend to react negatively toward that. But if there is even if it’s a fairly onerous set of policies, but it’s shared, and its owned by me and my close constituents. I tend to be more willing to do it."
Members of the panel also emphasized that technology solutions in and of themselves are not adequate for achieving SOA governance. "The organization has to be ready for governance," said Frank Martinez. "While SOA registries and repositories certainly are a necessary mechanism, they by no measure deliver governance on their own you really have to make investments in those areas. It’s really about encouraging desired behavior."
Anne agreed, noting that "governance is about process. It’s about defining policies. And establishing processes that you use to verify compliance with policies. It’s about measuring what you’re doing,and it’s about having an organization that actually provides a certain level of support for the governance program in the first place. This is a process, and as I’m developing my code. I need to make sure that the code is conforming with my principals and with my best practices, and with any legal regulations and requirements that I have."
Manes said to gain acceptance, SOA governance needs to be as automatic as possible. However, many registry/repository solutions fall down on the job, said David Bressler. Automatically capturing direct information or metadata about a service "is where registry repository has failed," he pointed out, "because it's not capturing anything. Its not automatic at all, and frankly its nothing more than a fancy spreadsheet of information about your services that you can email around once a week to your development team."
"What happened is people started with registry repository because they wanted to get a handle on the chaos. But because its not automatic, they didn’t get a handle on the chaos."