Engineering integration tax: how to size rework before a new tool
Size the engineering integration tax by inventorying every source and connection, scoring each connector on its cost drivers, and estimating in ranges rather than single numbers. Point-to-point translators grow roughly with the square of the tool count, while a shared schema grows linearly, so rework is largest exactly when you add the next tool.
What does an integration tax cost in engineering terms?
It is repeated labor to access, map and ingest the same data for each new tool, and it rarely shows up as a line item. The integration tax is the cost of rebuilding connectors every time a new tool is added. This article covers how to measure it.
The hidden labor is easy to underestimate. A NOAA business case found that NOAA and end users spend 25 to 50 percent of an FTE accessing, formatting and ingesting data for every product or output delivered. That is a federal ocean-data program, not your shop, but it is a useful sanity check. If your team's logged integration time is far below a quarter of an FTE per data product, you are probably missing hours spent in chat threads, spreadsheets and one-off scripts.
What are the main cost components of a connector?
Track eight hour buckets: discovery, authentication, field mapping, build, testing, deployment, monitoring and ongoing maintenance. Take the hours from your own past connectors, because generic per-connector figures hide the differences that matter.
Pull the last three connectors you built and split their time sheets or ticket history into those buckets. Mapping and testing usually dominate when sources disagree on names, units and identifiers. Discovery dominates when documentation is thin. Monitoring and maintenance never stop, so record them as hours per year, not as a one-time cost. Once you have your own distribution, you can apply it to new connectors instead of guessing.
How do you inventory integrations and data sources?
List every source, every consumer, every connection, its owner, its format and its last-change date, then count the connections each prospective tool would touch. That count is your rework scope.
Use one row per connection:
| Field | What to record |
|---|---|
| Source | System of record, such as an OEM telemetry platform, maintenance log or procurement system |
| Consumer | Dashboard, model, report or agent that reads it |
| Format | Machine-readable feed, or digitized only (scanned PDF, CSV export) |
| Owner | Named person who fixes it when it breaks |
| Last change | Date of the last mapping or API change |
| Hours | Build and yearly upkeep from your logs |
Then add a column for each tool you are considering and mark every connection it would need new work on. The column totals are the rework count. Digitized-only sources deserve a flag, since someone must turn them into structured data before any tool can query them. Scattered sources are a common pattern on fleets, and fleet data silos are worth ruling out while you build the list.
What makes one connector costlier than another?
Five drivers set the price: API quality, authentication, schema complexity, rate limits and data volume. Score each source on them before you estimate.
A simple sheet works. Rate each driver 1 (easy), 2 (average) or 3 (hard), then average the five scores to get a multiplier against your baseline connector. A well-documented REST API with token auth, a flat schema, generous limits and modest volume scores near 1. A vendor feed with undocumented fields, certificate-based auth, nested schemas, tight throttling and high-frequency telemetry scores near 3. These scales are a judgment tool, not a published benchmark, so calibrate them against your own actuals.
Apply the same logic to mixed-OEM equipment. Each manufacturer names signals, units and identifiers differently, which pushes schema complexity to 3 even when the API itself is clean. Normalizing OEM telemetry across manufacturers is usually where the largest share of that work sits.
Which estimation method fits high uncertainty?
Use three-point ranges per connector and T-shirt sizes for early triage, then calibrate against actuals. Single-number estimates fail on integrations because the unknowns sit in other people's systems.
For triage, size each connector S, M, L or XL from its multiplier score, which takes minutes and lets you rank the backlog. For connectors you intend to fund, give an optimistic, likely and pessimistic hour figure. Report the range with it. After each delivery, record the actual hours against the range and adjust your baseline.
How much maintenance do connectors need each year?
There is no universal percentage you can trust, so build the line from your own change history. Track change events per connector: API version retirements, schema drift, authentication changes and vendor updates.
Add a change-log column to the inventory and note each event with the hours it took to fix. After a year, you have an hours-per-event average and an event rate per source. Multiply the two for each connector, then sum. Sources that change often, such as vendor-hosted APIs, will carry most of the budget. Stable file exports will carry little. Also note which events caused silent data errors rather than loud failures, since those cost more to find.
How does point-to-point integration scale as tools are added?
Direct translators grow as n(n-1), while a canonical model grows as 2n, and the two are equal at three applications. The Enterprise Integration Patterns catalog shows this: 2 applications need 2 translators directly versus 4 with a canonical model, 3 need 6 either way, and 6 need 30 versus 12.
The same source notes that a canonical model seems complicated with few applications but quickly pays off as the number grows. Real estates rarely connect every pair, so treat n(n-1) as the upper bound and use your inventory for the actual count.
When does a hub, canonical model or shared schema fit?
A canonical model fits once you pass about three interacting tools or expect to. A canonical model is a superset data model with a translator layer, so each system only needs to know how to talk to the model, not to every other system.
It does not remove mapping. Each source still gets mapped into the schema once, and someone has to decide which record is authoritative. For a rule of thumb: stop building point-to-point connectors when your inventory shows three or more interacting systems and at least one more tool on the roadmap. Below that, a direct connector is cheaper. A fleet with several OEMs, maintenance logs and procurement records crosses that line quickly. When each new tool gets its own pipeline, teams end up rebuilding the same connectors, a pattern covered in common industrial data integration mistakes.
What should you do before buying the next tool?
Run the inventory, score the connectors, range-estimate the rework, and ask whether the tool can query a shared schema instead of needing its own connectors. If the rework count is high and the tool only reads through bespoke connectors, price that labor into the purchase.
A quick test: pick two assets from different manufacturers and ask whether one query with one set of field names returns comparable readings. If it does not, the next tool will add to your tax. If you want to see how a shared schema would be built from your own systems, ask us for a demo.
Related resources
SailPlan builds the machine-readable data model that makes every AI tool in your stack actually work. Request a demo to see it in action.