10. PLM Architecture, Platforms and Information Governance

Introduction and Context

Product Lifecycle Management (PLM) is often described as a system for managing product data, but this description is incomplete. At postgraduate level, PLM is better understood as an enterprise information architecture that connects product knowledge, processes, people, applications, and governance mechanisms across the product lifecycle. Its effectiveness depends not only on software functionality but also on the way information is structured, exchanged, protected, retained, and used for decision-making.

A modern product may be conceived in one country, designed using distributed engineering teams, manufactured by several suppliers, regulated by multiple jurisdictions, serviced through connected equipment, and retired with environmental reporting obligations. Such a product creates a large and continuously changing body of information: requirements, models, drawings, specifications, bills of material, software, test results, manufacturing instructions, supplier records, service histories, compliance evidence, and end-of-life documentation. PLM architecture provides the technical foundation for managing this information. Information governance establishes the rules that determine who may create, modify, approve, access, share, retain, or dispose of it.

The architectural decision is therefore strategic. An organization may select an on-premise, cloud, or hybrid arrangement; integrate PLM with enterprise resource planning (ERP), manufacturing execution systems (MES), computer-aided engineering (CAE), customer relationship management (CRM), Internet of Things (IoT) platforms, and supplier systems; and define a governance model for master data, intellectual property, cybersecurity, and records. Poor decisions produce duplicate data, uncontrolled interfaces, weak traceability, and security exposure. Sound decisions create a trusted digital thread through which product information remains consistent and usable.

Learning Objectives

After studying this chapter, the learner should be able to:

1. Explain the architectural role of PLM platforms in an extended enterprise.

2. Compare on-premise, cloud, and hybrid PLM architectures.

3. Select suitable integration patterns, APIs, and data-exchange mechanisms.

4. Design governance for master data, access control, intellectual property, and records.

5. Evaluate cybersecurity, data ownership, compliance, and operational risks.

6. Apply architectural reasoning to an industrial PLM implementation scenario.

7. Assess emerging developments such as SaaS PLM, digital twins, event-driven integration, and AI-assisted governance.

PLM as an Enterprise Information Architecture

A PLM architecture consists of more than a central application. It includes the information model, application services, integration services, infrastructure, identity services, security controls, user interfaces, and governance processes that support the product lifecycle. The architecture should answer five fundamental questions:

• What product information exists, and how is it represented?
• Which processes create, consume, approve, and revise that information?
• Which systems are authoritative for particular data objects?
• How does information move between systems and organizational boundaries?
• How is information protected, audited, retained, and eventually disposed of?

A useful conceptual distinction is between the data layer, application layer, integration layer, and infrastructure layer. The data layer contains objects such as parts, documents, requirements, configurations, classifications, suppliers, changes, and manufacturing processes. The application layer provides functions such as configuration management, workflow, document management, requirements management, project management, and change control. The integration layer connects PLM with other applications through APIs, message brokers, file exchanges, and data services. The infrastructure layer includes servers, storage, networks, identity providers, backup facilities, and security monitoring.

PLM architecture must also support several dimensions of product definition. A product is not adequately represented by a single bill of material. Engineering, manufacturing, service, software, and regulatory views may coexist. These views must be related without creating uncontrolled copies. Configuration management provides the discipline for identifying versions, variants, effectivity, and approved baselines. The architecture must therefore support relationships among product structures, rather than treating each structure as an isolated list.

Important Architectural Terms

A system of record is the authoritative system for maintaining a particular data object or business record. A system of reference may provide a usable copy or view of information but does not own its authoritative lifecycle. A canonical data model defines common meanings, structures, identifiers, and relationships used when information crosses system boundaries. A digital thread is the connected flow of product information and traceability across lifecycle stages. A digital twin is a digital representation of a physical product, asset, or process that may be updated using operational data; it is not automatically created merely by storing a three-dimensional model.

The distinction between master data and transactional data is also essential. Master data changes relatively slowly and is shared across processes, such as part numbers, supplier identities, units of measure, material definitions, and product classifications. Transactional data records events or activities, such as an engineering change order, inspection result, purchase order, or service event. Confusing these categories often causes duplicate identifiers and inconsistent reporting.

Architectural Deployment Choices

On-Premise PLM

