A few months ago, we received an all-too-common chat through the website. The woman contacting us was charged with heading up the integration project for her company. As we chatted back and forth, I discovered that she was in fact a marketer, like myself, and had very little knowledge of what was needed or how to even go about starting the project.
If you’re a CTO or you work in an IT department, you probably have a firm grasp on many of the terms associated with integration. However, sometimes department managers in marketing and sales roles are asked to spearhead integration projects. When the integration provider asks questions or explains common integration scenarios, it may sound like a foreign language. There are many nuances of integration, but for a start, let’s get familiar with some basic integration terms.
- API – The term API is an acronym for Application Programming Interface. When you’re integrating two software solutions together, you’re using their API’s to connect the data points. The API interface maps out the software structures and uses definitions and protocols to allow the solutions to communicate over the internet. In short, each application has a set of rules that says “Here is how to access the data and what data you can access.”
- Connector – Integration solutions such as iPaaS (integration platform as a service) usually have a large number of connectors to choose from. The idea of the connectors is that all the programming required to connect to an application through their API is packaged up into a connector for quick and easy access. If you were going to have a developer write an integration from scratch, they would have to write all the API call outs for each system they are connecting to. In a connector, all of that work is done for you for multiple systems. A connector is kind of what it sounds like: it is the software used to create a data connection. Sometimes called “middleware”, connectors are what enables the API’s to connect to the software. For example, if you’re trying to integrate Creatio CRM with QuickBooks, you’ll need a connector that can read the API of each solution and tell them how to interact.
- Data Cleansing - When you start your integration project, your integrator may ask if you’ve cleansed your data. Just as you spring clean your closet to get rid of the hideous sweaters you never wear, you must also clean and standardize your data to remove duplicates, invalid or incomplete information, and other junk from the database. This ensures that when you do integrate, everything being passed between the systems is accurate and up-to-date. Otherwise, you’ll be pulling analytics that aren’t a true representation of your business and perpetuating a problem you have that needs to be resolved.
- Data Governance – It’s important to know whether or not your company has a data governance plan in place before beginning an integration project. Data governance rules manage all aspects of data in a system, from the availability of that data to the usability, integrity, security, and storage. It is important to know in advance if your organization has such plans in place prior to starting your integration project. If not, perhaps now is the time to consider implementing some.
- Data Lake – Data lakes are kind of like storage facilities for data that doesn’t have a purpose yet. It’s a repository that holds large quantities of raw data in its native form until it’s ready to be used. If your business uses data lakes, it may be a factor in your integration process.
- Data Mapping – Data mapping is a big part of integration. It’s when you match the fields from one database to another. Oftentimes, systems will define similar types of fields using different terminology. For example, let’s say we were trying to connect HubSpot marketing automation with SugarCRM. If we wanted the account information to be shared between each system, we’d need to map the “Accounts” from SugarCRM to the “Companies” in HubSpot. In essence, these fields are the same, but they are labeled differently in each solution. If we don’t use maps to direct the data where to go, the integration won’t work as we desire. The great thing about comprehensive integration solutions is they also allow you to change or transform your data as it moves from system to system. Some systems have a different data format, others you may need to completely change the actual data, maybe it is “Client” in one system but “Customer” in the other. Integration solutions with that flexibility offer you options that fit your needs exactly, you don’t have to change the way you do business to adapt.
- Data Warehouse – A data warehouse is a bit like a data lake, but the data within it is structured, not raw like that of a data lake. It’s a central repository that stores archived data from various sources.
- ETL – You may have noticed this term right in the StarfishETL name. The acronym ETL stands for Extract, Transform, Load. It’s the process databases use to extract data from a source, transform that data into a necessary format, and then load it into a new solution. ETL is one of the most popular and trusted forms of integration.
- iPaaS – You’ve probably heard of SaaS at this point, so what the heck is iPaaS? Integration Platform as a Service defines the suite of cloud services that enable integration flows to be developed, executed, and governed. These integration flows can manifest through any combination of on-premises or cloud-based processes or applications. StarfishETL uses iPaaS technology to make our integrations scalable and easy to adapt for any business solution.
- Legacy Software – Your integration partner may ask you if you’re integrating any legacy software. All that means is that the software is old or outdated. Think of legacy software like a 2001 flip phone, whereas newer, fully supported software would be more like an iPhone. Legacy software is often on-premises (installed locally in your business).
- SQL – Structured Query Language is the most widely used programming language for relational databases. When it comes to integration, SQL is used to write data integration scripts and run analytical queries.
- Service Level Agreement – Also referred to as an SLA, a service level agreement is a contract between the customer and the service provider that defines which services the customer can expect to receive during the integration project.
- Webhook – A webhook serves a similar purpose as an API does, but the two are used in different instances. An API will perform an action when you tell it to, whereas with a webhook, an action will be triggered when certain criteria are met.