Nothing like a little collaboration to shine some light on a few issues and come up with a solid list of best practices.
That's what happened when Forrester Research Inc. recently gathered a dozen application architects and thought leaders from large enterprises in London for a roundtable on
Companies have been architecting their IT infrastructures to deliver protocol-independent services for years -- no surprise there. But when a meeting of the minds happens, people get granular. The 12 experts talked about their real-world SOA experiences and hashed out a list of nine tips that any enterprise could adopt.
"These people wrestle with similar problems," said Randy Heffner, Forrester vice president. "There was a good breadth of issues and stories that emerged."
The roundtable served to reinforce some common-sense SOA tenets like tightly linking SOA to business processes while surfacing some less obvious takeaways like version resolution.
"One major issue with SOA and any enterprise is reuse [of code]," Heffner said. "The great thing about it is that 20 applications can use the same service. But if you change a service, all 20 applications have to be retested."
Version resolution enables an enterprise to run multiple versions of a service at the same time -- and was a common hiccup for a few of the architects.
"What was surprising that one client was able to attest for the need for version resolution and had a good, custom-built architecture in place," Heffner said. "It's one issue that no standard addresses or vendors are talking about."
Heffner said in addition to aligning services with business processes, enterprises should sponsor workshops that set the context for business processes and services alignment. Selling developers and decision makers on the idea is crucial for success, the panel said.
Next, the panel said enterprises should use vertical and horizontal models to illustrate business processes. For example, vertical process domains illustrate the end-to-end business process, Heffner said. Horizontal processes and technical services (i.e., document retrieval) support the vertical processes.
The panel also concluded that it's acceptable to do service orientation without having a Web service architected. Web services are the accessibility layer, Heffner said, on top of the service-based design. The panel advised pursuing both disciplines.
Building a single service interface is the next best practice to follow when connecting disparate applications. Heffner said that a common interface also enables underlying applications to evolve away from the client apps that consume them.
With outsourcing in such vogue, some enterprises may entrust their SOA to an outside provider. Heffner said it's imperative that companies maintain control, otherwise service design could go in many directions. The panel concluded that enterprises should use joint service design teams, list principles that should be built into a service and write into the contract that a third-party review team examine the service once it's complete.
Buying packaged applications also wrestles control away from an enterprise. The panel suggested four ways to counter that possibility: layering XML interfaces on top of a package's APIs, using custom off-the-shelf or custom integration adapters, using Web services interfaces provided by the package, and wrap a screen-scraping interface as a Web service.
Finally, in addition to have a version resolution architecture, the panel recommends implementing a service-invocation architecture, or a service-delivery bus. Version resolution, routing, billing and transformation services are examples of a bus.
FEEDBACK: What are your best practices for implementing an SOA?
Send your feedback to the SearchWebServices.com news team.