In a panel at a recent SearchSOA virtual trade show, several experts spoke up on issues in this area. One thing all agreed upon was the need for an integrated and educated team.
Sandy Kemsley, an analyst and systems architect with Kemsley Design, said she often sees a team of business experts thinking in purely business terms and a team of developers thinking only in terms of what code they'll need to write. But SOA is not the sort of architecture that one builds by throwing code at it. It is, at its core, very conceptual.
"We have found that the biggest hurdle is invariably organizational and you have to start with training," said Peter Woodhull, principal at Modus 21. "IT realizes the burden is not on them anymore. The business has to be the responsible party."
A large degree of preparation goes into readying an enterprise for BPM through SOA, but the benefits can be great. Where processes often once lived in silos and did not make use of reusable components, a SOA-backed BPM is far easier to modify and connect with new processes down the road.
Woodhull said that SOA may actually give smaller companies a competitive advantage. In larger organizations, there is often a mentality of implementing SOA for compliance purposes, he said. The smaller an organization is, the more fully it can adopt SOA principles from the offset. And thus, the more effective its BPM practices might turn out to be.
"Using BPM and SOA together really pays off as your timeline increases," said Marc Smith, director of technology marketing at Lombardi. "It's when you start looking at the long term goals and execution that using SOA techniques in conjunction with your process improvement tools really starts to pay off."
The panel generally agreed that it is of utmost importance for the business and IT side of a BPM implementation to work together to define exactly what the business objects are and what operations need to be performed on them.