News
SOA Governance: "Not Much" Success, Panelists Say
Experts described the state of governance, which isn't easy to do but it's really necessary for your SOA effort
What are the best practices for an organization to sustain its service-oriented architecture (SOA) effort? With SOA, you associate services with specific business activities. That involves loose coupling and achieving greater granularity within the system. Under these circumstances, governance is seen as a key component for managing SOA systems, especially at the outset of the SOA effort.
A panel of experts examined the question of governance in SOAs based on real-world practices. The SOA Governance Panel was part of the Enterprise Architecture Practitioners Conference held last month in San Francisco.
The panelists were all SOA veterans. They included:
- Andrew Hately, a senior technical staff member in IBM's software standards group, experienced in applying service discovery, network discovery and service management standards to industry and business problems;
- Kyle Gabhart, director of the SOA technology division of Web Age Solutions, with a focus on service-oriented technologies enabled by Java, .NET and XML;
- Stephen Bennett, BEA's Americas SOA practice lead with an emphasis on SOA organization and governance;
- Michael Nassar, an enterprise integration architect with IBM specializing in SOA and Web services technologies (especially the IBM WebSphere Enterprise Services Bus, which provides Web services connectivity); and
- Mats Gejnvall, certified enterprise architect of Capgemini. Gejnvall specializes in enterprise architecture and SOA within large organizations (such as telcos, supply chain and defense).
SOA Governance Success Stories?
The panelists were first asked to provide SOA governance success stories. The collective answer was "not much so far."
Gejnvall said that Sweden, where he works, is just getting started. "That's why we're developing these frameworks," he said.
Bennett concurred on this side of the pond, saying that "it's an ongoing multiyear project" and that customers were mainly reactive, not taking SOA governance seriously until they encounter challenges.
"You need to evangelize in force, with incentive models in place, or you'll fail," Bennett said. He stressed the importance of having a repository. "Unless you have the information at hand to course-correct, you'll get into trouble."
Nassar gave an example of why governance is important. He described the case of an insurance company that had started developing Web services for their department. When they tried to start doing reuse, they discovered that the services weren't reusable. Developers had started modifying the services to fit specific needs without taking overall company needs into account. They got into a fiasco with versioning, with 16 different versions of one service in play, for example. Nassar's team went in and straightened out the versioning issue.
Gabhart talked about a Department of Defense (DOD) group in the Washington, D.C. area.
"[They] had this lifecycle set up and the last stage was called 'governed,' he said. "They thought it happened after everything else was done."
Gabhart's group had to install key gates and make them understand that governance needed to be global and happen throughout development."
EA vs. SOA Governance
When asked whether there should be a difference between SOA governance and enterprise architecture (EA) governance, Gabhart pointed out that various organizations have EA or SOA or business process management (BPM) as "the big umbrella." He sees the three areas converging. You need IT to be aligned with business goals and processes, you need consistency across business units, and you need standards for more predictable business strategies, he acknowledged.
"IT isn't just locked in the server closet," Gabhart said. "It's out there promoting visibility and enabling the business' objectives."
Bennett talked about companies where EA governance has failed, concluding that "taking it more from a portfolio or iterative way may help." It also helps to take care of governance from the start.
"SOA in general highlights existing challenges," Bennett said. "If you've had enterprise governance issues in the past, SOA will make it worse. You must straighten them out first."
Nassar sees SOA as an extension of IT.
"The reason we have SOA is so we can reuse services," he said. "You must have guidelines to ensure that these services are reusable -- rules and policies controlling this use and reuse.
Gejnvall said that if the company doesn't have EA governance beforehand, SOA governance takes over responsibility for the former. "They fit well together," he added.
Snake Oil Architecture?
Dave Estrom from Sun challenged the panel, saying, "I think SOA stands for Snake Oil Architecture…customers are asking for specifics, not platitudes."
Bennett replied that there are no pure SOA governance standards. The Web Service Interoperability Organization (WS-I) provides some industry standards, but SOA governance is about "creating your own internal IT standards and living by them," he explained.
For Nassar SOA governance is about creating a centralized entity that receives everybody's input but represents the whole company. It means making sure that the services being developed fit the requirements of the whole enterprise and aren't biased toward one department or another. Another concrete step would be a service registry or repository "like IBM's WebSphere Service Registry and Repository (ours). You can't really achieve high-level governance/reliability without tools like that," he said.
"Requirement analysis tools and the like become more critical because the use of these tools is more stringent," Nassar added.
Gabhart, referring to his DOD case study, said that a lot of what this unit was doing involved metaframeworks, but "this is one of the less mature areas of SOA." Consequently, Gabhart said he trying to play it safe for now, using configuration management products "where there's a little maturity."
Gejnvall said that "the standards part of governance is a good question we've been debating." For him, governance "is about making sure standards are followed -- every one that's been mandated by the company. It's an enforcement activity."
Gejnvall added that Control Objectives for Information and related Technology (COBIT) and The Open Group Architecture Framework (TOGAF) might be appropriate standards to follow.
However, Bennett said that his group tried to use the COBIT standard "with little feedback from COBIT [the parent organization]. We did try to contact them six or nine months ago with no success."
Start With EA, Then Implement SOA
The panel was asked for a governance plan. Gejnvall said that in an ideal world, you'd start with EA and then with SOA. Next, you'd need governance within the SOA development space to make sure that EA governance is followed.
Bennett's angle was that you need to put policies in place to make sure you're not wasting your money.
"SOA has many assets that need to be governed," he said. "Make sure it's practical."
For Nassar, SOA "is just a natural evolution." You should implement practical governance ideas that ensure reliability of services. And "all the other standards we follow still apply."
Gabhart added that "what it ends up looking like depends on the business proposition." But then he parted ways with some other panelists, saying, "I don't think reuse is what we're targeting. We've been chasing that for three decades without too much success. It may be agility, alignment.…Whatever the motivation, governance is a risk mitigation strategy for achieving your company's value proposition."
How To Make SOA Governance Happen
The panel was asked what they use to make SOA governance actually happen, beyond installing a service registry. Bennett said that it takes psychology -- understanding how the company works today. As for reuse, Bennett said that "we can achieve a level of that but never what we'd like." He added, "I spend a lot of time on restructuring IT and tying it in with lines of business."
Nassar disagreed about reuse, still feeling it was possible. He said that building a service to be reused in the future with unknown applications requires using "some classic tools that help us develop software in a more stringent and methodical way." He cited using tools for requirements analysis, modeling of the business, a methodology tool and a repository of assets.
Gabhart joked -- sort of -- that "the most effective governance tools I know are Excel and Visio." He said you have to build a dialogue about how to adapt/change/mold SOA to navigate the political structures, the people and the resources, using wikis, whiteboards, whatever it takes to foster that discussion. He added that a lot of valuable items are not reusable, such as paper plates, paper diapers and foam cups.
Does SOA Governance Reduce Dev Costs?
One question to the panelists was this: If a CTO came to you and said she wanted SOA governance to reduce her costs of development, would you take the job? Gejnvall said no, as did Bennett, who added that governance has the potential to do that, but it takes a lot of education and evangelizing.
Nassar said that governance will eventually reduce costs but not in the short run. He added that SOA governance "gives you flexibility and agility so we can react faster, change our composite apps quicker so we don't have to rebuild them more than once."
How Do You Convince People To Try It?
When asked about the politics of adoption, Bennett said the most effective was an enforcement model. But it's bad for morale and most people lack the authority to force it through anyway. So they use an incentive model with links to bonuses and career structure.
"It's hardest to do with existing employees," he added. "Instead we go out and hire a skunk works team of new employees."
Gejnvall argued for incentives.
"If you've got a project and they develop a service, they get more money, time. If others start reusing it, they get even more money."
Gabhart said he's not anti-reuse…just skeptical. "And I know how many executives cringe at the thought." He mentioned making reuse the assumption and requiring developers to show why they aren't reusing. Or $1,000 spot bonuses for every successful reuse -- "though you then need QA processes to stop fraud." For Gabhart, though "governance is not an inherent good. You use it to avoid or reduce pain."
Which Methodologies Work Best?
Does a particular methodology mate well with SOA governance? For Bennett, it's the old-fashioned waterfall model. He added that "you can use agile methodology [iterating code throughout the lifecycle] with a skunk works."
Nassar touted extreme programming methodology because it "brought up issues quickly."
For Gabhart it's more of an issue of timing. If governance is implemented too late, he said, "there's a momentum already started. It can be a lean governance but it needs to be [implemented] at the start. Then you can grow it incrementally as SOA grows."
Governance Priorities?
Asked about governance priorities between services, solutions, portfolio, or service architecture, Gejnvall opted for solutions. "Make sure solutions that are available are reused," he said.
But Bennett said that "If you're starting from scratch, do the portfolio; if existing, do services. Maturity and SOA adoption dictate the priorities."
Gabhart said you have to make sure the services are "rock solid and 100 percent reliable. All hope is lost if you can't depend on the services. Then you can move to a larger context."
-- Lee Thé