Shared Object, Two Conflicting Consumers
A single 'Customer' business object is used by two processes. Process A (onboarding) creates new customers and needs the object to submit the form and capture the generated customer ID. Process B (annual review) only reads existing customers and displays their details. The object's action 'Open Customer Screen' currently hard-codes navigation to the onboarding menu path and presses Save at the end. Process B's team has started calling the same action and is now accidentally creating blank customer records when the screen auto-saves on exit. Separately, Process A's team wants to add a 15-field data capture step to the same action, which Process B does not need and which adds 20 seconds per record for B's 12,000 annual reviews. Both teams have change requests open against the same object.
1. Explain why the current object design is causing both the data corruption and the performance complaint, and propose a corrected action structure.
Read the worked answer
Two symptoms, one cause. The object exposes a single action that mixes three responsibilities: navigation, data capture, and persistence (Save). Any consumer that needs only one of those gets all three. Process B needs navigation and read-only display, but calling the action also triggers Save, which is why blank records appear - the object is performing a write the caller never asked for. Process A needs capture, but the capture fields are baked into the shared action, so every other consumer pays the 20-second cost.
Corrected structure. Split the action along the responsibility lines:
Navigate To Customer- pure navigation, no capture, no save. Used by both processes.Get Customer Details- reads the displayed fields and returns an output collection or data item. Read-only.Create Customer- takes a typed input collection of the 15 fields, performs capture, and calls a privateSave Customerpage. Write, and only called by Process A.Save Customer- private (not exposed on the interface), so no consumer can trigger an unintended write.
Why this works. Process B calls Navigate then Get, never touching Save, so the corruption stops. Process A calls Navigate, Create, and gets the generated ID as an output parameter. The 15-field capture runs only where it is needed, removing the 20-second penalty from B's 12,000 reviews. Each action now has one reason to change, so the two teams' change requests no longer collide on the same page.
2. The two teams disagree about who owns future changes to the object. Recommend a governance approach and describe how you would sequence the change to avoid breaking Process B in production.
Read the worked answer
Ownership. A shared object with two consumers needs a single accountable owner - typically the object's original design authority - with the consuming teams as stakeholders who raise change requests rather than editing directly. Publish the object's interface (actions, inputs, outputs, exceptions) as a contract, and require any change to that contract to be reviewed by both consumers. Changes to private pages are the owner's call alone.
Sequencing to protect Process B. Do not remove or rename the existing action in one step. Instead:
- Add the new granular actions alongside the old one and make the old action a thin wrapper, so nothing breaks immediately.
- Migrate Process A to the new
Create Customeraction first, since A is the team that wants the change and can absorb testing effort. - Migrate Process B to
Navigate+Get Customer Detailsand verify in a test environment that no records are written - check the ERP for new blank customers after a test run, not just that the process completes. - Once both consumers are migrated and have run cleanly for a release cycle, deprecate the old action, then remove it.
Safety net. Version the object release and record which process version consumes which object version. Keep a rollback copy of the previous object release so a regression in B can be reversed without blocking A's go-live.