In our terms, it's a service that can provide access to core data residing in the database. So what you want to do is abstract the data there into an XML format. Then you can run XQuery, for example, to do searches. Or you can do XML searches on SQL-based data. So instead of doing a native SQL call, you can make a query in XML that translates into a SQL query on the backend. So from the end user perspective it is all one native language. So they don't need to learn SQL in parallel with XML. We've abstracted the complexity away, providing one unified platform from which you can do queries independent of where the data resides. The advantage is you might have data stored in an Oracle database or [IBM] DB2. You might have data stored in SAP. You can have an Oracle application or any other custom app and each interface is different for how you extract data out of that system. Imagine the complexity. If you have hundreds of systems you have to know each native format for the data, but if it is abstracted to a common XML layer and then you are only programming to that layer, and the platform takes care of native interfaces for queries, then you've taken away a lot of the complexity of pulling information from these heterogeneous systems. That's our definition of what a data service is. So how did you develop your strategy for the data integration suite?
As we see more of our customers adopt SOA, they're quickly realizing that it's great to service-enable the infrastructure, but in automating more processes and connecting more systems the value of data is becoming more prominent. As I automate a process, I also tie it in with the underlying data. Without information, without data, the promise of service automation is not truly realized. But there wasn't a product in the market that addressed that. So what you would do is buy the SOA platform, but then you would have to go back and buy separate technology for data integration, and those two products were not integrated, so you had two efforts going without synchronization between the two. You'd have to do custom programming, custom code to really tie the two together and benefit from this automation. So Oracle set out to solve this problem?
Being Oracle and having this background in information and data management, we realized what our customers really needed was a unified, integrated platform for both data and SOA. The first entry for that is the data integration suite. What does the suite do for SOA developers?
What it really does is as you're automating your processes, as you're service enabling your infrastructure, you have an integrated platform so you can do data transfer and data integration. You can also bring data into this new SOA infrastructure. You can expose data as a service. Now, I can tie that into an end-to-end SOA process. Do you have an example of how that would work?
For example, in an order-to-cash process, I can have a step in the process that says do this transfer from database A to database B, and then you can go on to the next step. Versus having to call up another database process, go into an entirely different toolset to make that data transfer happen. What about cases where you have data coming from a lot of different sources?
In this announcement, we really make it clear that our technology works across heterogeneous systems. It doesn't matter where the data is residing. It can be residing in an IBM DB2 database. It can reside in MySQL, Microsoft SQL Server. We have an OEM partnership with Teradata [Corp.]. With any kind of system, including Oracle, you can do the data transfers, but the neat thing about it is it doesn't even require an Oracle database. So if you have an infrastructure that is independent of Oracle, it will still work. It is truly heterogeneous. We have over 200 customers who are actively using this core technology in the market today and a large percentage of them are not utilizing the Oracle database.
Absolutely. We have adapters that connect to that and can pull data into the system. It can expose that data in a standard XML format. We can do queries into it. We can do data transfers into it. It is completely heterogeneous and hot plug-able. It can connect with any system using any backend technology and expose it in a standardized fashion and then run queries on top of that. So even if the system was created in the 1970s, you can get to it?
We definitely can. There are customers with IBM mainframe COBOL systems and they don't want to move off of it. They find value in it. They've invested a lot in it, but they want to bring that infrastructure into the mainstream, into the next generation infrastructure. So how do you do that? We actually have adapters that connect to the COBOL system, do the translation from COBOL to XML and then we bring it into the SOA mainstream.