Anyone who’s bought consumer electronics understands the confusion of trying to compare features and specs that you only half-understand in the first place. Even researching which TV to get now requires a technical dictionary to discern between the different versions of “HD perfection,” audio setups, and smart configurations.
Folks looking for business software can face just as much of an uphill tech jargon battle. In order to help translate the terminology that buyers find in Integration Platform as a Service (iPaaS) product descriptions and vendor sites, here are some of the features and concepts that tend to cause buyer confusion. In an effort to help you focus on what matters, we also discuss which iPaaS buzzwords you should care about as buyers and why
Multi-tenancy is a core feature of what differentiates iPaaS from other integration solutions. Broadly speaking, multi-tenant architecture is when multiple users/customers use a single instance of a software simultaneously. For iPaaS, it means multiple clients or users use the same platform instance which the vendor hosts. Rather than buyers hosting the platform themselves, they simply access a vendor-hosted platform.
What It Means for Buyers: If you’re deciding whether you need an iPaaS at all, multi-tenant architecture can matter a lot. Multi-tenancy is core to the value proposition of iPaaS as a whole, as it more or less outsources much of the integration burden from your IT team because the vendor handles maintenance and hardware upkeep. It also keeps costs lower because you don’t have to buy and manage the integration infrastructure, just the end data.
Batch vs. Real-Time Integration
Batch and real-time integration refer to the frequency of integration events occurring, or how often data is transferred between sources on the platform. “Batch integration” is when data is collected from incoming sources either at given time intervals or in response to an event occurring. If the platform doesn’t initiate integration events, but rather processes data that is sent to it, then the incoming data is collected over a period of time before being processed and transferred at certain intervals.
Real-time integration basically does what it says on the box. The iPaaS checks for new data to transfer or update continually and handles each new piece of data individually, rather than waiting for time intervals or event triggers to prompt integration. This cuts lag in data transfer down to seconds, rather than minutes.
What It Means for Buyers: Real-time integration will obviously result in more rapidly updated and unified data across your systems. It also tends to be more resource intensive and could be more expensive. If your data doesn’t need to be called immediately, real-time integration may be more costly than it’s worth. However, if you use data across systems rapidly, or rely on automated workflow processes, batch data could introduce inefficiency into your operations. The significance of batch integration vs. real-time integration ultimately depends on the type and urgency of the data you’re working with.
ETL (Extract, Transform, Load)
ETL, which stands for Extract, Transform, and Load, is a process by which data from different sources is consolidated into a single source. It is a 3-step operation where data is Extracted from external sources, Transformed into a format that is usable in the receiving source, then Loaded into its destination (commonly a data warehouse or repository). It used to be implemented by standalone ETL products, but the functionality has been rolled into most iPaaS products.
What It Means to Buyers: If you’re looking for built-in ETL functionality, look to the larger mid-market and Enterprise iPaaS solutions. Like multi-tenancy, Extracting and Loading are inherent to iPaaS’s core functionality. iPaaS products do differ in how much data transformation is available, as larger-scale products usually offer better transformation capabilities than smaller vendors.
iPaaS employ data mapping when assigning data fields from incoming data sources to fields in the receiving data source. For example, suppose a prospective client fills out a lead form on your website. That lead form submission has the contact’s name, email, organization, and availability. The integration between the lead form portal and the CRM must know where each of those pieces of information goes in the CRM, or where each data point is “mapped” to. It ensures that the data is organized so that it can provide business value in its final destination.
What It Means to Buyers: the biggest differentiating factor in data mapping capabilities is whether an iPaaS offers automatic data mapping services. This can save a lot of time when building out your own integrations or customizing prebuilt integrations, especially if your data tends to be straightforward or simple. If there are a lot of irregularities or quirks, automatic mapping features may struggle to handle your data.
API are a core part of how most iPaaS integrate systems. API stands for Application Programming Interface and can be roughly understood as an access point through which a program can communicate with external systems and queries. APIs are very commonly used by iPaaS, and some of the larger platforms offer the capability to build your own APIs.
There are several relevant types of API, but the most popular one is RESTful API. RESTful API provides certain development advantages for coders, but it can otherwise be understood as a standardized API architecture that can be accessed by a wide range of systems. This means more things—applications, devices, and integration platforms—can interact with a software that has a RESTful API while requiring less initial development, customization, and configuration.
What It Means to Buyers: iPaaS support for RESTful API matters most for developers who want to build their own API or if you need to make your own integrations in an enterprise context. If you want to make more direct use of RESTful API, look for iPaaS that feature “API Management” capabilities, or that discuss RESTful API support directly. Both terms are good signs that the iPaaS will have the level of API support you’re looking for.
iPaaS that support “hybrid integration” enable integration between on-premise and cloud-based systems. On-premise systems include anything that is hosted on-site, and commonly include data warehouses and legacy systems that have been in use prior to the cloud revolution. Cloud-based programs include most other systems and apps that have become the norm in the last decade. For midsized to enterprise-level iPaaS, this applies most significantly to Software as a Service (SaaS) programs.
What It Means to Buyers: Most larger iPaaS products integrate on-premise and cloud-based systems, but there can be differences in how effective said integrations are. If you know what on-premise systems need integrating, review how effective or robust a product’s hybrid integration capabilities are for similar systems. Frequently, reviewers can provide some of the best insights into how well hybrid integration works in practice.
Where “hybrid integration” refers to what systems iPaaS can integrate, “hybrid deployment” refers to where and how the iPaaS itself is deployed and hosted. When iPaaS is deployed as a hybrid platform, some components are hosted in the cloud and some are on-premise. This contrasts with the iPaaS norm, which is to be hosted in the cloud and managed by the vendor, per the discussion about multi-tenancy above. However, there are some business cases where there are advantages to having some components of iPaaS hosted on-premise.
What It Means for Buyers: Hybrid deployment options are standard among larger iPaaS vendors, but whether it’s a good idea for you is very contextual. Consider both what benefits in security and in-house management may exist from hosting some components on-premise, as well as what additional costs and labor is required in the process. Once you know what you want to host on-site and why, be sure to ask vendors about your specific deployment scenario when evaluating products.
Microservices is a programming structure in which a program is built as a series of components that can exist and operate independently. This contrasts with “monolithic” architecture, in which an app is built as a single unit. Monolithic apps tend to be more difficult to update and require more downtime for maintenance. Microservices architecture helps mitigate these issues by allowing developers to make changes to the program without downstream impacts or downtime.
Microservices are applicable for cloud deployment tech, API management, and integration technology, among other use cases. For integration, if microservices are exposed to a standard protocol (such as a RESTful API), they can be used by other services or apps without direct coupling. This helps address technical debt more efficiently and is better for agile development methodologies. However, it does require excellent documentation in order to keep track of the distributed microservices for maintenance and reusability.
What It Means for Buyers: Most users can benefit from a platform that is structured as microservices, since it may mean that they won’t have to buy bundled services and add-ons to the platform that they don’t need. If you’re a developer trying to build microservice-structured integrations yourself, only some of the enterprise iPaaS products will support that level of development. This means whether an iPaaS can support developing microservices can be a deciding factor between products.
Was this helpful?