Integration Templates vs. Integrations

Building embedded integrations is different from building a one-time use (sometimes called "bespoke") integration.

Embedded integrations are meant to provide a consistent data integration experience between two software products for a cohort of end customers. To the extent that business requirements will allow, that integration should work the same for each end customer that uses it. This is how you can scale to hundreds or thousands of users on an integration without having to scale your operations team as fast as the adoption.

However, while an integration is typically mostly the same from end customer to end customer, there will always be configration points that must be provided. The very simplest configuration point that must be provided is for the end customer to enter their specific credentials to the integrated system. In reality, they probably need to configure or customize beyond just their credentials.

Common points of configurability required by embedded integrations are:

• Mapping custom fields into/out of the external system
• Cross referencing data values or codes that are otherwise incompatible
• Establishing common identifiers for records that traverse both systems
• Filling in gaps of fundamental data incompatibility that simply require the user to decide how to map

Thus, when building an embedded integration, an engineer is actually building an integration template. In other words, they are building an integration that has intentionally defined gaps to be filled in later by an end customer. This is the only way to build integrations that can be used by many users and can be managed at scale.

Building integration templates, instead of bespoke integrations, means you add a lot more customer value per integration project. However, it opens up the engineer to the following additional challenges:

• You need to design for and test multiple scenarios within your integration
• You need to consider the end user's experience providing those configurations--if set up is too hard, it'll impact adoption
• Deployment is now more difficult, because it involves merging shared functionality with unique user-provided configurations
• Monitoring and maintenance are harder, because every customer's integration is somewhat unique

Integration templates are harder to build than one-off integrations, but they have the potential to provide exponentially more value. Doohickey is built to help product engineering teams take advantage of this value opportunity, while maintaining responsible engineering practices and reducing risk.