One of the problems blocking servive-oriented architecture (SOA) adoption in companies is that when the architects...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
and developers start talking in jargon, they lose the business executives and managers in the blur of XML, WSDL, SOAP and UDDI.
This was the consensus view of SOA panelists at the recent OASIS Symposium in San Francisco. One of the panelists, Robert Carpenter, senior program manager at Intel Corp., summed up the problem by saying valuable as HTTP, XML, SOAP and UDDI are to SOA, talking in those terms is not going to excite management. He urged architects to focus on business values.
This view was reinforced by Forrester Research vice president Randy Heffner, in the closing keynote at the OASIS meeting. He told his audience that SOA will only advance if IT and business people can find a way communicate and work together.
So the question is how to bridge the gap between the IT technologists and the business manager, who may only think of SOAP as something to use in the shower?
David Groves, senior director, worldwide consulting for BEA Systems Inc., works on a daily basis to bridge that gap. He believes there is a way to achieve balance between business and technology, so SOA can work.
"It's a balance of the technical and non-technical approaches that makes SOA successful," he said in an interview this week. Not that he finds striking that balance an easy proposition.
He recalled a recent session at an executive briefing where CTOs were lamenting that they are going round and round because neither the IT professionals nor the business managers wanted to take ownership of specific issues with SOA projects.
"IT says, we don't have the problem, and HR says, we don't have the problem and finance says, we don't have the problem, and it goes around in a circle," Groves said, recalling the CTOs' dilemma. In his opinion the vicious cycle starts at the highest level of viewing SOA, which is where business strategy and processes are defined so the SOA applications can support them. Each department looks at it in the old-fashioned compartmentalized point of view and says it's not their problem.
"There's no ownership because people don't really understand who owns the problem," Groves said. "And they don't understand who owns the problem because they can't communicate because the terminology is too hard."
But the consultant is not without hope, because he has found that the source of confusion can also be the starting point for communication between technical and non-technical people in an organization.
Based on real-world experience consulting on SOA projects, BEA consultants in the past two years have developed a model for thinking and talking about SOA that breaks it into six "domains" that are defined without jargon. Three of the domains, which BEA labels as "business strategy and process," "costs and benefits," and "organization and governance," are basically business issues. The other three, "architecture," "building blocks" (i.e. services) and "projects and applications" are basically IT issues. But all six domains in the BEA model are presented with a minimum of jargon to make it easier for non-technical people to talk to architects and developers, Groves said.
Beginning with a discussion of how SOA will support business strategy and process, the communication barriers can be broken down. Getting the project started with both the technical and business people understanding and agreeing on how the SOA implementation helps the business, is the key to success, Groves argues.
He recalls that this was not true in the 1990s when client/server was in flower and business people were forced to learn developer jargon before they could figure out if an application would help them get a job done. Meanwhile business strategy and process was usually an afterthought.
"The interesting thing is the business strategy and process domain enables you to find a way for IT and business to talk about SOA in a way that everybody can understand," he said. "With SOA, it's important to take into account far more of business strategy and process, cost and benefit, and organization and governance. In fact, studies have shown that lack of attention and focus of those three things is really what's made previous attempts at reuse less successful than they should have been."
SOA done correctly offers an opportunity for the services to be discussed in terms of the business strategy and processes they will serve, so that business users can understand and participate in discussions and decision making, Groves said.
"The basic principle is, making SOA understandable, making it something that business and IT own together so that when you have a business strategy, it's linked directly to IT," he said. "And I think that in many cases in the past, that just simply wasn't the case and that's one of the reasons why people complain now about silo applications."
Noting that in days of old, COBOL programmers probably were more closely allied with business people than was true in the client/server era of the most recent decade, Groves sees SOA reuniting developers and business users in a common cause.
"For me, what I love about SOA is it brings the developer much closer to the business," he said. "I feel that the developer has been pushed out more and more with middleware becoming more and more abstracted. Whereas, in a service world, where the service has to be a component of business functionality that relates to a process and is interoperable with other components process, it brings the developer back to the actual business itself, because they understand how it fits into something the business delivers to a customer. I think for the developer, SOA's really a positive move."