Panel: SOA better prepares enterprises for cloud, data integration

Would a company that has embraced SOA be able to ramp up to the cloud more quickly and effectively than a company with no SOA?

Panel of SOA and cloud experts talk about SOA-cloud connection, data integration issues, REST versus SOAP

Bob Kemper, whose company, PivotLink, delivers cloud-based business intelligence services to numerous companies, observed that many customers do not have SOA, and yes, while integration between systems and data “is not an insurmountable problem, it is a more complicated problem to manage across the board.”

Kemper was part of a recent Webcast panel discussion which explored the latest opportunities and challenges as SOA enters the cloud era.  The panel included Randy Heffner of Forrester; Larry Mieldezis of Liaison; Ash Parikh of Informatica; and Bob Kemper of PivotLink joined Information Management's Eric Kavanagh and Jim Ericson.

Single sign-on capabilities are an example of how service orientation speeds up the cloud on-ramping process. “If someone already has a single sign-on service, having it already implemented within their infrastructure, we can just plug into it right away, without an additional process step.”

Panelists overall agreed that they see cloud computing is reviving interest in SOA,  but there are still challenges that need to be addressed. Simply separating  business processes from technology is still something every effective SOA proponent needs to emphasize, Randy Heffner said. In the end, technology is almost irrelevant. “The implementation behind an SOA interface can be anything – monkeys with typewriters. So long as it delivers the functionality that's expected.”

As Kemper put it: “SOA is an architecture and also a set of business drivers and related services that is the enabling piece behind SaaS. It allows that business agility to come into play, and make sure that they can do and make the changes that is needed in their business – without impacting their corporate infrastructure.”

The panel also tackled a number of other issues that inhibit the ability to achieve business agility through SOA. A critical issue that many SOA-aware enterprises are now running into is the viability of data being made accessible across the enterprise. Heffner observes, for example, that Forrester's surveys were finding that two-thirds of all companies implementing SOA-based infrastructures were doing so “for pure data access.”

While SOA is an effective method for enable cross-enterprise and inter-enterprise access to data and applications, data quality is a major issue that is cropping up, Ash Parikh observed. “What if the data sources had dirty data or consistent data to start with?” he asked. “Then you're propagating that dirty data, up to the end point which end-users will consume that information.”

Parikh advocated the creation of a data services layer as part of a service oriented architecture to manage the often-complex challenges that accompany managing data from disparate parts of the enterprise. Part of this complexity comes from the need to maintain and leverage two types of data – historical and operational. Effective decision making requires integration between both analytical and real-time information, he added. “You need a data services layer that can complement SOA. You need good data that you could trust, at a time you need it.”

The panel also tackled the continuing debate between building SOA-aware services through REST protocols or SOAP-based protocols. Heffner cautioned that the REST protocols often can't deliver robust functionality required for enterprise-level integration and exchange of services. “REST is just a simple protocol to do some simple things,” he said. “SOAP and the WS-* standards around it are trying to address security, reliable messaging – a broader set, deeper set of problems. If you have a need for reliable secure messaging in a way that you're sure that all 12 or hundreds of your partners are going to use in a standard way, you can't get there with REST, because everyone does it differently.”

As Randy continued: “You can get into an argument where a REST proponent would say, 'I don't want all that complexity. But sometimes business is that complex. You can wire it together yourself using the low-level kinds of specs, but you're going to wind up putting the standards together in a proprietary way.”