As we have seen in two previous articles(here and here), developing bridges between software or applications is often necessary to gain in reliability and automate processes. If asking the right questions upstream is an essential first step, then comes the technical question. Native integrations, nocode tools, custom connectors... Let's take a look at the solutions available to you.
- Designing a connector: constraints to be taken into account
- Solution 1: Market extensions
- Solution 2: "nocode" integration platforms
- Solution 3: the development of customised connectors
- Hybrid solutions
- Migration scripts
- Making the most of existing tools
Designing a connector: constraints to be taken into account
To connect applications to each other, you must first be able to communicate with them.
This communication can be done in different ways: XML feeds, APIs, webhooks (events sent on a url), etc.
While there are many ways to do this, at least one of these ways must exist and be able to transmit the necessary data to your connector.
If you are a software publisher, this may require you to design your platform around this need (micro-service architecture rather than monolithic, etc.), or to develop the necessary building blocks.
If you are using an online application or software, you may or may not have access to the APIs of that application, or to the integrations that already exist: depending on the tool itself (does it offer an API or integrations?), on your subscription, or even on the type of hosting you choose (on the publisher's infrastructure or on your own server).
It is fundamental to make an initial study of your environment in order to choose the right technical solution and/or implement the right actions.
Unfortunately, this phase may result in the impossibility of realising the connector. But we must not forget that the web is a constantly evolving ecosystem: today's truth is not tomorrow's truth and the initial design will not be lost.
By looking at the technical constraints, it is also possible to discover roundabout ways of addressing the need temporarily while waiting for planned developments. This study can also highlight the inadequacy of the tool with your needs: if the connector is necessary for your activity, and the tool does not allow it, then it is not necessarily the right tool for your company.
However, we reassure you: more and more publishers have long understood that it is in their interest to open up their platform to the outside world, and new technologies and development methods simplify the task: the days when you could only communicate with software by exporting flat files during the night are long gone!
Solution 1: Market extensions
Today, with the growing demand for interconnection, many platforms offer their own marketplace of extensions (or integrations, as the case may be). Your accounting software or your CRM probably offers "standard" connectors with partner software.
Screenshot: the marketplace Hubspot
Some connectors are developed and maintained by the publisher itself, others by third parties. Some companies have even specialised in developing these extensions for certain tools.
Rather than considering custom development, such extensions can be very relevant if they cover the identified need. Some of them have several years of existence and therefore improvements, an adapted support, and a versatility allowing to work by iterations.
From a budgetary point of view, many of these services operate on a subscription basis, with the price depending on the number of users. If the entry price is lower than a custom development, we recommend that you make the projection over several years, according to your projected growth, to choose the best solution.
However, most of these extensions require a considerable amount of time for configuration and testing, which is a consequence of their versatility: they must be adapted to your own needs.
If your CRM software offers a standard connector with your accounting software, this is good news, but beware: check that this connector covers your needs, as sometimes the functionality covered is limited!
For example, at the time of writing this article, the connector between Hubspot CRM and Quickbooks accounting software allows invoices to be created directly in Hubspot and transmitted to Quickbooks, but it does not allow invoices created in Quickbooks to be viewed in Hubspot... which does not meet all needs.
Solution 2: "nocode" integration platforms
No-code" is on the rise: applications that do not require development in the traditional sense (writing source code, etc.) are called "no-code"Applications that do not require development in the traditional sense of the term (writing source code etc.) are called
Numerous nocode platforms now make it possible to create tools in a few days from more or less macro bricks, already coded and requiring only assembly and configuration.
For the development of a connector, there are some particularly interesting no-code tools dedicated to the integration of applications.
These connectors usually work on the trigger principle:
- An event is issued in an application 1 (e.g. receipt of an order)
- This will lead to an action in an application 2 (e.g. sending an email to the customer)
- And another action in an application 3 (e.g. creation of a master record in ERP).
Capture from Zapier
Each software or application on these platforms offers a limited number of triggers and actions, which you can "play with" to create your own custom connectors.
These services of course have a cost, which may depend on the number of users, the number of events, the number of connectors set up.
They do not necessarily work in real time.
Moreover, despite an increasingly comprehensive catalogue, not all tools are available on Zapier or Integromat.
And for a given tool, it is important to study the possibilities offered by the integration in order to know if it meets your needs.
Finally, it should be added that these integration platforms are not the most suitable if you need bi-directional data exchanges between two applications: you are not totally safe from certain risks, such as the creation of duplicates or the overwriting of sensitive historical data.
However, no-code integration platforms are an excellent compromise for testing the relevance of a connector before considering custom development, or for linking widely used tools by following simple processes.
Here too, configuration and testing time is required, and iteration is possible: you can link several applications within the same process, and upgrade your integration at any time...
Solution 3: the development of customised connectors
Developing a custom connector involves creating a web application from scratch, allowing the transmission of data and instructions between two platforms. This involves setting up a suitable hosting facility, and the cost of entry is relatively high.
But it is the solution that offers the most flexibility and impact: we will develop exactly what you need, instead of using an existing tool to make it best fit your request.
It is also the most relevant solution in the long term: the technical basis allows you to iterate endlessly, without being limited by a tool, while remaining the owner of your data and controlling all the elements of the chain. Here, you are not dependent on another company which tomorrow could make choices that could put you at risk, or even cease its activity
Few companies, even software publishers, carry out this type of development themselves. The company's developers concentrate on the product roadmap, and the development of the connector can be carried out in parallel by external teams with complementary expertise, experienced in this type of exercise.
The technical requirements are less stringent here, since the customised service can use any type of communication with your platform, and it chooses its own hosting.
On the other hand, with applications on the market, it is always necessary to monitor whether or not there are APIs, for example, and whether they are versioned and secure.
Since each solution has its advantages and disadvantages, it is not out of the question to use them in a complementary way!
A publisher, for example, can start by setting up a connector between its product and an integrator like Zapier, so that its platform is integrated with as much of the market as possible.
He can then choose to create a dedicated connector to a solution like Hubspot, which aims to be the hub of enterprise ecosystems. This will de facto make his product connected to all Hubspot applications (which is called the Operation Hub), and this opens up a huge market.
For any connector project, moving forward in stages can be a good bet. Launching a custom development takes time: in the meantime, you can test an existing solution that partially covers your need. If the return on investment is positive, this may even allow you to restrict the scope (and therefore the cost) of the MVP developed!
This solution is a special case.
Sometimes you don't need a full-featured tool, allowing real-time synchronisation or reaction to events, but only to transmit data from one application to another, in a "one shot ". This is the case, for example, when you change software and you want to find your history in the new tool.
On the other hand, it is necessary to be able to translate and transfer all the data, dealing with special cases at the margin.
Therefore, a script (a set of lines of code that run on a one-off, non-continuous basis) may be relevant, as it is less costly to set up than a connector, and allows each case to be handled precisely.
A script is in essence custom development. It will not have a graphical interface to map each field, but neither will it require a subscription or hosting.
Indeed, the scripts are primarily concerned with translating data, between an export and an import procedure. This data is exported as a CSV file on most tools. The processing can therefore even be carried out within a spreadsheet.
Some software packages offer built-in migration tools. But in any case, whatever solution you choose for your data migration needs, design is central, as no case should be overlooked.
Making the most of existing tools
Many tools now offer import/export functions, native integration with other tools, automation accessible through parameterisation, etc.
Before considering major developments or the implementation of a new tool, we advise you to take the time to explore these configuration possibilities, even if it means being accompanied by a specialist agency.
Many automations can be made from an office suite, and even from a single spreadsheet, to cover the needs that have the greatest impact!