Data Integration for Government: Past the Mainframe, Through the ATO

Government data integration looks like commercial integration plus a layer of constraints that change everything. The source system might be a 1990s COBOL mainframe with no API, accessible only via 3270 emulation or batch FTP at midnight. The data flowing across it might be subject to a data sharing agreement with another agency that imposes its own access controls, audit requirements, and prohibition on certain downstream uses. The receiving system has to be inside an Authority to Operate boundary that includes the integration pattern. The records office needs to know whether the integration creates a new system of records under the Privacy Act. And every new data flow potentially triggers a Privacy Impact Assessment update. Commercial integration patterns assume none of this; government integration patterns are designed around it.

Government integration done right approaches each interface as a small ATO project of its own. Data classification and authorization decision before any technical work. Data sharing agreements negotiated in parallel with design. Integration pattern selected to minimize ATO boundary impact (event-driven where possible, well-bounded batch where not). Audit logging and access controls baked in. Records officer consulted on retention. Privacy Impact Assessment updated. Then — and only then — the technical implementation, which is usually the smallest part of the work. Done with this discipline, integration projects deliver. Done as commercial-equivalent technical work, they get paused at the security review.