Which parts should become shared capability?

Compare the work behind the matching screens

Consider two hypothetical purchasing teams in one company. North reviews ordinary purchase requests; South reviews supplier exceptions. Each wants a proposed answer with source references and correction history. Neither screen may place an order or change a contract. No shared component has been implemented or tested in this example.

The proposed shared component displays reviews. Each team keeps its own connector for loading source records, access checks, policy decisions, acceptance rules, and support assignments. North still decides whether its buyer can accept a request; South still sends nonstandard clauses to legal. The component displays those facts and decisions without acquiring the right to make them.

Check why the screens differ. South's legal review may be necessary; an extra copying step may be a defect. Preserve the first and investigate removing the second. Repeating a workaround in two teams is not a reason to build it into shared code.

Check what you may move into the shared project

Show the proposed reusable behavior without copying either team's real records. A generic example can demonstrate a missing source, correction, or blocked case. Raw contracts, customer identifiers, internal notes, and policy text stay where their owners permit them. Being inside one company does not make every business unit's information available to the platform team.

Check ownership of the code and evidence too. For customer-funded work, the contract may limit reuse, licensing, or publication. Name who can resolve those terms before moving files. Sanitizing a case does not establish that you own its implementation or have permission to publish it.

Use the two requests as a starting point and compare other permitted cases and counterexamples. Perhaps both teams need correction history but only one needs a particular exception field. Keep the common component small enough that local differences remain explicit.

Someone must own the shared version

Ask who will fix the shared component, review changes, answer support requests, and retire an old version. Each purchasing team still owns its workflow and its users. The shared maintainer needs reserved time; two teams adopting the same code also means a bad shared update can affect both.

Compare the cost of keeping two local implementations with the cost of extracting, testing, supporting, and migrating a shared one over the same period. Include each team's adaptation and repeated local checks. Leave costs unknown until the owners supply them. Fewer lines of code or a copied template don't establish lower delivery cost.

Candidate: review-card@0.1-candidate
Shared behavior: display permitted evidence, retain edits and correction history
Local decisions: sources, access, policy, acceptance, business actions
Needed before use: reuse rights, named maintainer, funded support, compatible interface, local tests
If an update fails: disable or pin the affected version; retain case records and an approved review path
Current decision: investigate; no shared release approved

Agree what information each team supplies to the component and how it reports edits or blocked cases back to their application. That input-and-output agreement is its interface. Give releases an exact version, document changes to that agreement, and say how long an older version will be supported. North and South need to know whether an update requires changes to their own applications. Plan how to disable or replace the component without losing pending cases or their history. Pinning a version buys time only while that version remains supported and safe.

Try the shared candidate in both jobs

Use permitted examples from each team. In North, try a closed cost center. In South, try a clause requiring legal judgment. The screen should keep each case blocked with the right next person; it must not copy North's buyer-acceptance rule into South's legal decision. Try corrections and an interruption too, checking that the current source revision and history remain visible when work resumes.

Also test a reviewer who cannot see a restricted source. The application must deny the read before the shared component, model, error message, or export receives the protected fields. Shared code must not imply shared data or permissions. Approval in North supplies no approval for South.

For now, keep both existing review paths while the team investigates rights, cost, maintenance, and those tests. A shared candidate should enter each team's normal release process only after its local requirements pass. Later, measure actual adaptation and support effort beside accepted work before claiming reuse made delivery cheaper or faster.

Take two repeated requests to their owners. Write the smallest common behavior, the differences that must remain, and the cost of owning one shared version. If nobody can maintain it or clear its reuse rights, leave the work local and record what would let you reconsider.