Beyond Architecture Diagrams: FDE's Trade-offs for Boundaries, Integration & Risk

After the business model is confirmed, the team finally shares a common understanding of "order," "fulfillment commitment," "delay approval," and "fulfillment risk task." This shared understanding comes from the evidence package沉淀ed from the field in the previous article "Don't Rush to Draw Architecture Diagrams: How FDE Discovers Engineerable Problems from the Real Field" and the business source model confirmed with business experts in "Business Experts Should Not Face Technical Standards Directly: How FDE Turns Field Knowledge into Runnable Business Models." Without these prerequisites, architectural discussions can only stay at technical possibilities. Next, the architect opens the canvas, ready to connect ERP, inventory system, contract system, Agent, and rule service.

The real controversy starts now.

Where should order status be read from? Can delay approval directly change fulfillment commitment? Should risk judgment be synchronous or asynchronous? Should new capabilities go into the product platform, customer configuration, or project customization? Can Agent automatically write back to the source system? Who takes over when an interface fails?

No "standard architecture diagram" detached from the field can answer these questions. The same business model can correspond to multiple technically runnable architectures; the real difficulty is not how to draw boxes, but who is willing to bear the consequences left by each choice.

This article continues using the "manufacturing enterprise abnormal order" synthetic case from previous articles. This is a synthetic scenario set by the author to illustrate the method; it does not correspond to a real customer nor represent actual production results.

FDE's architectural responsibility is not to draw the most technically complete target architecture, but to drive the team to form engineering trade-offs with clear system boundaries, unique authority responsibility, verifiable interfaces, manageable failures, and reversible decisions — based on confirmed field facts and business models.

Architectural Boundaries Are Not Module Splitting, But Responsibility Splitting

Many architectural discussions start with "how many services are needed": order service, rule service, knowledge service, Agent service, integration service. The more modules, the more complete the diagram looks, but the real responsibility boundaries may still have no answer.

A system boundary divides at least six things simultaneously:

Who owns object identity and business facts;

Who can modify transaction state;

Who grants permissions to users, services, and Agents;

Who bears compatibility responsibility for interface, data, and rule changes;

Who is responsible for production operation, failure recovery, and reconciliation;

When the current solution exits, who migrates data, consumers, and operational responsibility.

If these questions are not clarified, every line on the architecture diagram is just a technical possibility, not an engineering commitment.

FDE here is not only responsible for organizing discussions. It must personally participate in key boundary design, interface implementation, contract testing, and failure drills, connecting field evidence, business models, code, tests, and operational materials. But FDE cannot automatically gain data authority, production authorization, or risk acceptance rights just because it understands the solution best.

First Question: Where Is the Authority?

"Which system holds the data" is not a precise enough question. This article suggests splitting into at least four types of authority:

Object Identity Authority: Who defines the unique identity of an order, contract version, or fulfillment commitment;

Current State Authority: Who can state what state an object is in at the current moment;

Transaction Write Authority: Who has the right to change commitments, approvals, inventory, or scheduling — business facts;

Final Audit Authority: When disputes occur, which system and which records serve as the final audit basis.

They may reside in the same system or be scattered across different business domains. Being able to read a piece of data does not equal owning it; saving a copy does not make it the fact authority.

In the synthetic case, the order system may be responsible for order identity and order status, the inventory domain for available inventory, the contract or approval system for commitment change evidence. The new exception handling capability can save evidence references, judgment versions, manual confirmation processes, and execution receipts, but cannot thereby write itself as the final authority for fulfillment commitments.

This distinction directly exposes several common errors:

Data platform aggregates data from multiple systems, then is mistakenly thought to decide which value is valid;

Two systems can modify the same commitment state, conflicts resolved only by human guessing;

Interface returns "accepted," caller treats it as business transaction success;

Agent generates reasonable suggestions, thus gains write capability unapproved by business and permission owners.

When authority is not confirmed, the correct action is not for FDE to pick an answer based on interface stability, but to keep the architectural decision pending, narrow automation scope, or retain manual processing. Unknowns cannot be filled by code; authorization cannot be replaced by technical convenience.

Second Question: Where Should Capabilities Be Placed?

After authority is clarified, we must decide who owns new capabilities long-term. The article compares five ownership types:

Stay in customer source system | Primary judgment: Does it involve authoritative identity, real-time state, transaction write, or final audit? | Long-term responsibility: Original system continues to hold facts and execution responsibility.

Enter product platform | Primary judgment: Does it have stable commonality and can be continuously maintained by product team? | Long-term responsibility: Product team bears compatibility, upgrades, and formal support.

