If SOA today is a less lively topic of debate than it was a few years ago, it is still an area where development managers seek out case studies and ''lessons learned.'' That is because the move from one-to-many SOA projects remains a hurdle. At IBM Impact 2012 in Las Vegas, attendees sought SOA know-how, which took the form of several sessions that outlined the “SOA Journey.”
While SOA as a project becomes more common, SOA as a program is still busy being born. SearchSOA.com’s 2011-2012 reader survey bears this out. The data shows 77% of survey respondents have a SOA or are investigating one, but only 28% have of respondents’ organizations have multiple SOA projects underway.
Barriers to immediate and wider use of SOA may include project management complexity, limited skill sets and the time it takes to build-out supporting SOA infrastructure. Connecting and selling SOA to the business side of the organization is also a challenging effort, and it can halt or delay SOA adoption.
Some organizations can justify going outside to gain SOA expertise, but even they need in-house skills as well, and these skills tend to come only with hard-earned experience.
“You need to have a certain level of expertise in house. The people inside have a much better understanding of your business processes,” said Daniel Neal, general manager, Australia-based Royal Automobile Club of Victoria. Neal’s group has delivered 60 different services as part of an effort to update and replace systems “to improve front-line delivery capabilities.”
Neal said that a business leaders will call for clear return-on-investment (ROI) benefits, and these may require very careful selection of the early application targets for SOA transformation. You will find it hard from an ROI perspective if you do not have a strong business process to work on,” he said. He and others spoke at an “Our SOA Journey” session at IBM Impact.
“Our SOA journey stared with realizing first off what our business model was” said Ryan McGuiness, enterprise architect and planner, First National Bank of Omaha. A goal was to reduce siloed systems covering various offerings at the bank, and enterprise service bus (ESB) infrastructure was a means toward that end.
“From that vision we spawned our SOA strategy, to act as one company at the SOA level,
stated McGuiness. “We paved the highway with an ESB,” he said.
The ESB played an important role in the SOA journey of one manufacturing firm, according to James Lynes, lead enterprise integration architect at motion control specialist Parker Hannifin. But, like others, Lynes cautions against mixing business logic and transformation logic in the ESB.
“We try to say that our ESB is for transformation. You really don’t want to put application logic in your ESB. It’s a slippery slope” he said. To that end, he advises: make sure “the appropriate teams own the appropriate aspects of integration.”
For some, the challenge of SOA comes with the first project. These can provide SOA wins important for selling the method to upper management. But for many, it is the follow-up projects that are daunting, said Joe McKendrick, independent analyst, writer and blogger, on hand at Impact 2012.
“Ideally, SOA should start as a small project, quick-win type of thing. It shouldn't be too hard for someone to create such a service -- they could write something up in a matter of days,” he said. “The daunting part comes later, when the idea of reusable services needs to be brought to other parts of the business.”