In an on-premise architecture, the organization operates the PLM infrastructure within its own facilities or private data centers. It controls hardware, network configuration, upgrade timing, storage location, and many security mechanisms. This model can be appropriate where export controls, data sovereignty, latency, highly specialized integrations, or strict internal policies are significant concerns. It may also be preferred where existing infrastructure and specialist support capabilities are already substantial.

The disadvantages include capital expenditure, responsibility for capacity planning, patching, disaster recovery, availability, and specialist administration. Upgrades can be delayed because customizations and integrations must be tested extensively. The organization retains substantial responsibility for vulnerabilities in operating systems, databases, middleware, and application components.

Cloud and SaaS PLM

Cloud PLM places infrastructure and, in some cases, application operation with a cloud provider. In a software-as-a-service (SaaS) arrangement, the provider manages much of the application platform, including infrastructure maintenance, availability mechanisms, and standardized upgrades. Cloud deployment can improve scalability, support globally distributed collaboration, and reduce the need for organizations to operate data-center infrastructure.

Cloud adoption does not eliminate governance responsibility. The customer remains responsible for appropriate configuration, identity management, data classification, user access, contractual controls, and lawful processing. Shared-responsibility models must be understood precisely: the provider may secure the underlying platform, while the customer must secure accounts, permissions, integrations, and the information placed in the platform.

Potential concerns include provider dependency, network availability, subscription cost growth, jurisdictional issues, limited customization, integration latency, and the difficulty of migrating data away from the platform. A cloud contract should therefore address data ownership, portability, service levels, breach notification, subcontractors, retention, deletion, audit rights, and exit assistance.

Hybrid PLM

A hybrid architecture combines on-premise and cloud resources. For example, sensitive design data may remain in a controlled private environment while supplier collaboration, field-service information, analytics, or selected workflows operate in the cloud. Hybrid architecture can provide flexibility, but it introduces synchronization and boundary-management problems.

The central design question is not simply where data is stored, but where each data object is mastered, where it is processed, and which copies are permitted. A hybrid system should define authoritative ownership, synchronization frequency, conflict resolution, identity federation, network trust zones, and behavior during disconnection. Without these rules, the architecture may produce several apparently valid versions of the same product definition.

Comparative Decision Criteria

Deployment selection should be based on business and technical requirements rather than fashion. Important criteria include:

• sensitivity and export classification of product information;
• geographic distribution of users and suppliers;
• regulatory and contractual data-location requirements;
• availability, recovery-time, and recovery-point objectives;
• integration complexity and required response time;
• total cost of ownership and internal skills;
• customization and upgrade requirements;
• scalability and expected growth in users, products, and data;
• provider viability, portability, and exit risk.

A weighted decision matrix can be used, provided that security, compliance, and business continuity are treated as constraints rather than merely low-weight preferences.

Integration Patterns, APIs, and the Digital Thread

PLM rarely functions as an isolated application. Integration must preserve meaning, identity, state, and traceability as information moves through the enterprise.

Common Integration Patterns

Point-to-point integration directly connects two systems. It may be quick for a small number of interfaces, but complexity grows rapidly as the number of systems increases. It also creates tight coupling: a change in one system may require modifications in many others.

An enterprise service bus or integration platform mediates communication between applications. It can provide transformation, routing, monitoring, and error handling. However, a central bus can become a bottleneck if governance is weak or if business logic is hidden inside numerous transformations.

An API-led architecture exposes reusable services through controlled interfaces. APIs may support operations such as retrieving an approved part, submitting a change request, or obtaining the current manufacturing structure. Well-designed APIs define authentication, authorization, versioning, validation, rate limits, error responses, and audit requirements.

Event-driven integration publishes events such as “part approved,” “change order released,” or “test result accepted.” Interested systems subscribe to relevant events and respond asynchronously. This reduces direct coupling and supports scalability, although it requires reliable event delivery, ordering rules, duplicate-event handling, and clear definitions of event meaning.

Batch and file-based exchange remains common for large datasets, supplier collaboration, legacy applications, and regulated handovers. It is practical but requires strict naming, validation, encryption, completeness checks, and reconciliation. A file that arrives successfully is not necessarily a file that has been correctly interpreted.

API and Data-Exchange Governance

An integration architecture should establish a lifecycle for interfaces. Each interface requires an owner, business purpose, data classification, source of truth, schema, service-level expectation, authentication method, monitoring approach, and retirement plan. Versioning is essential because changing an API without managing consumers can interrupt production or invalidate historical traceability.

