28 — Integration and information governance

An approved change can leave the business in a dangerous intermediate state: engineering has revised the cooling module, procurement still expects the earlier supply and production holds an obsolete installation package. Integration must make these differences visible and resolve them deliberately. Moving data quickly is useful only when recipients understand what the data authorises.

Assign authority before connecting systems

Allocate authority at attribute or coherent attribute-group level. DOORS controls customer-requirement content and its agreed baseline context. NX authors mechanical definition; Capital authors electrical definition within the agreed discipline boundaries. Teamcenter coordinates controlled product definitions, configurations, manufacturing-planning baselines and change relationships. SAP controls assigned commercial and operational transactions. These are operating-model allocations, not claims about automatically installed integrations.

Technical selection, contractual agreement and implementation acknowledgement are distinct. Engineering can establish that a replacement connector pair is acceptable without amending a supplier contract. Procurement can agree a delivery without approving an unassessed technical substitution. An integration service can confirm import without establishing that a vehicle has been modified.

Define each shared attribute's owner, approval role, source identifier, consumers and correction route. A supplier part number, internal identity, order line and physical serial number are cross-references with different meanings. Descriptions cannot safely replace that mapping. Replicated values retain source and version information; local convenience edits must not become competing definitions.

Exchange contracts

An exchange contract specifies the business event, payload, meaning, preconditions and acknowledgement. For a manufacturing release, include the package identity, baseline, resolved material selections, occurrence context, vehicle applicability, required instructions and change authority. Define which fields are mandatory and which omissions block consumption. A schema-valid message may still be unusable when its applicability is ambiguous.

Stable identifiers must survive renaming and legitimate restructuring. Record the issuing organisation and namespace so identical supplier numbers do not collide. Preserve revisions and baseline identifiers separately from item identities. When a receiving system cannot represent the source revision scheme directly, maintain an explicit mapping rather than truncating or translating it ambiguously.

Define units and quantity semantics. A value without its unit, reference condition or interpretation can change meaning during transfer. Distinguish quantity per assembly from total order quantity and planned consumption from actual usage. Dates need an explicit meaning and time convention: approval, intended introduction and recorded installation are different events. Transformation rules belong to a controlled mapping version with test examples and a responsible owner.

An exchange also needs an access contract. Recipients must receive sufficient technical information to act correctly while respecting supplier and programme restrictions. If a restricted source cannot be copied, supply an authorised reference and a workable access route. A broken link to an inaccessible specification is not a completed handover.

Transactions and recovery

Treat release distribution as a tracked business transaction. The source records the authorised package and transmission identity. The recipient validates dependencies, records the source version and acknowledges what it accepted. Operational use begins only when the required acknowledgement and readiness conditions are satisfied. A transport receipt confirms delivery to an interface, not business acceptance.

Failures require distinguishable states: awaiting transmission, rejected validation, accepted but not activated, active, superseded or awaiting reconciliation. Keep the reason and accountable recovery role. Retry transient failures using the same business-event identity so a repeated delivery does not create a second order or duplicate installation obligation. Corrected content receives a new controlled version and an explicit relationship to the rejected exchange.

Do not assume one transaction can atomically update every application and external supplier. Define a safe intermediate state and compensating actions. If SAP accepts a material update but rejects the related planning package, prevent unsupported production use and reconcile the partial result. Reversing a database value cannot undo a purchase already sent to a supplier; commercial recovery requires its own authorised action.

Reconciliation compares intended and received business states, not merely message counts. Check selected revisions, applicability, quantity interpretation and unresolved obligations. Maintain exception queues with owners and ageing. An interface dashboard showing all messages delivered can conceal a technically unusable configuration unless these semantic checks exist.

Customer change across the stack

The customer changes hot-climate operating conditions in DOORS while Vehicle 01 is building. Preserve the proposed requirement version and its relationship to the currently agreed baseline. Do not automatically replace the manufacturing basis. Technical assessment considers cooling, supplier HVAC, electrical demand, packaging and verification; commercial assessment considers the requested scope and existing commitments.

Capture the requirement reference and baseline in the impact package. NX work evaluates packaging and mounting implications; Capital work evaluates electrical interfaces and demand. Analyses and supplier responses support the integrated judgement. A payload change is a different customer change with potentially structural, suspension, braking and powertrain consequences. Neither is equivalent to a supplier notifying a changed connector, even if all three eventually affect the cooling-module configuration.

After disposition, Teamcenter coordinates the selected product and manufacturing baselines and their vehicle applicability. Procurement receives the authorised supply changes for SAP processing. The exchange identifies whether each order line is retained, amended, cancelled or subject to further negotiation. Sending a new part identity without disposition of the old commitment leaves both financial and delivery exposure unresolved.

Vehicle 01 needs assessment of installed and in-progress work, including access for any rework. Vehicle 02 needs supplier acknowledgement against its ordered equipment. Vehicles 03–04 can adopt revised planning baselines where authorised. Manufacturing instructions identify mechanical mounting, fluid connection and electrical mating work separately, with appropriate inspection and test obligations. Evidence links the actual result to the applicable configuration, including software or calibration identity where relevant.

