User Review
( votes)Look at the successful enterprises around you. Don’t they all depend heavily on underlying software applications? The problem is that, as time goes by, enterprises invariably end up with software created with disparate technologies and built by several vendors.
The number of software applications varies according to the size of the organization. According to our research, small businesses use an average of 22 applications, and in large enterprises, this number rises to an amazing 788 software applications!
The Motivation for Software Integration
All these disparate software applications often need to work together, and this is where software integration comes in. I see various motivations for software integration when I talk to business owners and IT managers. They usually want to achieve one of the following:
- Produce a unified set of functionalities, for example, a unified customer support system
- Increase productivity by reducing the need to switch between applications
- Have easier user adoption, especially if one of the software applications being integrated is new
- Enable data analytics by getting data from multiple sources
- Automate data entry – getting data from another application is less costly than manual data entry
In the early stages of software integration, one of the main issues would be that everything was proprietary and closed. You would buy an application, and all the information you put in it was accessible only from within that application. Not to mention that often it would be available on a single machine or on a limited set of machines. If you wanted to, for example, access that information from another software application, you were into trouble.
But when there is a will, there is a way, and so software integration started. The software integration challenges were initially addressed by implementing in-house integration solutions that used ad hoc and proprietary protocols themselves.
Eventually, with the addition of more and more software systems and the wider spread of internal and external networks, home-grown solutions were no longer adequate. Software integration evolution had reached a new level. The motto “no system is an island” became common, but there was still no standard solution to the problem.
Software Integration Evolution from RPCs to APIs
Over several decades, enterprise integration technologies leveraged one or more integration styles. The earliest integration style was the Remote Procedure Call (RPC) style, used in single-language environments and very popular in the 80s and early 90s. Later, multi-language systems such as CORBA appeared. In these, an explicit Interface Definition Language (IDL) was used, so that the caller and callee could be implemented in different programming languages and even different platforms.
In the end, the use of Application Programming Interfaces, best known as APIs, became the rule. APIs emerged to expose business functionalities provided by one application to other applications. APIs exist so you can reuse them – the concept has been, from the beginning, that multiple applications could consume the same API. The idea was that developers could rely solely on the API to access an application’s functionality without worrying about their implementation details.
What Is API Management and Why You Need It
When developers start using an API, they hope that the API is a contract that will not change. However, APIs are susceptible to the same environmental pressures to change that all software systems face. They are often upgraded, reworked, and sometimes refactored. When this happens, finding actual points of change in the API and making things work again is painstaking work for the developer. This is why API lifecycle management appeared.
Developers also hope they will have to work with as few APIs as possible. This is because each new API represents a new learning curve and involves time and effort. Moreover, when you come across the upgrade problems we mentioned, the developer knows it will help to have few APIs and few inter-dependencies.
The thing is that this is not always up to the developer, as the need to integrate different software systems grows.
This is what API management is: API lifecycle management for multiple APIs.
As a result of sheer demand, API management using middleware has emerged as a way of using APIs and getting their advantages, while avoiding their known problems. Please note we are looking at API management from the API consumer perspective. If you look at it as an API producer, then the focus will be different.
API Management Tools – An Example
Connect Bridge is one such middleware that has eliminated the need to call APIs directly. Instead, it uses its connectors to translate standard SQL syntax in your code (1) (2) into API calls (3). These calls retrieve the needed information from the target system (4). This can work for retrieving data (SELECT) or to input/change it (INSERT, UPDATE, DELETE).
The middleware acts as a translator that speaks all the API variants the developer needs, translating them into ANSI standard SQL syntax that the developer knows well and can use together with his favorite programming language, such as Python, Java, or C#, just to name a few.
By using such translating middleware, the developer no longer needs to learn a new programming language or gain expertise in the target system API. This makes all the difference, dramatically reducing the time and effort necessary to integrate software.
Using Connect Bridge, the developer has two options:
- he can build his own custom integration software in the programming language of his choice or
- he can start from the source code of any software from the past 40 years.
In both cases, completing the integration will require few lines of code and be quite straightforward.
Using such middleware also eliminates the need to redo your code when you upgrade the target system or its APIs. The middleware company itself will handle all the maintenance efforts. It is now their job to guarantee forward compatibility (and sometimes backward compatibility too).
Ultimately, API management gives enterprises greater flexibility by enabling them to go for the software integrations they need while shielding them from the negative aspects and not compromising on security, e.g. maintaining GDPR compliance.
Summary
Software integration has long been a pain point for businesses, often leading companies to either maintain their legacy systems for longer than they should or fork over large sums of money on developers to migrate to the latest and greatest.
Fortunately, with software integration evolution, software integration no longer needs to be dreaded as it once was. You can easily solve current integration challenges and prepare companies for the future by using today’s technology of API management middleware. Whether to simply share data between systems, to modernize legacy systems, or to meet complex requirements, endless integration possibilities are at your fingertips once you start using API middleware.
Do you have some questions you would like answered? Are you curious to see Connect Bridge in action? We’re happy to arrange a quick web meeting to show you around or simply talk over e-mail or phone.
By Ana Neto
Software engineer since 1997, she is now a technical advisor for Connecting Software.
Connecting Software is a producer of integration and synchronization software solutions since 2004. We operate globally, and we are also a proud “Top Member” and “Top Blogger” at CRMSoftwareBlog.
Links and References
How to Use CRM Integration to Your Advantage – Real World Examples
How to Sync On-prem Database to Dynamics 365 Online
Integration Design Patterns for Dynamics 365
The post Software Integration Evolution: Challenges of the Past, Present, and Future appeared first on CRM Software Blog | Dynamics 365.