Data transformation should be explicit and testable. For example, one system may represent a material as a code, another as a text description, and a third through a standardized material specification. The integration must define whether these values are equivalent, related, or merely similar. Silent transformation creates false confidence and weakens engineering decision-making.

A robust pattern is to separate the authoritative transaction from downstream notifications. The system that approves an engineering change remains responsible for the approved change record, while other systems receive an event or synchronized representation. This prevents multiple applications from independently asserting approval status.

Information Governance Across the Product Lifecycle

Information governance is the framework of policies, roles, processes, controls, and technologies used to ensure that information is accurate, accessible to authorized users, protected from misuse, and managed for its required life. Governance is broader than data administration and more operational than a general policy statement.

Master Data and Identity Management

A master-data program begins by identifying critical objects and assigning ownership. Typical objects include part, document, product, supplier, customer, plant, material, unit of measure, and classification. For each object, governance should define its identifier, naming rules, attributes, allowable values, lifecycle states, steward, system of record, quality rules, and retention requirement.

A part-number policy illustrates the issue. If engineering, procurement, and manufacturing independently create identifiers, the organization may purchase or produce equivalent parts under different numbers. A centralized numbering service or governed creation workflow can prevent duplicates. However, centralized control alone is insufficient; classification, synonym management, duplicate detection, and periodic quality review are also required.

Data quality should be measured through dimensions such as completeness, validity, consistency, uniqueness, timeliness, and traceability. Quality rules should operate at data creation and change points, not only during periodic cleansing.

Access Control and Segregation of Duties

PLM access should be based on business need, not convenience. Role-based access control assigns permissions to roles such as designer, configuration manager, supplier engineer, quality auditor, or service technician. Attribute-based controls can add conditions based on project, geography, export classification, product sensitivity, employment status, or lifecycle state.

The principle of least privilege means that users receive only the access required for their duties. Separation of duties prevents one person from controlling incompatible activities, such as creating a sensitive part, approving its release, and authorizing its external distribution. Privileged accounts require stronger authentication, monitoring, time-limited elevation, and periodic review.

Access decisions should reflect the product lifecycle. A supplier may need access to a controlled drawing but not to unreleased design alternatives. A service organization may need serial-number-specific records but not the complete design repository. Temporary project access should have an expiration date rather than relying on manual removal.

Intellectual Property and Data Ownership

Ownership of PLM data is often more complex than ownership of the software subscription or physical storage. Contracts should distinguish ownership of pre-existing materials, newly created deliverables, jointly developed results, derivative works, metadata, usage data, and operational telemetry. Supplier and customer agreements should specify permitted use, confidentiality, onward disclosure, retention, and deletion.

Technical controls may include encryption in transit and at rest, rights management, watermarking, controlled download, view-only access, virtual workspaces, and monitoring of unusual export activity. These controls do not replace contractual and organizational measures. An employee who can legitimately view a file may still misuse it; governance must address both unauthorized access and authorized misuse.

Records, Retention, and Traceability

Not every PLM object is a record. A record is information retained as evidence of an activity, decision, obligation, transaction, or state. A working CAD file may be revised repeatedly, whereas an approved design baseline, released drawing, signed certification, or regulated test report may require formal records treatment.

A records schedule should specify retention periods, event triggers, legal holds, disposition authority, and the format needed for future interpretation. Retention should not mean indefinite accumulation. Excessive retention increases storage cost, discovery burden, privacy exposure, and cybersecurity impact. Destruction must be authorized, documented, and suspended when litigation, investigation, or regulatory preservation applies.

Traceability requires more than audit logs. It should connect requirement versions to design objects, design changes to manufacturing instructions, production records to serial numbers, and field events to the configuration actually delivered. Time synchronization, immutable or protected logs, and reliable identity records are important where evidence may be examined years later.

Cybersecurity and Resilience

PLM environments are attractive targets because they contain commercially valuable intellectual property and may provide pathways into manufacturing or supplier networks. A risk-based security architecture should consider confidentiality, integrity, availability, authenticity, and accountability.

Key controls include identity federation with strong authentication, network segmentation, endpoint protection, vulnerability and patch management, secure configuration, encryption, backup protection, logging, anomaly detection, secure software development, supplier risk assessment, and incident response. Interfaces deserve particular attention because an API account with broad privileges can become an efficient route for data exfiltration or unauthorized change.