If a supplier connector notification arrives during this assessment, retain its separate origin and disposition while linking overlapping impacts. Otherwise a requirement approval can accidentally be interpreted as approval of an unrelated substitution. Integrated impact assessment reduces duplicated work; it does not erase distinct authority.

Baselines and audit

Define the cross-system baseline boundary explicitly: retained requirement content, relationship versions, downstream selections and the evidence needed to reproduce the decision. Baseline and external-link behaviour must be checked against the selected DOORS edition and integration; this operating model does not assume that a requirements baseline captures externally held relationships.

Preserve the identities and versions needed to reconstruct the decision even if a live link later resolves to newer content. Audit records should connect the decision, transformed payload, mapping version, sender, receiving disposition and recovery actions. Corrections preserve the earlier record and explain the revised interpretation. Logging every technical detail indefinitely is neither necessary nor sufficient; retention follows the evidential and contractual purpose.

Migration and continuing governance

Migration is an engineering interpretation exercise. Classify legacy records as trusted, conditionally usable, conflicting or unresolved. Keep original identifiers and provenance. Do not infer a released configuration from the newest file date or treat missing serial data as evidence that the planned part was installed. Assign explicit limitations where history cannot be reconstructed.

Rehearse migration on complete configuration slices: requirement basis, definition, manufacturing plan, order, physical records and evidence. Compare source and target through business queries, including obsolete versions and exceptions. Counts and checksums help detect omissions but cannot prove preserved meaning. Reconcile changed units, identity merges and occurrence mappings under named authority.

At major-programme scale, partition exchanges and reconciliation by meaningful configuration and commitment boundaries. Millions of occurrences, years of changing schemas and thousands of users require version-compatible contracts, monitored queues and controlled retirement of interfaces. Expensive supply contracts make silent overwrite particularly costly. Governance therefore needs accountable information owners and operational support, alongside integration developers.

Choose the actual connectors, application programming interfaces and security mechanisms against selected product versions. The enduring requirement is that a receiving organisation can explain what it received, what it accepted, what remains inconsistent and which authorised action resolves the difference.

Work a failed exchange to recovery

Consider an authorised cooling package for Vehicle 02 following assessment of the customer hot-climate change. The requirements authority supplies the agreed DOORS reference and baseline context; engineering supplies the assessed mechanical and electrical definitions; configuration control fixes the selected package. Procurement separately authorises the order amendment. A service account distributes those decisions without acquiring their authority.

The exchange envelope records a stable business-event identifier, source namespace, package version, mapping version, predecessor, payload integrity reference, intended recipient and vehicle/operation scope. The contract declares dependencies such as the selected material identities and required instruction versions. These are required design semantics, not a prescribed API for DOORS, Teamcenter or SAP. Each adapter must demonstrate how its selected version represents them.

Suppose the recipient imports the material identity but rejects the installation package because its referenced instruction is unavailable. The integration owner records partial acceptance; manufacturing retains the affected operation hold. Procurement determines whether any order action has already escaped the system boundary. The package owner supplies the missing controlled instruction and issues a corrected exchange version linked to the failed version. An integration developer cannot repair the failure by dropping the instruction requirement.

A lost acknowledgement creates a different problem: the sender cannot know whether processing occurred. Retry with the same business-event identity and unchanged payload. The recipient's deduplication record returns the earlier disposition rather than creating another business action. Retain that record for the agreed replay period. The architecture must define what happens after that period; indefinite safe replay cannot be assumed from a short-lived interface cache.

If the same identifier arrives with different content, quarantine the conflict and involve the source owner. If a later package arrives before its predecessor or dependencies, hold it pending dependency reconciliation rather than treating arrival order as authority. A cancellation received after an order has been sent requires commercial disposition, not silent deletion. These cases need explicit acceptance tests because a successful normal transfer exercises none of them.

Reconciliation closes the loop at business level. Configuration control compares the authorised baseline and applicability with the recipient's accepted selection. Procurement checks the supplier's acknowledged amendment. Manufacturing checks the issued instructions and operation scope. Execution returns actual installation and inspection references; quality assesses the evidence against the applicable configuration, including control software and calibration where relevant. The exchange is complete only for the obligations actually satisfied. Receipt of material in SAP remains a logistics event unless the assigned execution process separately records installation.

A reconciliation discrepancy has one accountable recovery owner and contributing authorities. The integration team owns transport diagnosis and replay; the information owner decides corrected meaning; procurement owns contractual recovery; manufacturing owns executable work; the technical authority clears compatibility. This prevents every failed exchange becoming an undifferentiated IT ticket.

Before resuming held work, reconcile technical clearance, instructions, material and resources, execution acknowledgement and residual-exposure authority for the named operations and units. If service action is transferred instead, retain the accepting owner, unit applicability, criteria, due event and expected return evidence. Report transferred and physically completed obligations separately. A downstream system's closed task must not erase a still-open physical obligation.