# Planning and running interfaces: integration without unmaintainable one-offs > How systems talk to each other properly: define the authoritative system, document interfaces, handle error cases, use an integration platform where it fits and limit dependencies. URL: https://techport.ai/en/it-beratung/architektur-und-anwendungen/schnittstellen-und-integration --- 1. [IT Consulting](/en/it-beratung)/ 2. [Architecture and Applications](/en/it-beratung/architektur-und-anwendungen)/ 3. Interfaces and integration [Architecture and Applications](/en/it-beratung/architektur-und-anwendungen) # Interfaces and integration By Redaktion techport.ai, IT-Beratung · Last updated on 21 August 2026 Interfaces are the least visible and most sensitive part of an IT landscape. They get built when two systems need to exchange data, they run quietly for years, and they only draw attention when they stop. At that point it turns out that nobody knows exactly what is transferred, in which order, and what happens when a record does not arrive. Integration is not a technical detail but a decision about data ownership. Which system holds which information, who may change it, and what applies in a conflict. Answer those questions and you need fewer interfaces and get better ones. ## How you notice it * The same information is maintained in two systems and the states regularly diverge. * There is a nightly transfer, and when it fails a clerk notices the next morning. * Interfaces were built by people who no longer work at the company. * Every system change raises the question of how many interfaces are affected, and nobody knows the answer. ## Why this happens Interfaces get built under time pressure at the end of projects. The budget is spent, the goal is that data flows, and the fastest solution wins. Documentation, error handling and monitoring feel like luxury at that moment. Afterwards nobody touches them again because they work. Only years later, when one of the two systems is replaced or an error occurs, does it become clear how much knowledge sits in that one connection. ## How we go about it 1. **Record the data flows.** We capture which data flows between which systems, in which direction, how often, using which technology and who built it. That overview alone is usually revealing because it exposes loops and duplicate paths. 2. **Define ownership per data object.** We determine for customers, articles, prices, employees and other central objects which system is authoritative and which only read. This definition often cuts the number of necessary interfaces sharply, because bidirectional connections become unnecessary. 3. **Standardise technology and operations.** We define how new connections are built, how errors are handled and logged and how a transfer can be repeated. Where the number of connections justifies it, we examine a central integration platform. 4. **Monitor and document.** We set up monitoring that reports a failure before a user notices it, and document per connection its purpose, fields, schedule, contact and behaviour in the error case on a single page. ## What you gain * Fewer contradictory records, because it is clear which system is right. * Failures that surface before they reach the departments. * System changes that become plannable because dependencies are known. ## From our projects When recording data flows we regularly find connections that nobody needs any more but that keep running and overwrite data. A recurring pattern is the silent reverse direction: an interface was originally built both ways, only one direction is wanted today, the other keeps running and produces exactly the discrepancies that people have been correcting manually for years. The second pattern concerns error handling: in most grown connections there is none, and failed transfers vanish without notice. Both findings are fixable with modest effort once they are visible. ## Häufige Fragen Do we need an integration platform? From roughly ten to fifteen productive connections it is worth examining, before that rarely. The benefit lies less in the technology than in the standardisation: one place for monitoring, logging and retries. The drawback is an additional component that has to be operated and mastered. With only five connections you are better served by clean individual solutions. Should we use the vendor's standard interfaces or build our own? Standard wherever it covers the business requirement, even if it looks inconvenient at first. Custom connections typically get built to accommodate a small deviation, and they cost again with every version change of the system. Where a custom solution is necessary, it belongs documented and tested like any other application. ## Let us talk about Interfaces and integration In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it. [Arrange an initial call](/en/kontakt)[Our software](/en/loesungen) ## Further reading [Architecture and ApplicationsCleaning up the application landscapeWhich systems carry which process, where data originates, what is duplicated and what is being phased out. An overview that speeds up decisions instead of filling folders.](/en/it-beratung/architektur-und-anwendungen/anwendungslandschaft)[Data and InformationCleansing master data and keeping it cleanHow master data becomes and stays clean: measure quality, cleanse where it matters, regulate creation and maintenance, prevent duplicates and keep quality metrics in view.](/en/it-beratung/daten-und-information/stammdatenqualitaet)[Architecture and ApplicationsSettling the cloud questionCloud decisions per system rather than across the board: cost over the term, operations and specialists, legal requirements, vendor dependency and a defined way back.](/en/it-beratung/architektur-und-anwendungen/cloud-strategie)[KnowledgeIT glossaryTerms from IT, software and security, briefly explained.](/en/it-beratung/glossar)[KnowledgeIT maturity checkKnow where your IT stands in ten minutes.](/en/it-beratung/reifegrad-check) Back to the field [Architecture and Applications](/en/it-beratung/architektur-und-anwendungen) Rt Written by [Redaktion techport.ai](/ueber-uns), IT-Beratung Mehr als 15 Jahre Erfahrung in IT-Projekten des Mittelstands, Auswahl und Einführung von Unternehmenssoftware, Aufbau von IT-Betrieb und Informationssicherheit in wachsenden Organisationen. [More about us](/en/ueber-uns) More from techport.ai [ Software Custom process software for mid-sized companies. ](/en/loesungen)[ HR consulting People processes and the systems behind them. ](/en/hr-beratung)[ IT maturity check Ten minutes to a clear position. ](/en/it-beratung/reifegrad-check)[ HR maturity check 24 statements, a result per field. ](/en/hr-beratung/reifegrad-check)[ Funding BAFA grant plus more than 50 programmes for delivery. ](/en/foerderung)[ Process in practice How workflows become reliable software. ](/en/sop-praxis)[ Data and AI Analysis, forecasts and assistance systems. ](/en/daten-ki)[ About us The people behind techport.ai. ](/en/ueber-uns)