Threat modeling should examine misuse cases such as stolen credentials, malicious insiders, compromised suppliers, ransomware, manipulated product data, vulnerable integrations, and unauthorized bulk export. Integrity attacks may be more dangerous than simple data theft: an altered material specification or manufacturing instruction can create safety and quality consequences.

Business continuity planning should define recovery-time objectives, recovery-point objectives, dependencies, alternate procedures, and restoration testing. A backup that has never been restored under realistic conditions is an assumption, not evidence of recoverability.

A Governance and Architecture Framework

A practical design can be organized into six connected decisions:

1. Information scope: identify lifecycle objects, classifications, relationships, and critical records.

2. Authority: assign system-of-record ownership and accountable data stewards.

3. Process: define creation, review, approval, change, release, suspension, and retirement states.

4. Integration: select APIs, events, files, or batch mechanisms according to latency, volume, criticality, and coupling requirements.

5. Protection: apply identity, access, encryption, monitoring, resilience, and intellectual-property controls.

6. Assurance: measure data quality, interface health, access recertification, audit findings, recovery performance, and compliance.

This framework should be supported by architecture principles. Examples include “capture information once,” “make authoritative ownership explicit,” “secure by default,” “prefer open and documented interfaces,” “preserve lifecycle traceability,” and “design for exit and recovery.” Principles become useful only when translated into review criteria and design decisions.

Applied Case: Hybrid PLM for an Aerospace Component Manufacturer

Background

The following is an illustrative case. AeroStruct, a fictional manufacturer of aircraft structural components, operates engineering sites in three countries and supplies components to several aircraft integrators. Its legacy PLM repository is hosted in a private data center. Suppliers exchange large design packages through encrypted file transfer, while manufacturing and quality systems use separate databases.

Situation and Problem

The company intends to introduce cloud-based collaboration and service analytics. The engineering organization wants to retain control of export-controlled design data, while procurement seeks faster supplier access. Previous integrations have created duplicate part numbers and inconsistent revision status. An audit also found that former project members retained access to shared workspaces.

Analysis

The architecture team identifies four classes of information. Unreleased and export-controlled design data require restricted handling. Approved product definitions require strong configuration control and long-term traceability. Supplier-manufacturing data require controlled exchange and validation. Service and field-performance data can be processed in a cloud analytics environment, provided that contractual and security requirements are satisfied.

The team assigns the private PLM environment as the system of record for engineering parts, released configurations, and controlled design documents. A governed cloud workspace is selected for approved supplier packages and collaboration metadata. The ERP system remains authoritative for purchasing and financial supplier records; the MES remains authoritative for production execution and shop-floor completion records.

Approach and Solution

A hybrid architecture is designed with federated identity and conditional access. Suppliers receive access only to project-specific workspaces and only to released objects intended for them. Download rights are restricted for highly sensitive documents, and all temporary access has an expiry date.

An API gateway mediates exchanges among PLM, ERP, MES, and the cloud workspace. A canonical identifier service validates part numbers and units of measure. When a change order is released in PLM, an event is published. ERP and MES consume the event and retrieve the approved information through authenticated APIs. They do not independently change the engineering revision.

Data-quality rules reject incomplete classifications and invalid units before release. A records schedule distinguishes working files from approved baselines, certifications, and production evidence. Security monitoring detects unusual bulk downloads, while quarterly access reviews verify that project membership remains justified. Recovery exercises test restoration of both the private repository and cloud collaboration records.

Outcome

The design reduces uncontrolled copies and makes authority explicit. Suppliers gain faster access to approved information without receiving the entire engineering repository. Manufacturing receives release events linked to controlled revisions, and auditors can trace a component from requirement and design change through production evidence. The architecture does not eliminate all risk: it creates continuing responsibilities for interface monitoring, provider management, access review, and data-quality stewardship.

Learning Points

The case demonstrates that hybrid architecture is a governance problem as much as a hosting problem. The essential decisions concerned authority, classification, access boundaries, integration semantics, and evidence preservation. Cloud collaboration delivered value because it was placed within a controlled information model rather than treated as an unrestricted file-sharing service.

Common Failure Modes and Professional Considerations

Several recurring mistakes weaken PLM programs. Organizations may select a platform before defining information ownership; migrate poor-quality data without cleansing; customize workflows excessively; treat every document as a permanent record; or assume that an integration is successful because data has technically moved. Another mistake is to grant broad access to accelerate collaboration, then attempt to repair exposure after a project ends.

