An architecture proposal can be technically sound and economically incomplete. The missing part is often the work outside the component: waiting, coordinated migration, duplicated interpretation, or the cost of preserving a future choice.
Five lenses help expose that work. They are a way to compare consequences, not a formula for assigning a monetary value to every engineering decision. Use them on a specific outcome with named consumers and a plausible alternative.
Flow: find the step that limits the result
Start with the work that must finish. For a hypothetical data product, that might be a product engineer shipping a feature using a governed dataset. Faster ingestion helps only if ingestion is what currently prevents that outcome.
If the engineer is waiting for a definition owner, another ingestion worker cannot answer the unresolved question. It may make more data available without making that data usable. Trace the path and find the limiting transition before choosing the investment.
The limit can move after an improvement. Treat the diagnosis as a statement about the present system rather than a permanent ranking of teams.
Google's Handling Overload chapter documents why request counts can misrepresent capacity: different queries consume different resources, and those relationships can change with a software version. Its recommendation is to measure the resources that constrain the service. This provides a concrete technical example of the flow lens. Extending that reasoning to a team's decision queue remains an analogy; people are not interchangeable servers, and request counts alone cannot establish the staffing needed.
Option value: specify the future decision
A portable format, coexistence period, or stable interface can preserve the ability to change direction. That ability has a present cost: extra testing, operational work, or limitations on the first implementation.
Name the event that would make the option useful. A likely change in access pattern may justify keeping a storage boundary replaceable. A purely hypothetical requirement with no consequence attached may not justify supporting two complete stacks.
An option also needs an exercise path. Keeping an export function does little if nobody has checked whether another system can interpret the exported data. A bounded rehearsal can establish more than a broad promise of portability.
Coordination cost: count affected roadmaps
Suppose a shared event service changes an internal component. If every producer must update its client and every consumer must deploy in the same window, the migration contains many separate commitments.
The work includes scheduling, compatibility testing, support, and recovery coordination. A component comparison that includes only the platform team's effort will miss those commitments.
Coordination is sometimes necessary because the meaning of the contract changes. Distinguish that work from migration caused only by an implementation detail leaking into consumers. The latter is a candidate for a better boundary.
Externalities: locate the unpaid work
A local saving can move effort elsewhere. Reducing platform support might require each product team to maintain a specialist. Compressing retention might reduce storage cost while forcing consumers to rebuild their own history.
These are hypothetical mechanisms, not reasons to reject either change automatically. Write down who inherits the work and compare the total consequence. The decision may still be worthwhile, particularly when a rarely used guarantee is expensive to maintain.
An explicit transfer can be reasonable. An invisible transfer makes the business case unreliable and leaves ownership to be negotiated during an incident.
Cost of delay: state what waiting postpones
Waiting matters when it postpones an outcome. That might be learning whether a product hypothesis is useful, retiring an unsupported dependency, or removing a recurring manual obligation.
Avoid turning an uncertain future into a precise revenue estimate. Describe the consequence first. Identify the deadline or condition that makes delay costly, the evidence behind it, and whether a smaller step could produce useful information sooner.
A rush can also create future delay. A design that ships this week but requires many synchronized migrations later may merely move the queue. Compare the next meaningful outcome and the commitments that follow it.
Use the lenses together
For the hypothetical data product, the next investment might be a clear definition and support owner rather than a faster pipeline. A small contract could reduce coordination while preserving the option to replace the storage engine. A staged adoption could produce feedback before committing every consumer.
The CNCF Platforms White Paper recommends choosing platform capabilities around stakeholder and user needs. The five-lens review adds an owned conceptual method for examining the economic consequences of that choice; it does not supply a universal financial model.
The lenses can disagree. An independent consumer interface may reduce coordination while increasing the platform's compatibility work. A shorter migration may reduce present delay while removing an option the organization still needs. Preserve that disagreement in the record. It identifies the actual tradeoff and the owner whose capacity determines whether the proposal is workable. A single composite score can obscure this information, particularly when some costs are observed and others remain uncertain. Use the lenses to expose the decision, then make the judgment explicitly.
A small local change does not need a lengthy business case. Use enough detail to expose a material tradeoff. For a consequential shared decision, attach the reasoning to the technical proposal: intended outcome, present constraint, valuable option, coordination burden, displaced work, and consequence of waiting. Then select the smallest investment that addresses the constraint while preserving the options that actually matter.