Designing a connector: best practices for interfacing your software

by | 16 Sep 2021 | Web Expertise

As we saw in the last article, the proliferation of digital tools and software in companies requires these tools to be linked together by developing connectors. These connectors make it possible to synchronise data between several tools, to automate tasks, and in general, to gain in productivity and performance. 

You have identified a need for a connector in your company: but where do you start? How do you go about designing that connector? We take stock of the situation in this article.

Identify and map processes

For a connector to be relevant and well designed, it is important to take the time to identify its role within a more macro process.

For example, if you want to connect your CRM software and your invoicing software, you need to take the time to list the business processes, the management rules, and the impacts for users of this new connector.

It is therefore necessary to list all the actions and users linked to this connector, the operations that can be carried out by the users, the other tools that may be impacted, etc. This is absolutely necessary in order not to miss an essential need or an important side effect.

In addition, this approach maximises the impact of the connector on users. When two tools that were not connected are connected, it is necessary to deal with the uses that are already in place and apply the appropriate change management. Involving users from the design stage is the key to a useful and used connector.

Determine the data to be transmitted

Transmitting data means first and foremost knowing the structure of the data in order to know what is being sent on the one hand and what is expected on the other.

This data, in digital tools, is usually filled in as tables, each with fields and relationships to other tables. 

Designing a connector: best practices for interfacing your software

In order to use a connector properly, it is necessary to determine which fields are important, and translate them into the format expected by the other application. We call the set of correspondences to be determined "mapping".

For example, to transmit a contact on an application, we could have several fields corresponding to phone numbers: "Phone_1" and "Phone_2".

Now let's imagine that on the other tool we have "personnal_phone_number" and "professional_phone_number" fields. 

From then on, you must explicitly indicate to the connector whether the data in the "Phone_1" field must be synchronized with "professional_phone_number", to be sure that your contact record is correctly filled in!

This example, among others, shows that it is necessary to identify upstream what data we need. Whatever its use, wanting to transmit everything is not an effective solution, as we shall see later.

Not wanting to be universal

The "classic" pitfall when setting up a connector is to want to transmit everything, in real time, with all the components of the system.

Often, 90% of the usefulness of a connector comes from the transmission of certain well-chosen data, in precisely identified cases.  

One imagines that transmitting everything saves time, since one saves thinking about what data is useful or not. But will this time saved cover the time (or budget) used to develop or configure the connector? Nothing is less certain.

In addition, a connector needs to be maintained regularly, as it links applications that may also change.

For example, when an application is acquired by a group, it is common for the application to use the group's authentication system to make the accounts unique. It is then necessary to modify the connector to take into account the change. 

Thus, the problem is clear: the more complex the connector, the more data is transmitted, and the greater the risk of bugs or compatibility problems (and therefore the costs associated with maintenance).

If you publish your own software, it may be worthwhile today to expose a well-documented and secure API and link it to integration tools such as Zapier via a connector, rather than bearing the risks associated with dedicated connectors for each target application yourself: more on this in a future article.

Develop by iterations

In entrepreneurship as in agile methodology, the MVP (meaning "Minimum Viable Product") is increasingly popular.

Derived from the Lean Startup methodology, the principle of the MVP is to separate the final product into several batches to be produced one after the other, so that the result is viable and useful at the end of each stage. The important thing here is to identify the first version, and this applies all the more to a connector.

Indeed, linking several platforms generally implies a technical set-up, notably taking care of the connection to the tools or the management of possible errors. Although this base is relatively incompressible, the quantity of data to be transmitted, its type, frequency, etc. are all parameters that can vary the complexity. The higher the complexity, the longer it will take to deliver the product, and the greater the risk that it will not function properly.

By developing in iterations, you choose to rely on a stable and proven base each time. You start with a first iteration, and you can then choose the following developments according to the feedback from the field or the evolution of your business: the impact of your connector will therefore be maximised.

In addition, a connector, unlike software or an application, does not need many features to be useful. It can be used from the very first iteration, if it has been carefully defined! So, as soon as the connector is in place, it works and starts adding value.

To conclude...

For a connector, as for any IT development, the design phase is crucial

Connecting applications to each other is above all a question of improving processes: this requires a good knowledge of them, and of the users. This is well ahead of the technical constraints, which we will come back to in a future article.

We need to approach all the systems as a product to which we would add one or more new functionalities. This product approach, centred on the user, can be the subject of external support. Very often, having a fresh look at the processes and actors involved, enables us to better identify what could be improved, beyond a possible connector.

Florian Agator

Florian Agator

Web Design Engineer @theTribe

Why don't we talk?