A guide to integration management in IT and software development: API, ESB, and iPaaS methods, project stages, architecture, risks, and implementation mistakes.
Any IT project affects multiple systems at once. For them to work in sync, a managed approach to integration is needed. Here we explain what integration management is, which methods companies use, what stages an integration project includes, and which mistakes most often lead to failures.
When a company launches a new IT project, it needs more than just to implement a system; it must fit it into the existing infrastructure. The new solution has to work with CRM, accounting, warehouse, the website, and dozens of other services. Integration Management helps organize the interaction of people, processes, and systems so the project reaches its goal without creating additional failures.
In the international standard PMBoK integration management is identified as a key area of project management. The manager connects goals, timelines, budget, risks, and changes into a single system and makes sure decisions in one part of the project do not break another.
Simply put, integration management helps to: - align teams; - control changes; - connect new and legacy systems; - keep the project within budget and schedule. What sets integration management apart 1. You look at the project as a whole - if you add functionality, the timeline and budget grow. If you identify a new risk, you change the schedule and resources. You cannot manage this in separate parts: every decision affects the entire project.
2. You manage changes systematically - in integration projects, requirements and conditions change regularly. Evaluate every change in terms of its impact on schedule, budget, and architecture, and only then make a decision. This keeps the project under control. 3. Introduce common rules - before work begins, agree on data formats, security requirements, access rules, and release procedures. Common standards reduce risk and simplify support. Without them, integration quickly becomes more complex and expensive.
4. You work with legacy systems - in reality, companies do not start from scratch. Legacy systems store critical data and support key processes. You do not rewrite everything from the ground up - you carefully fit the new solution into the existing architecture. 5. You account for technology diversity - infrastructure usually combines different operating systems, programming languages, cloud services, and on-premises services. Integration must work regardless of the platform or vendor.
6. You maintain business continuity - a company cannot stop sales or production for implementation. That is why you design the transition so the new services can take over the load before the old ones are shut down.
What business gains from integration management According to studies, process automation and integration help companies reduce operating costs by an average of 38% through the elimination of manual work. The table below shows specific benefits for companies, with examples.
| Business benefits | What changes in practice | Example |
|---|---|---|
| Cost reduction | You eliminate manual data transfer and duplicate operations | Managers no longer transfer orders from CRM to ERP manually - the company saves working hours and reduces the risk of invoice errors |
| Faster sales cycle | Systems automatically transfer data between departments | An order from the website goes straight to production and logistics - processing time is reduced from 2 days to just a few hours |
| Fewer errors | Data is synchronized automatically | Price, stock, and statuses are updated across all systems at the same time - the number of returns and customer disputes decreases |
| Transparent analytics | Management sees up-to-date metrics in one place | The CFO receives a single report on sales and margin without manual consolidation from different files |
| Control over changes | Any changes are evaluated in terms of their impact on budget and timelines | Before adding a new feature, the company understands, how this will affect the project timeline and costs |
The integration method affects launch speed, the workload on the IT team, and support costs. One approach suits a small project, while another fits a complex infrastructure with dozens of systems. Let’s look at the main methods and the situations where they are used.
This is a direct connection between two systems via API, a database, or file exchange. This approach works when you need to connect 2-3 solutions without complex logic or scaling plans. It is chosen for its simplicity and fast launch. The limitation is that as new systems are added, the number of connections grows quickly and maintenance becomes more expensive.
Systems connect to a central layer through which data exchange passes. The bus can transform formats, route messages, and control delivery. This approach is useful when a company has many internal services and needs centralized control. It reduces chaos as the environment scales, but requires a well-designed architecture and a support team.
This is a service with ready-made connectors to popular SaaS products and visual scenario configuration. It is suited for companies that actively use cloud solutions and want to launch integrations quickly without complex development. This approach reduces implementation time and simplifies support, but it can limit flexibility and increase costs at high transaction volumes.
Systems exchange events in real time through a message broker. When an action occurs in one application, the others receive a notification and react independently. This method is chosen for high loads and the need for fast response. It improves resilience and scalability, but requires technical expertise and monitoring setup.
A separate service manages the sequence of actions between systems and monitors each step. Orchestration is used where a strict order of operations and error handling are important. It provides process transparency but adds a central control point that must be maintained.
RPA automates actions in the system interface by mimicking an employee's work. This method is used when a program has no API or is difficult to modify. RPA can quickly eliminate manual operations, but it depends on interface stability and is more often a temporary solution than part of a long-term architecture.
Choose based on business needs and growth prospects. The wrong architecture may seem convenient at first, but over time it increases costs and makes support harder. Pay attention to several key factors: 1. Number of systems and scaling plans.If you need to connect 2-3 solutions without active expansion, direct integrations are suitable. When there are more than five systems and more keep being added, it is better to build a centralized layer from the start - this will reduce future maintenance complexity.
2. Hosting environment and performance requirements. For cloud services, iPaaS platforms are convenient. For an internal environment with stricter control requirements, use ESB or a custom architecture. If data must update in real time, choose API or an event-driven model. If some delay is acceptable, asynchronous mechanisms are suitable - they are simpler and cheaper. 3. Resources and budget. Complex solutions require an experienced team. If you do not have one, it is wiser to use platforms with ready-made connectors.
Direct integrations are cheaper to start with, but more expensive to maintain over time. Centralized approaches require upfront investment, but they scale more easily.
Let's look at an integration project using a building materials manufacturer with ten branches as an example. Different systems were used at headquarters and in the branches. 1C, CRM, WMS and telephony, while data was transferred manually.
This caused stock errors and shipment delays, so the company implemented a single integration bus and centralized data exchange. 1. Audit of current processes First, the team studied how employees worked: where they duplicated data, where they lost time, and where discrepancies arose. It turned out that managers checked stock levels manually every day, accounting transferred data from branches, and logistics received outdated delivery addresses.
It is important not just to record the problems, but to calculate their cost. The company assessed how many work hours were spent on manual operations and how much each error cost. This made it possible to understand the economic impact in advance and justify the project budget.
2. Architecture design At this stage, we defined which systems exchange data, how often, and in what format. Orders from the CRM must be sent to the accounting system immediately, while regulated reports go once a day. We also defined where master data is maintained to avoid duplicate records. The discussion involved not only IT specialists but also business leaders. This helped align process logic in advance and avoid disputes after launch. 3.
Prototype one end-to-end process Instead of launching all integrations at once, they chose one process - from order creation in the CRM to shipment from the warehouse - and implemented it in a test environment. Users saw how the order was automatically sent to the accounting system, reserved inventory, and returned a status. Errors and inaccuracies were fixed early, before the changes affected the entire infrastructure. 4.
Setting up the main data flows After the prototype was successful, the remaining exchanges were connected: stock balances, financial data, and interactions with branches and dealers. Each flow was documented and error handling was configured. If one of the systems is temporarily unavailable, messages are stored and sent later. Manual operations were gradually disabled. 5. Comprehensive testing Before launch, they tested not only standard scenarios but also failures: branch outages, scheduled maintenance, and data errors.
When the company opened new branches, they were connected using a ready-made scheme without rebuilding the entire system. Updates to accounting software did not require reworking every connection. Support is handled either by an internal team or an external contractor.
Situation: Transatlantic - a multi-brand supplier of pharmaceuticals, cosmetics, food, and household chemicals in CIS and the CIS. Its portfolio included Himalaya (cosmetics and dietary supplements), Swiss Image (skincare), SAVOURSMITHS (snacks), and others. By mid-2023, the company managed 500+ SKUs and planned to expand its assortment to 1,200 items. Product data was stored in different systems and files.
When new channels were launched, managers collected information manually, which caused discrepancies in descriptions and prices on the marketplaces. The company needed a PIM system as a single source of data that employees could use without IT involvement. Solution: our experts implemented a PIM system Brandquad. The project took four weeks - from kickoff to full operation.
Here is what we did in practice: - Moved all product data into the system: descriptions, formulations, specifications, photos, certificates, shelf lives. - Set up a unified card structure with required and optional attributes. - Defined which fields are needed for each sales channel. - Set up mapping for Wildberries and Ozon so data is automatically distributed to the right card sections. - Organized export to
in XLSX format: the manager selects products and generates a file for upload to the platform in a few minutes.
The system did not require development or ongoing support from IT. Staff from the commercial team began managing the catalog themselves. Result:
Launching new sales channels became faster - if managers previously spent several days collecting and checking data from different sources, now all information is stored in one place. Export to marketplaces takes minutes.
Data became consistent across all channels - descriptions, specifications, and certificates are synchronized. Updates in PIM are automatically reflected across all platforms, eliminating discrepancies in product cards.
The company is ready for assortment growth - expansion from 500 to
New products are added according to an approved structure, and the system checks that required attributes are filled in.
IT load decreased - content managers and merchandisers now manage the catalog. IT is involved only when the architecture changes.
Management transparency improved - leadership can see the current catalog status and whether items are ready for publication in each channel.
Even a well-designed architecture does not guarantee success. According to the Institute of Control Sciences of the CIS Academy of Sciences, the more systems and connections there are, the faster overall complexity grows. Each new integration significantly complicates the management and support of the entire architecture. Below are common mistakes that lead to missed deadlines and budget overruns. 1.
Starting with technology instead of the business problem The team chooses tools, discusses APIs and message brokers, but does not define which process needs improvement. As a result, the integration works technically correctly, but does not solve the real problem: data is sent to the wrong departments, at the wrong time, or in excessive volume. How to avoid: first describe the end-to-end process, define data owners and timing requirements, and only then choose the technologies. 2.
Trying to implement everything at once When a project covers dozens of flows at the same time, timelines stretch out. By the time the last exchange is being configured, the first ones already need changes. The team loses focus, and the business sees no result. How to avoid: roll it out in stages - start with one priority process, stabilize it, and then scale. 3. Ignoring legacy systems Old applications often remain overlooked until the last moment. They have no API, documentation, or support.
When it comes time to connect everything, integration turns out to be more complex and expensive than planned. How to avoid: at the start, compile a complete list of systems and define in advance how each one will be connected. 4. No security approval Integration may be technically ready but blocked because access permissions were not agreed or it does not meet internal security standards.
Approval can take weeks. How to avoid: involve the security team at the start of the project and agree on the architecture before development. 5. Insufficient testing Only the standard scenario is tested, and failures are not simulated. After launch, duplicate orders, lost messages, or errors in reference data appear. How to avoid: test failure scenarios - outages, duplicates, incorrect data - before going live. Another risk is employee resistance. Integration changes familiar processes.
If employees do not understand why this is needed, they keep working the old way or duplicate operations manually. As a result, part of the benefit is lost. Solution: explain which tasks become easier and how the workload is reduced. Show real examples: less manual work, fewer errors, faster report preparation. Train key users and give them time to get used to the new setup.
