# From Manual Handoffs to Clear System Boundaries > Why connecting applications begins with understanding responsibility, not simply exchanging more data. **Source:** https://pilot.isp.validatus.com/en/docs/from-manual-handoffs-to-clear-system-boundaries **Language:** en **Published:** 2026-10-13 **Updated:** 2026-10-13 **Category:** Architecture **Tags:** ERP, Data Ownership, Workflow Automation, Decision-Making *Why connecting applications begins with understanding responsibility, not simply exchanging more data.* On Monday morning, the engineering team releases an updated drawing. Revision C of an assembly has been reviewed and approved. Purchasing, however, is still working with Friday's bill of materials. Production has already scheduled an order based on the previous revision. When someone asks which version should now apply, the search begins: an email containing the revised drawing, an exported spreadsheet, a record in the ERP system, and a question sent back to engineering. Nothing has failed. The information exists. Each team is working with a version that, from its own perspective, appears entirely reasonable. **What remains unclear is when an engineering change becomes an authoritative decision for purchasing and production.** ## The spreadsheet isn't the real problem. Manual handoffs often emerge where several applications support different parts of the same business operation. Engineering manages drawings and technical revisions. Purchasing needs parts, suppliers, and procurement information. Production schedules orders, materials, and resources. Information moves between these areas through exports, spreadsheets, emails, and occasional manual re-entry. The obvious response is to integrate the systems and automate the exchange. But moving information more efficiently doesn't resolve what that information means once it arrives. A revised drawing doesn't necessarily authorize changes to existing purchase orders. A technically approved bill of materials doesn't automatically apply to every production order already in progress. **Automating the transfer of data can also accelerate the spread of decisions that were never properly defined.** ## Different systems can hold different truths. In software architecture, Martin Fowler uses the concept of *Bounded Contexts* to explain why distinct business domains may need their own internally consistent models. The same term can carry different meanings depending on where it is used. In engineering, “approved” might mean that a technical revision has passed review. In purchasing, approval might authorize a binding order. Both statements can be correct. They simply describe different decisions. This is why good systems architecture doesn't necessarily require a single application to own every piece of information. What matters is **which system is authoritative for which information, and who is accountable for the decisions associated with it.** In our example, engineering could own the approved technical revision, while the ERP system manages purchasing and production orders. That division would need to be deliberately designed, not assumed to exist because the applications are in place. ## A well-designed boundary connects rather than divides. A dependable handoff requires more than transferring a file or calling an API. Information must retain its business context. Which revision was approved? Which orders does it affect? When does it become applicable? Who decides what happens to materials that have already been ordered? Only once these questions have answers can the technical exchange be designed with confidence. Where systems use different domain models, a translation layer may help. Microsoft's *Anti-Corruption Layer* pattern describes an explicit boundary that translates between models without forcing one system to adopt another's internal assumptions. That doesn't mean every handoff needs a new service. A controlled export or a deliberate human approval can be equally appropriate when ownership, validity, and exception handling are clear. The quality of a system boundary isn't measured by how invisible it becomes. **It's measured by whether information retains its meaning as responsibility passes from one domain to another.** ## Automation cannot replace an undefined decision. Return to our updated engineering drawing. The new revision may affect components that have already been purchased or manufactured. Whether existing orders should change depends on consequences that need to be understood. An integration can make the revision available, identify affected records, and initiate a review. But changing an order already in progress remains a business decision unless the organization has explicitly defined the rules and authority required to automate it. That distinction separates technical integration from systems architecture. One moves information. The other determines how information becomes reliable decisions and coherent operations. ## Good architecture makes ownership visible. Not every email needs to disappear. Not every workflow needs to become fully automated. But it should always be clear where responsibility begins, where it ends, and what must happen before another system or team can take it over. That is how individual applications become a coherent systems landscape without losing the distinctions that make each of them useful. **The goal isn't for every system to know everything. It's for information to be authoritative where it matters — and for no decision to disappear between systems.** --- ## Sources and Further Reading - [Martin Fowler — Bounded Context](https://martinfowler.com/bliki/BoundedContext.html) — Domain models, context boundaries, and their relationships. - [Microsoft Learn — Anti-Corruption Layer Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer) — Translating between different domain models and system semantics. - [Microsoft Learn — Saga Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/saga) — Coordinating multi-step operations, partial failures, and decisions that cannot simply be reversed. *The architectural principles described are based on documented designs and reasoned conclusions derived from them.*