Just say no to proprietary APIs

CRM applications strive to consolidate customer information from multiple IT systems, business intelligence, applications strive to present cohesive views of entire organisations across IT platforms, and supply chain management applications strive to integrate systems between IT environments within numerous disparate organisations. Web services and software oriented architecture 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’ are application program interfaces (APIs) based on industry standards such as ODBC, JDBC, and ADO.NET. Businesses 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 standardised applications. Both are bad news for users’ bottom lines. The latter is also bad news if an organisation is an ISV marketing one of those targeted applications. The ISV will undoubtedly be aware that more users want access to data from its application using third-party tools.

Standardised APIs make it easier for organisations to add security logic between the application accessing data and the data source. Modifying the middleware is sufficient for applications and databases using standardised APIs; those using proprietary APIs, however, must each 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.

ISVs have a vested interest in making their existing products more open in order to expand their market. They could take on the effort of writing an ODBC driver component that fully complies with the specifications. 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 designed to create standards-based APIs over any type of data source.

The best-of-breed API SDKs available have the ability to make anything — flat file data, proprietary data, or a website — appear as a SQL database that application tools based on standard APIs know how to talk to. Development effort consists strictly of writing code which is independent of the driver they are creating, the platform they will run on, or whether it is a single tier or a client/server implementation.

If they want to include such applications in BI or CRM solutions that employ best-of-breed third-party applications, if they want to add OTS reporting or analytical functionality to those applications, if they want to leverage those applications to gain the advantages that SOA can provide in securely integrating IT functionality across the enterprise and beyond, an API SDK could be the solution.