APIs are the lifeblood of software – and can be for your firm

APIs are the lifeblood of software. It is challenging to enable standard connectivity methods across software systems without them.

A non-technical way to think of APIs that applies to personal lives: you’re building a new house. You want to take on the role of a general contractor yourself. You work with architects, plumbers, electricians, painters, framers, retailers, and a myriad of other sub-contractors to build your dream home. The “interface” – the I in APIs – are the contractors. You interface with them all to build your dream home. APIs in software code is a similar concept.

An API at its core (per Wikipedia): “a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.” They are standard interfaces that allow connectivity and data to be exchanged. You chain them together in an application.

Not everyone has heard of APIs, though most have heard of that buzzword integration. Everyone talks about how integrated their solutions are and how much more efficient an integrated system is.

It might surprise you to know APIs exist in near every modern software product. There are generally 2 notions of APIs.

1: Private or “Internal” APIs.

These are used by Independent Software Vendors (ISVs) to provide internal developers private access to integrate to systems, data, and software. They can be quite broad as well as fine grained to enable a wide range of use cases. Broad access to application and company resources is enabled via role-based access control and other methods.

2: Public APIs.

These are used by Independent Software Vendors (ISVs) to provide external-to-the-ISV developers with controlled access to data and services for a given application or set of applications. Generally, they are subject to versioning, deprecation, and governance policies to ensure optimized customer experiences and flexibility.

The second notion allows scenarios such as CCH Axcess integration to scheduling software, or expense reporting software, or CRMs. Think of enabling the ability to seamlessly import data to tax returns from an external system, to export data from returns to an external system, to extract e-File history information for processing in business intelligence tools.

Questions to ask your technology vendors about their API policy.

When you are considering new technology expenditures, add APIs to your Q&A list. Ask vendors:

1. What APIs are available “publicly”, with what governance policies, on what marketplaces.
2. Where to find content that will aid in development.
3. How to obtain support policies.
4. What their data projection policy is.

Data projection policies are particularly important. It is our policy in Wolters Kluwer that the data in your systems belongs to you. You should be able to use it freely, not feel as though your choices are limited to a select number of vendors because one of your systems has a closed API policy.

Only when you, the consumer, demands access to use your data in any manner that you wish will more vendors support open API.