How We Resolved Complex Supplier System Boundaries: A 1.5‑Year R&D Governance Journey

1. What Boundary Governance Does

At the team level it clarifies the positioning of a module and aligns responsibilities to that positioning. At the product‑technology level it plans domain capabilities and consolidates scattered capabilities across modules.

2. Why Do Boundary Governance

2.1 Historical Background

Legacy architecture caused the supplier module to own many non‑supplier responsibilities (warehouse, procurement, after‑sale, etc.) while core supplier functions such as sourcing and quoting were scattered in the product‑center and procurement modules.

Resulting pain points:

Evaluation difficulty – fragmented logic makes completeness hard to assess and slows cross‑team evaluation.

Scheduling difficulty – aligning priorities and development rhythms across teams is challenging.

Change difficulty – siloed construction leads to inconsistent domain logic; historical inconsistencies must be resolved before further work.

Testing difficulty – cross‑system data generation raises familiarity costs.

2.2 Lack of Holistic Planning

Internal warehouses (managed by the company) and external warehouses (managed by suppliers) belonged to different modules, preventing unified planning and causing inventory‑count errors and stalled logistics tracking.

2.3 Deviation from Team Goals

The supplier module lacked a clear positioning, leading to missing core domain construction.

3. How to Conduct Boundary Governance

The process consists of three steps: Express Boundary → Identify Boundary Problems → Solve Boundary Problems .

3.1 Express Boundary

Expression Language: Choose a granularity that can describe boundaries richly while keeping comprehension low.

Uniformity: Ensure the language is consistent for communication.

Exit Criteria (准出): Boundaries must be independent, non‑overlapping, and collectively cover the entire domain; conflicts are resolved in a dedicated exit‑criteria step.

In practice the team used a five‑element business architecture (user, problem domain, scenario, product, capability) to define the supplier module:

Core Users: Suppliers, purchasers

Core Problem Domain: Supplier management and basic online collaboration capabilities

Scenario / Product / Capability: Captured in a concise diagram.

3.2 Identify Boundary Problems

Boundary problems are mismatches between the current state and the ideal design. The team matched mismatched parts to the appropriate module either by top‑down domain‑fit analysis or direct capability matching. For example, “signing”, “production scheduling”, and “stock‑in” originally placed in the supplier module actually belong to the procurement module, exposing clear boundary issues.

3.3 Solve Boundary Problems

Key difficulties include project‑management (whether a project can start) and technical design/implementation (post‑governance stability). The team adopted three strategic layers:

Business‑Oriented Strategies

Improve requirement‑analysis efficiency by reducing fragmented logic.

Boost stability and cut operations cost by preventing incomplete change analysis.

Accelerate business response by aligning priorities across teams.

Reduce learning cost by eliminating concept duplication.

Quantitative benefit can be estimated by “frequency × per‑instance gain”.

Resource Matching Tactics

Reserve resources during annual/half‑year planning.

Split handover: first transfer product responsibilities, then technical responsibilities.

Allow the receiving team to develop incrementally in the source codebase before full migration.

Complexity Reduction Techniques

Ensure Change Completeness: Trace data flow, align data‑warehouse changes, delete migrated code from the source side and run regression tests.

Postpone Unnecessary Changes: Use reverse‑proxy APIs to avoid external dependency refactoring; defer model upgrades unless essential.

Pre‑validate Data‑Cleaning Logic: Test cleaning scripts with production data to avoid incomplete test coverage.

During the 1.5‑year governance the supplier team aligned milestones with the procurement team (2020‑H2, early 2021, mid‑2021), transferred new requirements first, then legacy ones, and completed two migration waves in 2021.

4. Outcomes

R&D Efficiency Boost: Consolidated capabilities enabled single‑day iteration and release for supplier quoting.

Improved Domain Planning Completeness: Governance between supplier and warehouse modules produced a clear external‑warehouse blueprint.

Team Focus: The supplier team finalized its positioning and now concentrates on core domain work.

5. Takeaways

Boundary governance hinges on “recognizing module positioning”, “expressing module boundaries”, and “aligning boundaries” rather than pure code migration.

Successful governance requires tight product‑technology collaboration; without product input, technical efforts risk unreasonable boundaries and unsustainable solutions.

Boundary governance is an ongoing activity that must evolve with business, technology, organization, and people.

6. Further Reading

NetEase Yanxuan Boundary Governance Practice: http://mp.weixin.qq.com/s?__biz=MzI1NzQ2MzgyMw==∣=2247484744&idx=1&sn=0c0f30bb445fa11a4562bb4b194db6ca