Governance can also fail through excessive centralization. If every small decision requires a central committee, users create unofficial workarounds. Effective governance distinguishes non-negotiable controls, such as identifier uniqueness and export restrictions, from local process choices that may vary by site.

Ethically, organizations must consider the consequences of surveillance, automated access decisions, and AI-assisted classification. Employees and suppliers should understand what activity is monitored and why. AI recommendations must not silently alter released engineering information. Human accountability remains necessary for safety-critical approvals, intellectual-property decisions, and records disposition.

Technology and Emerging Developments

SaaS PLM is increasingly accompanied by low-code extensions, API marketplaces, event streaming, and cloud analytics. These capabilities can accelerate innovation but may create shadow applications and ungoverned data stores. Architecture review should therefore include citizen-developed workflows and externally hosted extensions.

AI can assist with duplicate-part detection, document classification, semantic search, requirements analysis, anomaly detection, and identification of incomplete metadata. Its output should be treated as a recommendation unless it has been validated for the relevant risk level. Training data, model access, prompt confidentiality, explainability, and protection of proprietary design information require explicit controls.

Digital twins and industrial data spaces are extending PLM beyond design and manufacturing into operation and sustainability. This expansion increases the value of lifecycle traceability but also raises questions about ownership of sensor data, interoperability, model identity, data sovereignty, and the accuracy of representations over time. Open standards and documented semantics will be increasingly important for avoiding new forms of platform lock-in.

Best-Practice Guidance

A mature PLM architecture should:

• define systems of record before building interfaces;
• classify information according to business, legal, and security impact;
• use governed identifiers and canonical meanings;
• apply least privilege, separation of duties, and time-limited access;
• prefer APIs and events for controlled, observable integration;
• validate data at creation and release points;
• preserve configuration, change, and approval traceability;
• distinguish working information from formal records;
• test backup restoration, disaster recovery, and provider exit procedures;
• review suppliers, extensions, and cloud contracts as part of the architecture;
• measure data quality, security posture, interface reliability, and user adoption.

Chapter Summary

PLM architecture connects product information, lifecycle processes, applications, infrastructure, and governance. On-premise, cloud, and hybrid deployments each involve trade-offs involving control, scalability, security, cost, integration, and data sovereignty. The most important architectural question is not simply where PLM is hosted, but which system is authoritative for each information object and how controlled representations move across boundaries.

APIs, integration platforms, event-driven patterns, and file exchanges can create a digital thread when they preserve identity, meaning, state, and traceability. Information governance provides the rules for master data, access control, intellectual property, records, retention, and ownership. Cybersecurity must protect confidentiality and integrity while supporting resilience and recovery. A successful architecture aligns technical design with professional accountability, contractual obligations, regulatory requirements, and practical lifecycle work.

Key Terms

System of record: The authoritative system responsible for maintaining a defined data object or record.

System of reference: A system that provides a usable copy or view but does not own the authoritative lifecycle.

Canonical data model: A common representation of data meanings, structures, identifiers, and relationships across systems.

Digital thread: Connected lifecycle information and traceability linking product stages and decisions.

Digital twin: A digital representation of a physical product, asset, or process that may be updated with operational information.

Master data: Shared, relatively stable data such as parts, suppliers, materials, and units of measure.

Transactional data: Data recording events or activities, such as changes, inspections, orders, or service events.

API: A controlled interface through which software systems request or exchange functions and data.

Event-driven integration: Integration in which systems publish and consume notifications about defined business events.

Enterprise service bus: Middleware that routes, transforms, and manages communication among applications.

Hybrid architecture: An architecture combining on-premise or private resources with cloud services.

Role-based access control: Permission assignment based on organizational or process roles.

Attribute-based access control: Permission decisions based on attributes such as project, location, classification, or lifecycle state.

Least privilege: The security principle of granting only the access necessary for assigned duties.

Segregation of duties: Separation of incompatible responsibilities to reduce fraud, error, or unauthorized action.

Data stewardship: Accountable management of data quality, definitions, lifecycle, and use.

Records governance: Policies and controls governing evidence, retention, access, preservation, and disposition.

Data sovereignty: The principle that data is subject to the laws and controls of the jurisdiction where it is located or processed.

Recovery-point objective: The maximum acceptable amount of data loss measured in time.

Recovery-time objective: The target time within which a service or system should be restored.

Review Questions

Short Answer Questions

1. What is the difference between a system of record and a system of reference?

