Designing a Connector Best Practices For Interfacing Your Software


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

You have identified a need for a connector within your company: but where to start? How to go about designing this connector? We take stock in this article.

  • Identify and map processes
  • Determine the data to transmit
  • Not wanting to be universal
  • Develop by iterations
  • To conclude…

Identify and map processes

For a connector to be relevant and well designed, you must first 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 have to take the time to list the business processes, the management rules, 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 performed by the users, the other tools potentially impacted… This is absolutely necessary so as not to miss an essential need or a significant side effect.

In addition, this approach maximizes the impact of the connector on users. When two tools were not previously been linked, you have to deal with the uses 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 transmit

Transmitting data above all knows its structure in order to know what is sent, on the one hand, and what is expected on the other hand.

To make good use of a connector, you have to determine which fields are important, and translate them into the format expected by the other application. We call “mapping” all of these correspondences to be determined.

For example, to transmit a contact on an application, we could have several fields corresponding to the telephone numbers: “Phone_1” and “Phone_2”.

Now imagine that on the other tool, we have “personal_phone_number” and “professional_phone_number” fields.

From then on, it will be necessary to explicitly indicate to the connector if the data of the “Phone_1” field must be synchronized with “professional_phone_number”, to be sure to find its contact file correctly filled in!

This example among others shows it: it is necessary to identify beforehand what data we need. Whatever its use, wanting to transmit everything is not an effective solution, as we will 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.

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

We imagine that transmitting everything saves time since we save thinking about the data that is useful or not. But will this time save cover the time (or budget) used to develop or configure the connector? Nothing is less sure.

In addition, a connector must be maintained regularly, since it makes the link between applications likely to evolve as well.

For example, when buying an application by a group, it is common to see the application using the authentication system of the group so that the accounts are unique. It is then necessary to modify the connector to make the change into account.

Thus, we understand the problem well: the more the connector is complex, the more the data transmitted are numerous, and the more the risks of bugs or compatibility problems increase (and therefore the costs associated with maintenance).

If you publish your own software, it may be interesting today to expose a well-documented and secure API and to link it to integration tools like Zapier via a connector, rather than bear the associated risks yourself. Connectors dedicated to each target application: we will talk about this in a future article.

Develop by iterations

In entrepreneurship as in agile methodology, the MVP (designating the “Minimum Viable Product Engineering”) is increasingly popular.

Coming from the Lean Startup methodology, the principle of 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 the identification of the first version, and this applies all the more to a connector.

Indeed, linking several platforms generally involves a technical implementation, in particular taking care of the connection to the tools or the management of any errors. If this base is relatively incompressible, the quantity of data to be transmitted, their type, the frequency, etc. is all parameters that can vary the complexity. The higher it is, the longer it will take to deliver the product, and the more it will present risks of unsuitable operation as needed.

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

Let’s add that a connector, unlike software or an application, does not need many features to be useful. It can be used from the first iteration if it has been carefully defined! So, as soon as the connector is set up, it works and starts to bring added value.

To conclude

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

Connecting applications to each other means above all wanting to improve your processes: this requires knowing them well and knowing the users well. Here we are well ahead of the technical constraints, to which we will return in a future article.

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


Please enter your comment!
Please enter your name here