Today we’re excited to kick off our “Data Point of the Week” series, a four-part blog series that will offer advice and pointers and answer questions about different data access issues.
First up: Why do we need standard-based connectivity?
Most SaaS applications like Salesforce.com expose their functionality through the Web interface to allow it to be used from any Web browser from any platform – this is how most users will connect. SaaS applications also expose their data through Web service APIs, which are proprietary APIs unique to each vendor. Salesforce.com has its own, so does NetSuite, and many others. However, there is no standardized Web service API. There is also no standardized API or language for SaaS applications, which means that each client application must be coded for each specific SaaS application.
Imagine you want to use your favorite reporting tool – one that you use regularly against your relational databases. What if you want to synchronize the data in SaaS with on-premise databases like SQL Server and Oracle? Users of your application demand best-of-breed third-party applications to access data. They are familiar with powerful reporting and analysis tools like Crystal Reports and MS Excel, and they want to use them against various data sources. Additionally, developers want to use products like Visual Studio and Java that have many capabilities for writing applications that connect to SQL-compliant databases. These third-party applications know how to connect using standards-based API and SQL data models, but they don’t necessarily know how to use proprietary APIs or file formats.
So, what can you do to solve this connectivity issue? Standard-based connectivity! It is the key to getting these different applications to “talk” to SaaS applications and data sources and effectively get the job done.