Configuration or controlled extension | Primary judgment: Can customer differences be handled by rules, configuration, or stable extension points? | Long-term responsibility: Extension mechanism stable, customer differences remain identifiable.

Customer customization | Primary judgment: Are there special constraints that neither platform nor extension mechanisms can accommodate? | Long-term responsibility: Explicit owner, test, upgrade cost, and exit method.

Temporarily retain manual | Primary judgment: Are automation risk, evidence, or authorization not yet closed? | Long-term responsibility: Manual processing becomes formal operational boundary, not temporary cover-up.

These five ownerships are not a maturity ladder. Retaining manual does not equal failure; entering product platform is not inherently superior to configuration extension. Judgment criteria should be authority, change source, reuse scope, compatibility responsibility, operational capability, and exit cost.

For example, "identify potentially delayed orders" can form a generic task framework in the product platform; customer-specific risk thresholds can be handled by versioned rules; reading order and inventory status from source systems needs controlled interfaces; external commitment modifications stay in authorized systems; when evidence conflicts or write-back risks are not closed, disposal actions retain manual confirmation.

Two opposite anti-patterns appear most often:

One is stuffing all field differences into the product platform. Short-term it looks like reuse, long-term a single customer's fields, processes, and release windows hijack product versions.

The other is putting all differences into customer branches. Project moves fast, but every upgrade requires re-merge, test, and debug; eventually no one knows which code still belongs to the formal product.

Therefore, boundary review cannot only ask "can this be done this time", but also: who will maintain it a year later, who verifies compatibility during product upgrades, who has permission to handle failures, how to migrate on exit.

Third Question: How Should Systems Connect?

After system boundaries are set, connection methods cannot be ranked by technical advancement. Synchronous calls, asynchronous events, batch processing, file exchange, and manual handoff each serve different constraints.

Synchronous call | Better when: Current request must get immediate result, and upstream/downstream availability can be jointly borne | Must handle: Timeout, cascade failure, retry side effects, latency budget.

Asynchronous event | Better when: Time decoupling allowed, need peak shaving, replay, or multiple consumers | Must handle: Duplicates, out-of-order, eventual consistency, dead letters, reconciliation.

Batch processing | Better when: Timeliness requirement low, data volume large, source system only opens windows | Must handle: Freshness, backfill, checkpoint restart, batch consistency.

File exchange | Better when: Interface capability limited, compliance or organizational boundaries explicitly require files | Must handle: Schema drift, transport security, versioning, processing receipts.

Manual handoff | Better when: Authorization, evidence, or automation risk not closed | Must handle: Operation guidelines, processing time limits, records, takeover responsibility.

In the abnormal order scenario, risk alerts may not need to block the order system's main transaction. The team can choose batch or event mode to aggregate order changes, generate risk tasks, then have authorized personnel confirm disposal. If an action must immediately verify inventory or permissions, synchronous call can be used within a controlled boundary. Specific choice must return to business timeliness, failure impact, and takeover capability — not "event-driven is more advanced" or "synchronous is simplest".

When old and new systems use different semantics, an adaptation boundary can be added to translate old system fields, errors, and protocols into contracts the new capability understands. Microsoft's Anti-Corruption Layer pattern supports this isolation thinking, but it also adds latency, operational components, and management cost. The adaptation layer should not become a new business decision center: it translates and isolates differences, should not silently assume full rules and process orchestration.

More critically, an interface is not a line on an architecture diagram, but a cross-team commitment. At minimum it must specify:

Provider, consumer, authorizing body, and upgrade contact;

Data structure, business semantics, version, and compatibility rules;

Permission scope, rejection conditions, error model, and retry budget;

Idempotency key, ordering, replay, dead letter, and backfill rules;

Deprecation notice, migration period, monitoring, and manual takeover.

Contract testing can prove cross-boundary assumptions still hold, but cannot prove the complete business process correct. Real transaction success still needs end-to-end testing, business reconciliation, and operational monitoring together. "Interface returns success" and "commitment has been changed via authoritative process" must be two different check items.

Fourth Question: Who Accepts the Risk?

Every architectural choice leaves consequences. Whether data leaves the domain, whether deployment environment (on-premise, private cloud, public cloud) can accommodate new components, how much permission services need, whether synchronous dependencies meet availability, whether customer team can operate new components, whether vendor lock-in and exit costs are acceptable — none of these can be decided by a single engineer.

FDE's responsibility is to make consequences visible, comparable, verifiable — not to accept risks on behalf of customer or product team.

A simplified Architecture Decision Record (ADR) should at least answer:

Field facts: Which business, data, permission, and operational constraints were confirmed at the time;

