News

Governance Is Key to SOA, Panelists Say

• By Kurt Mackie
• August 27, 2007

Panelists included representatives from IBM, BEA Systems, SAP and Cisco Systems. The session was moderated by the SOA Consortium's program director.

No one on the panel actually defined what they meant by governance. However, one of the slides presented by Christian Hastedt-Marchwardt, SAP's solution marketing director for enterprise SOA, used a definition of governance from the Burton Group analyst firm:

"Governance refers to the processes that an enterprise puts in place to ensure that things are done right, where 'right' means in accordance with best practices, architectural principles, governmental regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA" -- Anne Thomas Manes, Burton Group

Hastedt-Marchwardt emphasized how SOA governance connects business objectives.

"SOA governance is the key piece that actually helps you to link the different pieces, like the business strategy linking with the IT strategy, and with your solution portfolio planning and operations," he said.

Governance From the Top
Governance is also about organizational control, including both functional and nonfunctional aspects of decision-making, according to Fill Bowen, IBM's marketing manager for SOA governance.

"The answer is you have to have both because SOA governance is about decision making," Bowen said. "I mean, at the end of the day, SOA governance is really who gets to make what decisions and what the impact of those decisions are."

The architect is that person who will decide on governance issues, the panel seemed to agree. Clive Read of Cisco Systems' SONA program also emphasized the importance of teamwork to governance, saying that governance "is too big of a burden to put the whole thing onto an individual."

Other speakers later emphasized motivating the team. However, the whole impetus for SOA should come from the "C-level" (CIO, CTO, COO, CEO), Bowen stressed.

"It's going to have to come from the top down," he said. "The developers are not going to want to do SOA. It's too big a paradigm change for them."

Developers and SOA
Bowen addressed fears that developers might have about losing their jobs with a move toward SOA.

"We've had some companies that said, you know, 'going to SOA is a way to downsize.' That is not the intent of SOA. It's not intended to downsize your IT shops. It's intended to make your business more productive," he said.

Brenda Michelson, program director at the SOA Consortium, noted a general climate where "developers don't want to do SOA right" and that "developers hate SOA…just because it's extra work from a development point of view, because of the extra protocols."

She asked how those wanting to do SOA would "get the developers on board."

The response was the three "E"s -- "encouragement, enticement and enforcement," according to Ed Cobb, vice president of architecture and standards, office of the CTO at BEA Systems. Cobb described making SOA part of the developer's "business interest," without elaborating on the point.

Another way to motivate developers to get behind SOA is to give them "the feeling that they're doing a good piece of a special and a very interesting project," Hastedt-Marchwardt said.

It's About People
In the end, SOA is about people, with the architect in the lead, all helping business objectives. Once the team is in place, SOA will gradually provide the solutions.

"You have this nucleus-based approach where you start with people that build their design principles, build their roles and responsibilities and the procedures in small centers and then proactively go into the projects and say, 'Okay, listen, we're going to help you'," Hastedt-Marchwardt said.

Cisco's Read put less emphasis on the development aspects about SOA because "a lot of it is about people, influencing, organization, operational change." He stressed a certain amount of realism about SOA, with the idea that business executives pay more attention to the operations side of things than about SOA mechanics.

"Guess what, it's [about] the call center meltdowns, the network falling out…so you're absolutely tapped into operational performance," Read said.

The Money Issue
Getting funding for SOA proved to be a somewhat difficult subject to get hold of among the panelists, mostly because SOA is a long-term project, with benefits that extend across individual projects.

One suggestion, from Bowen, was that "the first person to develop a service pays for it." Others subsequently wanting to use the service will get to "use it for free," he said.

Barbara Errickson of EDS, a participant at the event, suggested another way of getting support from management to fund SOA. Simply explain to management how SOA costs less in the aggregate.

"Pool your money, do the project together and get an interoperable solution," she said. Funding for SOA should happen at the enterprise level, rather than at the individual project level, she emphasized, and it requires new thinking at management levels to accomplish that.

"It does require an organizational change to get the people with the money together, to agree on that different approach to the major project," Errickson said.

SAP's Hastedt-Marchwardt suggested that SOA initially might be a "very project-driven approach," but that it would eventually evolve from "the typical silo or fiefdom-oriented approach."

SOA for the Long Haul
SOA has a long-term aspect to it. It will take internal organizing to make SOA work, and you want to have that happen in your organization, according to Cobb.

"This is something that's going to take you several years, five plus years probably from the beginning to where you want to get to," he said. "Some people might like to have a consultant in there for 10 years doing this all for you, but I think from a business perspective, you want people in your organization that know how this is done, and how to do this in a way that benefits your business. I think this (business focus) is a big part of what SOA is about compared to some of the other technological paths of the past."

Governing Well
It's tough to govern well, and that's the reason why you need a way to measure it. One of the failures of governance is that organizations fail make such assessments, according to Michelson.

"I've seen that in a lot in organizations, where you make a great business case and you probably did achieve it, but you don't actually go back and do that final measurement," she said.

Bowen described the measurement aspect of governance as establishing a checkpoint. The checkpoint is a way of assessing if approvals have been made by decision makers, noting any exceptions.

"The governance framework says at the end of deployment we have to have a checkpoint, and so one of the measurements for governance is, have we had that checkpoint," he said.

The panel covered governance in greater detail than this brief summary. The complete presentation of the SOA Governance Roundtable, including audio, text and slides, can be accessed here.