If you’re looking to improve efficiency in your software delivery organization, a good first step is to integrate your toolchain and automate workflows.
The software delivery life cycle is complex and involves many specialists who each require specialized tools. Integration allows information to flow seamlessly from tool to tool, knitting your software delivery toolchain into a single connected value stream.
Integration also lets you aggregate data across departments, creating visibility for leaders who need to see the big picture of how IT and software delivery are performing to support business goals. In this article, we’ll take you through pros and cons of the four types of app integrations used in the software development life cycle.
A good integration strategy drives flow
The rise of product-based IT has led to a new approach to software delivery, where customer value is at the heart. In product-based IT, each product has its own value stream, powered by best-of-breed tools and cross-functional groups.
The goal of product-based IT is fast flow. Organizations want customer requests to be received, funded, and delivered as efficiently as possible. But it’s not as easy as simply rearranging your teams.
Dr. Mik Kersten, bestselling author of Du projet au produit, states that “disconnected software value streams are the number-one bottleneck to software productivity at scale.” In order to achieve fast flow, you need a robust, integrated toolchain.
Integrating tools and automating data transfer removes all the major impediments to flow, including:
- Perte de temps liée à la saisie répétée des données dans différents outils Agile et DevOps
- Erreurs humaines dues aux mises à jour de statut et aux passages de relais manuels
- Coûts indirects associés à la traçabilité manuelle aux fins de conformité
- Importation et exportation constantes de données pour les fournisseurs, les clients et les prestataires
With a connected value stream, every practitioner can work efficiently in their tool of choice, leading to a happier, more efficient workplace.
Integrating your toolchain is a big investment, so it’s important to find a solution that will work long-term. Learning about the different types of application integrations will enable you to ask the right questions and make an informed decision.
What is application integration?
Application integration, also referred to as integration, is the flow of information between two or more tools. Common integration patterns include:
- Bidirectional integrations between software delivery applications like Jira and ServiceNow
- One-way event-triggered integrations from DevOps tools like GitHub to Jira
- Integrations from many tools into a central database like MySQL
- Integrations between internal and external systems belonging to clients or suppliers
The number of options for software integrations can be overwhelming, so it’s a good idea to have a strategy in place that identifies what type of software integration you actually need before you start sifting through individual solutions. Otherwise, you risk getting bogged down in the mire of competing options.
The most important aspect to consider when creating your integration strategy is the method of integration. Whether you build it yourself or buy it off-the-shelf, there are four main methods that every application integration falls into:
- Do-It-Yourself (DIY) integrations using open APIs
- Plugins
- Outils d'intégration point à point
- Model-based integration tools
The pros and cons of app integration methods
1. The Do-It-Yourself method using open APIs
What are API integrations?
API integrations are connections between two or more applications that let those systems exchange data.
Un API, short for application programming interface, is a set of definitions and protocols for building and integrating application software. It’s a layer of programming that sits between the client and the application, routing and validating requests to services or information.
Think of an API like a telephone operator. You can call and make a request, and the operator responds to your request by connecting you to the right person. Similarly, you can program an application to request data from another application via an API. For example, apps like Expedia use APIs to gather information about flights from the websites of various airlines, which then gets displayed in Expedia’s UI.
Should you build your own integrations using APIs?
Most applications have public APIs, also called open APIs, which tell your developers how to speak to the tool. If you choose to build integrations yourself without the help of a dedicated integration tool, it’s up to your developers to determine which data is exchanged and how it will be interpreted. Developers build connectors, which establish a pattern of communication between two systems via their APIs.
Large-scale organizations often severely underestimate the complexity of DIY solutions, how long it takes to execute, and how difficult it is to evolve alongside business needs. L'un des largest US healthcare providers opted to build their own system of integrations and soon realized they bit off more than they could chew. It went beyond the original timeline, taking three years to complete, and carried an astronomical opportunity cost of over $50 million.
Even for smaller businesses, do-it-yourself integrations are costly. According to Tray.io, the average cost of building a single API integration can exceed $10 000, and requires a good deal of technical expertise.
And that number doesn’t even include the cost of maintenance. As apps evolve and security requirements change, so do their APIs. If you use homegrown integrations, developers need to stay on top of these changes by updating connectors. The more integrations you have, the less manageable it is to maintain them.
Another consideration is that it takes a certain expertise, as well as some trial and error, to know how to sync data without disrupting the participating applications. Too many queries to an application can overload it and jeopardize its operational stability.
The bottom line: Building and maintaining custom-built integrations is usually more expensive and time-consuming than what you thought.
Pros and cons of DIY integrations using open APIs
| Pour | Cons |
|
|
2. Plugins
What are plugins?
Plugins are pieces of software that you can install to expand the functionality of your existing applications. Some plugins facilitate data-transfer between specific tools. For example, there is a Jira plugin that allows updates to flow from Jira into Slack.
Are plugin integrations effective?
Plugins are good for specific, limited use cases, but it generally isn’t a good practice to adopt this as your main integration strategy. For one thing, users have to become familiar with various rules and methods for each different plugin. This adds to their cognitive load and can lead to confusion. For another, the use cases of plugins are relatively inflexible, so your developers would have to resort to custom-coded integrations to meet more nuanced use cases.
An additional challenge when using plugins to integrate is traceability. Without a central integration hub, it’s incredibly onerous to try and trace requirements to code or tests for security and auditing purposes, which is a requirement in regulated industries.
The bottom line: Plugins are suitable for very simple, straight-forward use cases but do not support complex business process or edge cases very well.
The pros and cons of using plugins to integrate your tools
| Pour | Cons |
|
|
3. Point-to-point integration tools
What does point-to-point mean?
Point-to-point integration tools are off-the-shelf solutions that provide a central application where you can manage integrations between two endpoints. Some tools provide pre-built connectors while others simply make it easier to build and organize your own integrations via public APIs.
Tools that use point-to-point integration follow the same pattern as building your own DIY integrations. The only point of difference is that they have a graphical user interface. This UI helps you configure integrations and troubleshoot more easily.
Since these tools are purpose-built for integrations, they are generally good at collecting and syncing data without disrupting the functioning of your applications.
Each integration is like a bridge between two applications. If you want to connect to an additional application, you must build a bridge leading to each of the others. As you add more integrations, the number of necessary bridges grows exponentially. 
The point-to-point method is also known as direct integration, star integration, or spaghetti integration. Looking at the diagram above, you can see where the term “star integration” comes from. The term “spaghetti integration” refers to the high degree of complexity within the system.
Are point-to-point integrations efficient?
In the domain of software delivery integration, point-to-point integration solutions require mapping each project in a source tool to the corresponding project in the destination tool. This is repetitive, error-prone manual work that quickly gets out of hand when you cross the 10-project threshold.
Maintenance costs for point-to-point integrations add up quickly. Taking into account setup and any subsequent changes to fields, values, and workflows over time, it would take 150 hours to maintain 15 project integrations for a year.
Vendors label their application integration tools in a variety of ways. Examples include iPaaS tools, ESB (enterprise service bus) tools, workflow orchestrators, middleware, and more. There are subtle differences between these types of integration tools but, overall, they all provide the same functionality. Generally considered “low-code,” some require more custom-coding than others.
The pros and cons of using a point-to-point integration tool
| Pour | Cons |
|
|
4. Model-based integration tools
What is a model-based integration?
Model-based integration is the most advanced evolution of application integration software. It’s the only way to efficiently synchronize enterprise-sized volumes of sophisticated data while maintaining the data’s integrity and supporting cross-tool reporting.
Unlike point-to-point integration, model-based integration is based on the principles of reuse at scale.
A model is an intermediary, like a universal translator, that sits at the center of all integrations and normalizes the data. It makes integrations scalable, because you only need to configure it once. During set-up, you define which fields will flow between applications, and this integration is automatically applied to all participating projects and artifacts, including any that are newly created.
Model-based integration requires 90% less maintenance compared to point-to-point integrations.
Prebuilt models are available for popular artifact types, which auto-suggest how data from each tool will be interpreted and represented in connected tools. For example, a “defect” model can be reused to flow data between a ServiceNow problem, ZenDesk ticket, GitHub issue, and Jira bug.
As shown in the diagram below, model-based integrations are like spokes on a hub.It’s easy to add and modify integration patterns without disrupting other connections.
Where the point-to-point integration model requires fifteen different connections, a model-based tool uses only six. This makes it easy for you to adapt your integration infrastructure to the changing needs of your business.
Download the Tasktop guide on model-based integration
The pros and cons of model-based integration
| Pour | Cons |
|
|
Example of a model-based integration tool
Currently, Planview Hub is the only integration platform that uses model-based integration. It comes with prebuilt connectors to over sixty best-of-breed tools that you can configure to meet the specific use cases of your organization.
In addition, it allows you to connect unlimited DevOps tools for event-triggered artifact creation and updates.
With a sophisticated UI and smart-modelling capabilities, it’s possible for a single administrator to set up integrations for a whole enterprise.
Watch this webinar to learn more about Planview Hub
Questions to ask when looking for an integration tool
There are a few questions to ask when deciding on which software integration tool is the best for your organization.
1. Will this tool integrate my Agile and DevOps tooling end-to-end?
Many tools claim to be end-to-end but they only integrate the DevOps cycle. DevOps cycle is just one part of your end-to-end value stream. Before a task reaches developers, it has already passed through planning, funding, and approval.
Look for a tool that integrates every stage of the software development lifecycle, including portfolio planning, application development, release and deploy automation, quality assurance, and service desks.
There is a caveat here: Beware tools that claim to integrate with ALL applications. This likely means that you’ll have to do much of the coding yourself to build connections from a general API.
2. Is it no-code or low-code?
No-code is better than low-code, because the set-upis much faster and easier. Non-technical personas can set up integrations without taking developers away from high-value work.
3. Does the integration use models or is point-to-point mapping between each project pair required?
Model-based integration is necessary if you want to operate at scale. Without models, you’ll have to manually repeat the same configuration for every project pair and repeat every subsequent change in tens of places (highly error-prone).
Next steps for building your integration strategy
Think about your own organization’s software delivery value stream. Where does work originate? How many applications does a defect or a story pass through before it finally reaches a customer?
There are so many opportunities to improve communication, reduce waste, and speed up handovers. The right integration strategy will help you realize those opportunities.
With an understanding of the different types of integration, the next step is to determine which type is the best for your organization. Voir le webinaire to learn the must-have capabilities for an integration solution.
