4 Innovation Myths Holding Back Enterprise Companies from Building New Integrations with their Applications

Eugene Khazin

Principal and Co-Founder, Prime TSR

Like most new technology concepts, APIs have gone from “new kid on the block” to industry standard for building software applications. As the key means for sharing data among disparate applications, the practical applications and benefits of building enterprise application integrations are everywhere – from online restaurant reservations to electronic payments to real-time inventory management for online retailers.

Yet, despite the fact that many enterprises are integrating with external applications, some CIO’s are still reluctant to adopt interfacing with external systems. Here is the truth behind some common misconceptions that may be holding them back from benefiting from the enterprise-ready integrations and API’s available to them.

But, First - Why Do We Need Enterprise Application Integration?

Enterprise application integration enables companies to pass data securely and efficiently from one system to another. This allows them to build powerful applications without the need to re-build the original service from the ground-up. More companies are adopting integrations with their systems, even with external systems because this is helping them build more powerful systems in much less time and resources. 

Here are the 4 misconceptions that are holding CIO’s back from utilizing services from external technology systems.

1. APIs are limited to only one area of my business

APIs can be applied to different areas of a company without the need to build from scratch. With pre-built integration templates and workflows, a business unit or department can use the same database or company data of an existing API and repurpose it based on their specific requirements. Using the same inputs, these API libraries become the framework for producing different outputs.

For example, a company may build an API to manage online marketing strategy using consumer behavior data gathered from its marketing analytics system. The assets stored in this API library can then be reused or fragmented to produce different information needed for the purchasing department. In other words, the API library may be broken down in for marketing purposes as 3+2, while the same data may be reused for the needs of the purchasing department as 1+1+1+1+1.

2. APIs are singular in nature or application-specific

In first generation APIs, web services would provide or pipeline the data based on a single application requirement. Today, the same API can be used again and again for multiple functions without having to modify the application, and without burdening the application team. These modern APIs can produce different data styles and formats based on customer needs, essentially doing the same amount of work with one API that formerly required multiple APIs.

We can think of this in the same way we think of color printer technology. We do not need separate printers to print a document in varying colors. Rather, a standard color printer will combine proportions of three standard ink colors – cyan, magenta and yellow – to produce a wide range of colors from the same printer. Likewise, a single API can facilitate different application needs by pulling different assets from server-side repositories.


3. APIs can only be accessed or modified by API developers

In the past, APIs that were developed to run continuously did not allow other users to touch any code. Users were able to unlock data, but access and management of the data was limited to the specific data teams.

That changed with the introduction of “Anypoint Exchange,” which promotes user interaction and modifications and allows a single API to be used by multiple users. With an “API Key”, users no longer need to wait for the API developer to make application changes. Instead, the Anypoint Exchange allows users to access proven assets – connectors, templates, examples and RAMLs – from the repository center and add to or reuse them without harming or altering the application.

4. Every API change requires hardcode development /downtime

Imagine being able to change your car’s oil while the vehicle is in motion. Although not a reality for cars (yet), this is the standard for APIs. Unlike legacy APIs, which required hard coding development and thus significant downtime with every modification, modern APIs do not keep hard-coded features. Rather than building new API stored procedures, SQL syntax or other formatting every time there is an application change, modern APIs can pull stored-procedures or stored templates from different repositories without stopping the application. Similar to replacing multiple TV remotes with one, universal remote, this high-level automation essentially allows one API to do the work of multiple APIs.

Like many emerging technologies for the enterprise, integrating with external applications, specifically, API technology has rapidly improved. With streamlined functionality for business integration, versatility, user access and automation, now is the time to reconsider an API strategy in order to modernize and optimize your business applications.