Just as there are dozens of products and services to choose from when building your IT ecosystem, there are almost as many options for integrating your chosen tools and processes.
When choosing an integration solution, it’s important to consider not only your organization’s integration needs right now, but also anticipate your needs in the future. But we get it: analysis paralysis is real. We hope this article clarifies your decision-making.
This article is part of our series on choosing an integration solution. See other articles in the series:
Alternatively, all of these integration methods are covered in our Integration-as-a-Service Playbook.
This time, we’ll explore two common integration solutions: point-to-point integration, the simplest integration method, and integration as a service, the modern dark horse of the integration scene.
We’ll review these two methods across a few key areas:
- Time to integration
- Integration approach
- Ability to align and coordinate stakeholders
- Amount of resources required
- Scalability
- Cost
What is point-to-point integration?
Point-to-point integration, also known as "p2p integration" or "direct integration," refers to a method of connecting two applications or systems using code without the use of a centralized integration platform.
Using this approach, data is transferred directly from one application to another through a direct connection, such as an API or web service. Essentially, point-to-point integrations provide a direct pipeline between two systems, enabling them to communicate and share data. Simple, right?
How do point-to-point integrations work?
Point-to-point integrations can be implemented using a variety of methods, including custom code, middleware, or API management platforms. The most common approach involves building custom code that connects the two systems directly. This code can be written in any programming language, such as Java or Python, and is typically hosted on a server or cloud platform.
Why would a company use point-to-point integration in 2023?
In the ever-increasing tech stack of modern companies, point-to-point integration use cases are dwindling, and multi-point integration is gaining popularity. With every new technology investment, companies must find a way to integrate the new system with the incumbents—and often, using point-to-point integration as the only integration strategy can fail to deliver the quality of integration that most businesses need.
In terms of quality, modern companies need integrations that can withstand high message volume and load, are simple to modify and expand on, are easily scalable, and don’t have a single point of failure from being built manually by one person or team.
That being said, point-to-point integrations offer a simple way to connect two systems without needing a complex integration platform. This approach is particularly useful for small to medium-sized businesses that may not have the resources to invest in a centralized integration platform, or the integration needs to justify it.
What are the benefits of point-to-point integrations?
Point-to-point integrations offer a number of benefits, depending on the use case.
You’re likely to gain the most advantage from this integration method if:
- The use case is simple and shallow in scope.
- There is only one integration to build in your organization.
- The business growth benefits far outweigh the technical and financial costs of building the integration manually.
To understand the benefits and limitations further, let’s discuss point-to-point integration across the specific areas we discussed at the beginning of the post.
Time to integration: Can range from slow to fast
If your company has internal technical resources available, simple point-to-point integrations can be implemented quickly, which means you can start seeing the benefits of the integration almost immediately.
This is because the direct connection between the two systems eliminates the need for a centralized integration platform, which in some cases can take longer to configure, test, and launch.
However, if the integration requirements are more involved (i.e., connecting more than two systems, connecting uncommon tools with complex APIs, or needing significant customization), the time to integration can blow out immensely.
Integration approach: Custom coding
Point-to-point integrations are almost exclusively custom coded. This approach is beneficial because of the limitless possibilities for customization, but it falls short due to a few main factors:
- If the developer who creates the code doesn’t include proper documentation, it can be a challenge for future developers to troubleshoot, maintain or improve the integration.
- When a tool (for example, an ITSM tool or CRM) changes its API, the integration may break, and developers must then modify the code. If the company has several point-to-point integrations running, the manual maintenance work can quickly start to add up.
Ability to align technical and nontechnical stakeholders: Low
For a point-to-point integration to get up and running, significant work is needed from both business stakeholders and the technical specialists who make it happen.
Business stakeholders must understand their own needs for the integration, and be able to communicate them clearly. For example:
- Which stakeholders (internal and external) need their systems to communicate with each other, and why
- What information needs to flow between systems, and in which direction
- How the integration should develop when, for example, new services or systems need to be connected
At the same time, technical stakeholders must be able to interpret these needs, create the technical solution and communicate it back to the business stakeholders.
Often, this situation requires a project manager to translate requirements between both sides, adding complexity and cost to the integration project.
Point-to-point integrations can also make it difficult to monitor and manage data flows between systems. This is because there is no centralized platform for monitoring and managing the integrations, which can make it harder to detect errors and ensure data quality.
Amount of resources required: Technical capabilities and dedicated personnel
Point-to-point integrations become complex and difficult to manage as more integrations are created. This can make it challenging for organizations to secure enough dedicated resources to ensure each integration is working properly and to troubleshoot issues when they arise.
Scalability: Low
To put it simply, point-to-point integrations are not scalable, because scalability isn’t inherently built into the method.
Every time a business case demands integration, it needs to be built from scratch. That is unless the organization has developed a method of delivering integrations in an easily repeatable manner. However, even with using a cloud platform like Azure or AWS to run code straight on the cloud (without needing to set up a server), this is still a piece of the puzzle that the organization must figure out themselves.
Point-to-point integrations are designed to connect two specific systems and may not be easily adaptable to changes in business processes or new system integrations. This can limit the business’ ability to respond to changing business requirements or integrate with new systems or services as needed.
Cost: Low to high
Point-to-point integrations can be less expensive than a centralized integration platform, especially for smaller organizations that don't require a complex integration solution.
However, as the number of integrations grows, so does the complexity of maintaining them, which can be time-consuming and costly. This is because each point-to-point integration is independent and needs to be managed separately, which can lead to duplication of effort and increased maintenance costs.
Thus, when evaluating the cost of point-to-point integration, it’s important to consider the total cost, including:
- Integration strategy and planning
- Development
- Infrastructure
- Maintenance
The verdict on point-to-point integration
To sum it up, point-to-point integrations offer a quick and easy way to connect two systems without the need for a centralized integration platform. This approach is particularly useful for small to medium-sized businesses that may not have the resources to invest in a more comprehensive integration solution.
However, organizations need to be aware of the limitations of point-to-point integrations, including maintenance, lack of visibility, limited flexibility, security risks, and complexity, as they evaluate their integration needs and choose the best approach for their business.
If by this point, you’ve decided that point-to-point integration may not be the right solution for your business, fear not—there are many other integration options out there.
In the next section, we’ll get into Integration as a Service, a service delivery model where customers—typically large enterprises or IT services companies—outsource integration projects to a service provider.
Before that, though, it’s important to be aware of a few other options you may eventually consider:
- iPaaS vs. Integration as a Service
- Enterprise Service Bus (ESB) vs. Integration as a Service
What is integration as a service?
The average enterprise uses hundreds of SaaS products and cloud services every day, and as that number continues to grow, so does the need to ensure effective information flow and communication between them. It’s where the initial need for integration came from, and it’s only becoming more complex as businesses and markets mature.
Enter: Integration as a service
Integration as a Service is a service delivery model where customers—typically large enterprises or IT services companies—outsource some or all of their integration needs to a service provider (an Integration Service Provider). Integration service providers generally offer detailed integration design and implementation services that link application functionality and/or data with each other and incorporate this into the company’s existing IT ecosystem.
The integration as a service model allows businesses to outsource their entire integration operation, from planning to delivery to maintenance, as well as many of the associated risks. This means that an organization no longer needs to develop and maintain its own integrations and can focus on its core business.
Why choose integration as a service?
The integration-as-a-service model serves both enterprises with a sufficient need to integrate multiple services and IT service providers who recognize the difficulty in rolling out and scaling integration solutions to their clients' systems. In essence, this time you’re buying the outcome, not just the technology.
Of course, most integration service providers use some type of integration technology (proprietary or otherwise) to get the job done, but customers are buying the end result.
These enterprises tend to be more mature businesses with many moving parts, multiple operating locations, and deeply rooted legacy systems. Also, IT service providers with sophisticated ITSM practices often require a systematic method of delivering integrations to their clients—this use case in particular fits the integration as a service model.
What’s important to keep in mind is that there are several types of integration service providers, and it’s important to choose the one that’s best suited to your industry or integration needs. For example, some integration service providers specialize in EDI, others in healthcare, financial services, or IT.
Benefits and limitations of integration as a service
Time to integration: Fast
Integration service providers often promise a fast time to integration, and for good reason—it’s one of the core outcomes of the service they’re providing. That being said, if your integration needs are in the realm of simple tool integration/automation, it may be just as fast (or faster) to get started with an iPaaS tool.
For integration service providers, the time to integration depends on a few factors:
- The technology the provider uses to deliver the service (their own proprietary technology, an iPaaS platform, or something else)
- The provider’s approach to their own service delivery (how quickly they are able to begin, deliver and repeat new customer projects)
Integration approach: No need to code
Because all of the technical aspects of integration are handled by the integration service provider, there’s no need to have technical integration expertise in-house.
Provided that the use cases and information needed to flow between systems are clearly defined, the customer generally doesn’t even need to interact with the technical side of the integrations.
Ability to align and coordinate stakeholders: High
Part of the service delivered by integration service providers is learning about the needs of different stakeholders and departments within the business and also understanding the nature of the ecosystem of vendors, suppliers, and contractors that need to be factored into an organization’s integration setup.
As integration experts, integration service providers are equipped with knowledge of even the most complex integration use cases, and can generally align and coordinate stakeholders with ease.
Amount of resources required: Very few internal resources, no technical competence needed
Outsourcing is synonymous with IT service management—whether it be an enterprise outsourcing some or all of its IT functions or a service provider outsourcing the non-core elements of its service to a specialized provider.
When working with an integration service provider, businesses often need just one continuous point of contact to manage the collaboration.
Scalability: Full scalability
Because integration service providers’ core business is to provide future-proof, high-quality integrations for their customers, it’s in their best interest to make sure their service is able to grow and scale with their customers.
Integrations provided by integration service providers are often inherently scalable, repeatable, and easily customizable based on the customers’ needs.
Cost: Medium
Now, while we’ve classed this one as "medium", customers buying integrations as a service will realize the return on investment much faster than using an alternative integration method.
Integration solutions typically come in packaged deals, where pricing is generally influenced by:
- Time to implementation
- Staffing considerations
- The scope of the integration functionality
- Tool and platform choice
- Maintenance costs
The integration-as-a-service model aims to bring a solution to market for a subscription fee, rather than a one-off cost. In practice, you’re purchasing the outcome, not the technology.
Granted, some integration service providers utilize their own (or others') technology to reach those outcomes, but they sell the outcome, not the means of achieving it.
Final words: to keep it custom, or to outsource?
Over the decades, point-to-point integration has served the IT industry and businesses small and large, keeping information flowing between systems and improving collaboration between teams and people.
However, with technological advancement and continuous improvement, comes change. And when the pitfalls of one method can easily be solved by another, it’s almost a disservice not to explore it.
While both methods can coexist peacefully, the integration-as-a-service model shines by operating in a way that encourages existing integration methods to continue doing what they do well, while improving the overall integration ecosystem of the business.