2. Why is master-data governance important in PLM?

3. State two characteristics of event-driven integration.

4. What does least privilege mean in a PLM environment?

5. Why should working files be distinguished from formal records?

Long Answer Questions

1. Compare on-premise, cloud, and hybrid PLM architectures using technical, organizational, and governance criteria.

2. Explain how APIs, canonical data models, and event-driven integration contribute to a digital thread.

3. Discuss the relationship among PLM information governance, intellectual-property protection, and data ownership.

4. Describe a comprehensive access-control strategy for an extended enterprise involving suppliers and service organizations.

5. Explain how records retention, configuration management, and auditability support regulatory and professional accountability.

Analytical / Application Questions

1. An organization discovers that ERP, PLM, and MES contain different revisions of the same part. Design a governance and integration response that establishes authority and prevents recurrence.

2. A company is moving sensitive product data to SaaS PLM but must comply with data-location and export-control requirements. Develop a decision framework and identify contractual and technical safeguards.

3. A supplier requests unrestricted access to a complete product repository to accelerate collaboration. Evaluate the request and propose a secure alternative using classification, role-based access, APIs, and controlled workspaces.

22. Multiple Choice Questions with Answers

Question 1

Which architectural decision most directly prevents multiple systems from independently asserting the approved revision of a part?

A. Increasing network bandwidth

B. Assigning one system as the authoritative system of record

C. Allowing all systems to edit synchronized copies

D. Retaining every historical file indefinitely

Correct Answer: B. Assigning one system as the authoritative system of record

Question 2

Which integration pattern is most appropriate when systems should react asynchronously to a released engineering change while remaining relatively decoupled?

A. Event-driven integration

B. Manual spreadsheet exchange

C. Unmanaged point-to-point file copying

D. Direct database modification

Correct Answer: A. Event-driven integration

Question 3

In a hybrid PLM architecture, what must be defined to prevent conflicting product versions?

A. Only the physical location of servers

B. The number of user interface themes

C. Data authority, synchronization rules, and conflict resolution

D. A policy prohibiting all cloud services

Correct Answer: C. Data authority, synchronization rules, and conflict resolution

Question 4

Which item is most clearly an example of master data?

A. A single inspection result

B. An engineering change event

C. A supplier purchase transaction

D. A governed material definition

Correct Answer: D. A governed material definition

Question 5

A supplier should view a released drawing for one project but not unreleased alternatives or unrelated products. Which control best supports this requirement?

A. Permanent administrator access

B. Attribute- and role-based access with project and lifecycle conditions

C. Public access through a shared link

D. Removal of all audit logging

Correct Answer: B. Attribute- and role-based access with project and lifecycle conditions

Question 6

Which statement best describes the shared-responsibility principle in cloud PLM?

A. The provider is responsible for every customer permission and integration

B. The customer has no responsibility once data enters the cloud

C. Provider and customer responsibilities must be explicitly divided across infrastructure, configuration, identity, and data

D. Cloud deployment eliminates the need for cybersecurity controls

Correct Answer: C. Provider and customer responsibilities must be explicitly divided across infrastructure, configuration, identity, and data

Question 7

Why is a released design baseline generally treated differently from a working CAD file?

A. The baseline may serve as formal evidence of an approved product state

B. Working files can never contain intellectual property

C. Released baselines do not require access control

D. Working files are always stored outside PLM

Correct Answer: A. The baseline may serve as formal evidence of an approved product state

Question 8

Which cybersecurity concern is particularly serious for PLM because unauthorized modification may affect product safety or quality?

A. Loss of interface color consistency

B. Integrity compromise of specifications or manufacturing instructions

C. Temporary reduction in search speed

D. A larger number of approved users

Correct Answer: B. Integrity compromise of specifications or manufacturing instructions

Question 9

What is the primary purpose of a canonical data model in integration?

A. To eliminate the need for data ownership

B. To provide common meanings and structures across systems

C. To ensure every system stores identical databases

D. To replace identity and access management

Correct Answer: B. To provide common meanings and structures across systems

Question 10

Which practice best demonstrates responsible use of AI in PLM?

A. Allowing an AI model to change released designs without review

B. Using AI recommendations for duplicate detection with validation appropriate to the risk

C. Uploading confidential designs to any public model

D. Disabling all human approval for automated classifications

Correct Answer: B. Using AI recommendations for duplicate detection with validation appropriate to the risk