Just Say No to Proprietary APIs

Information Management Magazine, August 2007

Dipak Patel

Integration is the watchword in today's business organizations. Customer relationship management (CRM) applications strive to consolidate customer information from multiple IT systems, business intelligence (BI) applications strive to present cohesive views of entire organizations across IT platforms and supply chain management applications strive to integrate systems between IT environments within numerous disparate organizations. Web services and service-oriented architecture (SOA) are seeing rapid adoption in large part due to their ability to free business logic from bondage to specific back-end sources of data and transaction processing.

Enabling this "urge to merge" and helping to spur it on are application program interfaces (APIs) based on widely used industry standards such as ODBC, JDBC and ADO.NET. Nothing will toss a monkey wrench into an integration effort as completely as will the use of proprietary APIs. Business organizations running applications that use proprietary APIs typically take one of two approaches: they either undertake major development expenditures to effect integration or else they target those particular irksome applications for replacement with more standardized applications. Either solution is bad news for the bottom line.

The latter solution is also bad news if your organization happens to be an independent software vendor (ISV) marketing one of those targeted applications. If so, you are undoubtedly aware that more users want access to data from your application using third-party tools. For example, business organizations architecting comprehensive BI environments might wish to use popular reporting and analysis tools from Business Objects (Crystal Reports), or Cognos or Microsoft Excel. Developers might wish to use products such as Visual Studio and Java SDKs that have many capabilities for writing applications that connect to SQL-compliant databases. These third-party applications know how to connect using standards-based APIs and the SQL data model. They do not know how to use your proprietary API or file formats. The inclusion of standards-based APIs included with major commercial databases such as Oracle, for example, are what allow the aforementioned BI products - and scores of others - to operate on a plug-and-play basis in an organization that relies on the Oracle platform.

If your application uses a proprietary API, your customer can enlist its IT development staff to write extensions to your application that extend it to include the more powerful reporting or analytical functioning desired. Or they can contract your company to do it. Either way, it is an expensive and time-consuming proposition. It is much more economical to integrate a third-party reporting and/or analysis application. And, of course, if that third-party application can tie in numerous other applications into an overall BI solution, all the better. With ISVs offering products head-to-head with yours but including standard APIs, your product is likely to rise high on that replacement hit list, as well as lose value in the eyes of systems architects planning new infrastructure.

Standardized APIs also make it much easier for an organization to add security logic between the application accessing data and the data source - a usual requirement when a new means of accessing corporate data is made available. Modifying the middleware is sufficient for applications and databases using standardized APIs; those using proprietary APIs, however, must be modified and tested specifically. This is one reason that many heavily regulated industry verticals - such as energy and financial markets - are required to use applications that can claim to have an open interface. In most cases, a standards-based API meets that requirement.

However, standards-based APIs are not just for commercial relational database management systems. Data connectivity leaders provide tools that enable users to cost-effectively layer the API or data with a standards-based API.

How Not to Do It versus How to Do It

Even if your organization has decided (or has been compelled) to adopt standards-based APIs, you may have good reasons to keep the applications currently using proprietary APIs. They may be homegrown applications representing a large investment in time and resources, or they may be so intricately ensconced in your overall systems environment that their replacement would be costly and disruptive to mission-critical operations. If your company is an ISV, of course, you have a vested interest in making your existing products more open in order to expand their market.

Your organization could take on the effort of writing, say, an ODBC-driver component that fully complies with the specifications, for example. However, the effort and expense of taking this approach will nearly always outweigh the benefits. A much better approach is to license a third-party software development kit explicitly designed to create standards-based APIs over any type of data source. This approach can essentially give you as much as 99 percent of the code already completed: the extensive driver API specification compliance, the SQL calls, and the network and server components necessary.

The best-of-breed API SDKs available have the ability to make anything - flat file data, proprietary data or a Web site - appear as a SQL database that application tools based on standard APIs know how to talk to. Such SDKs contain prebuilt components that implement the driver APIs. This code exposes the required APIs and interfaces and implements all the rules defined by the respective specification for various OS platforms.

A truly comprehensive SDK will also include a SQL engine with support for ANSI SQL92 and be capable of efficiently executing queries over any type of data store; this interfaces with the code your development staff supplies to access your particular data source.

Finally, the SDK should include the network communications components to allow deployment of a client/server configuration where the SQL engine runs as a server process on the particular OS platform supported . There is a need for the SDK to have high performance and for it to support Unicode. The high performance is required to allow the standards-based API to be able to be comparable to the proprietary API in terms of data access speed and scalability. Unicode is required in order to meet today's demand for internationalized applications.

Page 1 of 2.