The seductive promise of service-oriented architecture (SOA), through which businesses can transmogrify monolithic enterprise applications, making them highly responsive to organisational needs, has been embraced enthusiastically by IT users and vendors alike. But it is a very application-centric vision, and one that comes with some potentially ruinous pitfalls.
One such obstacle is data. Within a service-oriented architecture, business processes can be automated by aggregating the necessary components from any number of applications to build services. When that business process alters, the services can be reconfigured on the fly. Much of the work that has thus far gone into SOA has been in readying applications for this paradigm. However, these legacy enterprise applications have traditionally been welded to their own ‘silo’ databases and data models.
Historically, the advantage of this approach is that applications can use database-specific logic for managing data – including its creation, updating, deleting and access. But in an SOA environment, data may be associated with different applications and processes, a situation that introduces the possibility of inconsistencies between data models.
“While conventional SOA resolves the spaghetti that most application architectures look like,” says Philip Howard, an analyst at IT advisory group Bloor Research, “it is equally valid to attempt to unravel the Gordian knot that represents data architectures, and to do the two in concert: this is what data services is all about.”
The concept of data services (arguably, the twin of web services) is fast gaining traction as an approach for ensuring that the data challenges within SOA are adequately addressed. According to middleware maker BEA Systems, as much as 70% of application development time can be spent accessing disparate data – making the need for some form of data services layer critical for an SOA implementation. Traditional extract, transform and load tools can be cumbersome and ill-suited to the demands of a responsive SOA environment, something that has prompted vendors to develop alternatives.
Full services
The potential of this market is already attracting some heavyweight vendors. IBM’s Global Services arm is touting its ‘Information-as-a-Service’ offering as a blueprint for incorporating data integration and master data management within an SOA, drawing on its WebSphere and Rational software lines.
Australasian credit checking company Vera Advantage is using IBM’s Information Server to cleanse, transform and consolidate data into a master version from 3,000 of its suppliers. This service-oriented approach has reduced Vera’s operating costs and improved integration with its customers’ back-end systems.
Other companies have used data integration software to enhance executives’ understanding of business performance. At pharmaceuticals giant Pfizer, data integration software from BEA Systems has been used to collate data from its enterprise applications, to build a management dashboard. It has also introduced data services to improve expense management systems, providing a consistent way to track project costs across the business.
Data services allow existing applications to access data irrespective of where it lives and whether that data store has been ‘SOA-enabled’. But not all companies will choose to implement such a full data services layer. The US-based broadcaster Fox Network Group has opted for database connectivity software from integration specialist DataDirect to provide a fast, flexible and secure method for applications to access data within its SOA environment.
A standards-based API for database connectivity, whether that uses ADO.NET, as is the case at Fox, or the ODBC or JDBC database connectivity standards, provides businesses with a consistent approach to dealing with disparate data sources, says Mark Troester, product marketing manager at DataDirect. “Generally, we are not a big proponent of a wholesale re-architecting of data or creating a heavy data services layer,” he adds.
But whether business leaders opt for a complete data services layer or a database connectivity approach, the movement of data within a service-oriented architecture is likely to become increasingly important.The work on developing an SOA – which has become central to many IT leaders’ plans to deliver business value – depends on solid data foundations. Loosely coupled applications must still maintain an unbreakable yet fluid link with underlying data if they are to realise that value.
Further reading in Information Age
Also from the March 2007 issue:
Structural hazard – The pitfalls of SOA design and implementation
More articles can be found in the SOA Briefing Room