Chosen and not chosen: What solution was adopted, which alternatives were excluded and why;

Consequences: Benefits, costs, new dependencies, and residual risks;

Risk acceptance: Which authorized body accepts residual risk, where recorded;

Failure signals: Which metric, incident, or constraint change indicates the decision is invalid;

Rollback and review: What can be restored, when must re-decision happen.

Again using the synthetic case: suppose the team decides "Phase 1 only generates risk tasks and disposal suggestions, does not automatically modify scheduling or customer commitments." This decision's value is narrowing write permissions and irreversible risk; cost is retaining manual confirmation and processing latency. Business Owner must confirm phase scope, System Owner must confirm interface and operational responsibility, security or data authority must approve permissions and data usage, product team must clarify which capabilities enter long-term maintenance.

FDE can propose solutions, implement prototypes, verify contracts, drill failure paths, and explicitly point out risks not accepted. But it cannot decide business priorities for the customer, cannot approve data egress and production permissions, cannot promise permanent maintenance of a customer exception for the product team.

Fifth Question: How Does an Architectural Decision Become Invalid?

Many architecture documents only record "what was decided", not "under what conditions this decision no longer holds". So temporary solutions run for three years, original constraints have long changed, yet the team still treats the old diagram as the answer.

Architectural correctness is not a permanent property. A decision only holds within explicit facts, scope, time, and risk acceptance conditions.

For the abnormal order capability, several invalidation conditions can be pre-recorded:

Fact changes: Source system fields, object identities, or business rules change;

Scope changes: Extending from risk alerts to automatically modifying scheduling or customer commitments;

Operational failures: Duplicate tasks, state loss, latency exceeding standards, or persistent reconciliation inconsistencies;

Responsibility changes: Interface owner, operations team, or risk acceptor change;

External constraint changes: Data, permissions, regulations, deployment environment, or product capabilities change.

When failure signals appear, the system cannot rely on silent patches to maintain "surface availability". Rollback-capable configurations, routing, and versions should enter controlled rollback; transactions needing compensation must be reconciled; irreversible actions go to manual takeover; the original decision enters review and forms the next version ADR, not simply overwriting history.

This also requires architectural design to answer upfront: which configurations can roll back, which data can be replayed, which states need compensation, who executes, who confirms, who is responsible for reconciliation, how old interfaces and consumers exit.

If these questions have no answers at all, the team gets not an evolvable architecture, but a set of established facts that can only be maintained.

Technical Debt Is Not a Euphemism for Failure

Field delivery cannot eliminate all compromises. Delivery windows, source system capabilities, and product maturity may force the team to choose a less-than-ideal but currently controllable solution.

But a compromise can only be called technical debt if it simultaneously records:

What benefit is gained now;

What interest will be paid in the future;

Who is responsible for repayment;

Who has authority to accept residual risk;

What is the due date;

Which event triggers repayment or re-decision.

Unowned temporary scripts or shared accounts, known security vulnerabilities, unapproved excessive permissions, multiple systems writing the same authoritative fact, irreversible actions without recovery paths, and silent failures undetectable by monitoring or reconciliation — these are not "owe now, pay later", but blockers or explicit delivery risks.

FDE must push the team to face trade-offs, but cannot package all unfinished work as technical debt, nor use "field special" to replace owner, deadline, and risk acceptance.

Where FDE's Architectural Responsibility Ends

In the architectural phase, FDE must bear engineering connection responsibility: ensure decisions are grounded in field facts and business models, personally participate in solution comparison, boundary design, contract implementation and verification, and maintain traceability from decisions to code, tests, monitoring, rollback, and takeover materials. When facts change, it drives review rather than silently patching architecture.

This responsibility has clear limits:

FDE cannot decide business priorities and rules for Business Owner;

Cannot approve data egress and production permissions for data, security, and system authorities;

Cannot accept compliance, business, and organizational risks for customer management;

Cannot promise long-term maintenance of customer exceptions for product team;

Cannot write "proposal adopted" as "production results proven".

An architectural decision only becomes an engineering baseline when authority responsibility is clear, interface contracts are verifiable, failures are manageable, technical debt has an owner, and exit and review conditions are recorded.

Architecture diagrams help the team see the system, but they are not the answer. The real answer lies in every confirmed authority, every accepted contract, every rehearsable failure path, and every responsibility decision not usurped by FDE.

Article 04 determines where capabilities go, how systems connect, and who bears risk. The next article will continue answering: within these boundaries, how to cut the first controlled, runnable, verifiable delivery loop from prototype.

References

Frontline Deployment Engineering Practice Guide: Architectural Trade-offs

Microsoft: Anti-Corruption Layer pattern