Web-to-print architecture and discovery

What the discovery covers

The product model must distinguish attributes customers can choose from attributes production needs. A size may be a free measurement, a constrained range or a fixed option. Finishing operations may depend on material or size. We document those relationships before proposing tables, variants or editor controls. This prevents the interface from promising combinations the plant cannot make.

Pricing rules are captured as inputs and decisions, not only as current figures. A spreadsheet may contain quantity breaks, setup, waste, sheet yield, customer tiers and exceptions in separate places. We trace a sample quote to its governing rule. If estimators disagree, discovery records the disagreement and who can resolve it; software should not silently choose a commercial policy.

The output specification describes what prepress will accept. It can identify page geometry, colour intent, permitted fonts, file format, proof requirements and failure messages. The client provides accepted and rejected files when available. We do not infer a production standard from a preview or from the format the storefront happens to export.

An integration inventory names every system that reads or writes an order: storefront, editor, pricing engine, MIS, ERP, scheduler, prepress route and fulfilment service where relevant. For each connection, the inventory records data direction, identifier ownership, available interface, authentication boundary, retry rule and what an operator sees when it fails. A sanctioned interface must be verified; a promise that a connector probably exists is an unresolved risk.

The inventory separates confirmed interface behaviour from assumptions. For each untested assumption, it names the smallest authorised test, the person who can provide access and the decision that depends on its result.

The decision document

The discovery output is an architecture and a phased plan. It includes a target data model, pricing-rule specification, print-output contract, integration inventory, risk register and acceptance criteria for the proposed next phase. It also compares reasonable routes: retain a packaged product, replace one component, build a custom core, or stop. The recommendation carries its own case against it.

The output of a discovery engagement is written so that a supplier other than us can execute it. That requirement changes how the material is written. A component has an owner and an interface; an acceptance criterion has an input and an expected result; an unknown has a decision owner. A drawing with boxes called "integration" and "automation" would not meet that standard.

What is outside this scope

Discovery does not implement the platform. It does not choose presses or hardware, set the client's commercial prices, repair the existing data, or obtain access the client cannot authorise. A prototype can be separately scoped if an unknown cannot be resolved from documents and samples. That prototype should answer one question and be disposable if the result argues against the proposed build.

The client needs to make estimating, prepress and production knowledge available. It also needs a decision owner who can settle a contested rule. If the existing MIS is undocumented, the output says so and limits what can be promised in the next phase.

Check the specification before building

Discovery is accepted against a document set and a review of representative cases. An estimator should be able to trace a quoted product through the written price rule. Prepress should be able to point to the output requirement that decides whether an artwork sample passes. Production should be able to read the order map and identify the job fields it expects. A decision owner should be able to see what has been deferred and the risk of deferring it.

The plan should also state which assumptions can be tested cheaply before a full build. A small interface spike can establish whether the MIS accepts the required job data. A specimen PDF can establish whether the proposed output route meets prepress's geometry and colour requirements. Those checks narrow uncertainty; they are not miniature products to be kept alive indefinitely.

Where several delivery phases are proposed, each phase needs a usable boundary and its own acceptance. A first phase might replace an order handoff while leaving the customer interface in place. Another might formalise pricing before redesigning configuration. The order should follow operational risk and dependencies, rather than the order in which screens look impressive.