Federated Data Architecture
Federated Data Architecture is the logical capability of reasoning over and querying product information that stays in its system of record — CAD vault, PLM, ERP, ALM, MES, supplier portals — without forcing replication into a single mega-repository. CIMdata recognizes that “required business-process information typically resides in multiple repositories,” and the federated approach treats those repositories as authoritative endpoints.
What it covers
- Identity and resolution layer — a stable identifier (often a URI) for each artifact, resolvable across systems.
- Pull-on-read instead of bulk replication — the answer is computed against live source systems.
- Schema mediation — mapping each source’s local data model into a federated query view.
- Distributed search and graph traversal across heterogeneous endpoints.
- Caching and access-control — federated queries respect each source’s authorization model.
Why it matters in PLM
Single-vendor “one PLM” deployments rarely survive M&A, multi-disciplinary engineering, or supply-chain reality. A federated architecture is the underpinning of the Digital Thread and the multi-disciplinary linkage between mechanical, electrical, software, and operations.
Relationships (see sidebar)
- Depends on the PLM Data Model (the federated schema) and Metadata Management (the discriminator across sources).
- Supports Systems Engineering, Supplier Development, and BOM Management.
- Implemented by PLM platforms with strong integration layers — Teamcenter (Active Workspace, T4S, T4EA), Aras Innovator (federated Items), 3DEXPERIENCE (with Netvibes and Exalead), and Windchill (Navigate, ThingWorx).
Comments