AS9100 and AS9102 should influence aerospace system architecture by making traceability, evidence control, version governance, approvals, and change control architectural requirements rather than afterthoughts. They do not require a single monolithic platform, and they do not make a system compliant by themselves. The architecture must support the quality management system, the production process, and the evidence needed to show that work was performed against the correct requirements.
AS9100 is broader than software architecture. It defines quality management expectations around controlled processes, risk, nonconformance, corrective action, documented information, supplier control, and continual improvement. AS9102 is narrower and more specific: it affects how first article inspection data, characteristics, ballooned drawings, measurement results, approvals, and design-to-production evidence are created and retained.
What this means architecturally
The practical implication is that aerospace systems need clear ownership of records and reliable links between systems. In most brownfield environments, PLM, ERP, MES, QMS, inspection tools, document control systems, and sometimes customer portals all hold part of the evidence chain. The architecture should define which system is authoritative for each record and how revisions, effectivity, work orders, inspection plans, nonconformances, and approvals move between them.
Common architectural requirements include:
- Controlled master data: part numbers, revisions, routings, operations, characteristics, tools, materials, and inspection requirements need governed sources and change history.
- Revision and effectivity control: operators and inspectors must work to the correct drawing, specification, work instruction, and inspection plan for the job being executed.
- Traceable execution records: the system should preserve who did what, when, against which requirement, with which material, equipment, tool, and inspection result where applicable.
- FAI linkage: AS9102 first article records should be tied back to design characteristics, ballooned items, measurement evidence, nonconformances, dispositions, and approval status.
- Nonconformance and CAPA integration: escapes, defects, deviations, MRB activity, and corrective actions should not live as disconnected side records.
- Audit trails and access control: changes to controlled records should be attributable, reviewable, and protected according to the site’s validation and security requirements.
- Retention and retrieval: records must remain usable over long product, program, and equipment lifecycles, not just stored somewhere.
Avoid the monolithic-system trap
AS9100 and AS9102 do not imply that every plant should replace ERP, MES, PLM, QMS, and inspection systems with one new platform. In aerospace-grade and similarly regulated environments, full replacement is often unrealistic because of qualification burden, validation cost, downtime risk, integration complexity, traceability obligations, change control, and long asset lifecycles.
A more credible architecture usually separates systems of record from systems of execution and evidence capture. For example, PLM may own released engineering definitions, ERP may own orders and inventory transactions, MES may control shop-floor execution, QMS may manage nonconformance and CAPA, and an FAI tool may manage AS9102 packages. The hard part is not drawing this map. The hard part is keeping revisions, identifiers, approvals, and statuses synchronized without creating uncontrolled manual workarounds.
Where architectures commonly fail
Failures usually appear at the seams between systems. A drawing revision changes in PLM but the shop floor still sees an older work instruction. A characteristic is ballooned in an FAI package but not linked to the inspection plan used in production. A nonconformance is dispositioned in QMS but the associated traveler, ERP inventory status, or FAI record is not updated. A report used for audit evidence is generated from a data extract that no one has validated.
Manual controls can be acceptable in some environments, but they need to be explicit, trained, and auditable. If the architecture depends on rekeying data between systems, the risk should be treated as a control issue, not hidden as an integration detail.
What remains site-specific
The right architecture depends on program requirements, customer flow-downs, export-control obligations, validation expectations, supplier relationships, product complexity, inspection strategy, and the maturity of existing systems. AS9100 and AS9102 provide pressure toward controlled, traceable, reviewable processes. They do not prescribe a specific vendor stack, database model, cloud pattern, or MES design.
The useful design question is not whether a system is “AS9100 compliant.” The better question is whether the overall architecture can reliably prove that the right requirement was used, the right work was performed, the right evidence was captured, exceptions were controlled, and changes were governed over the life of the program.