A technical boundary changes the price of a decision for the people on either side of it. One team can save operating effort while another inherits integration work. A shared review can make risk visible while leaving waiting invisible. Those consequences belong in an architecture review because they influence what teams will build next.
This is an application of the engineering-economics framework: examine who pays, who waits, and who can change the system. It is a diagnostic, not a claim that incentives explain every technical failure.
Follow the work across the boundary
Consider a hypothetical organization introducing a shared deployment service. The platform team owns the service and is measured on infrastructure cost. Product teams own release dates. Every deployment outside the standard configuration requires a platform ticket.
The platform team can improve its reported cost by narrowing the supported configurations. Product teams can protect their dates by keeping private deployment scripts. Both choices make sense inside their respective responsibilities. Together they can create a service with an efficient central budget and a growing amount of hidden consumer work.
The architecture diagram might show one deployment capability. The operating model contains several: the official service, the private scripts, and the people who translate between them. Counting only the first gives an incomplete basis for the next investment.
Inspect a real change request from request to completion. Record each handoff, each person who must supply context, and each waiting period. Keep elapsed time separate from active effort. The purpose is to locate a cost that the component budget cannot show, not to turn every conversation into accounting.
Make the desired behavior affordable
If the organization wants product teams to use a shared capability, those teams need a workable route through it. Documentation alone cannot compensate for a support commitment that conflicts with their delivery obligations.
Possible repairs depend on the actual constraint. The platform might support a recurring configuration directly. It might delegate a bounded decision to consumers. It might preserve an explicit exception whose operating cost remains with the requesting team. A narrower service with honest boundaries can be more useful than a nominally universal service that depends on private favors.
None of these choices requires removing common controls. Access policy, recovery requirements, and audit obligations may remain shared even when implementation differs. The economic question is where the control can be applied with a clear owner and acceptable coordination cost.
The CNCF Platforms White Paper describes platforms around users' needs and treats implementation ownership as a separate choice. That supports examining the consumer experience. The incentive analysis here is an editorial extension, not a measured finding from that paper.
Do not reduce people to a metric
A repeated workaround is evidence to investigate, not proof of rational optimization. A team may lack training. The documented route may already solve the problem. A temporary emergency may explain a departure that should not become permanent.
Read the request and the response before inferring motive. Then compare the behavior the organization asks for with the costs it assigns. If a product team pays for migration work while the platform alone receives credit for consolidation, resistance has a concrete explanation worth addressing. It still does not establish that the migration is wrong.
Likewise, a central constraint can be justified. A scarce specialist may need to review a consequential security boundary. The useful improvement may be earlier involvement or a smaller review scope rather than removing that review.
Add one economic sentence
For the next architecture decision, write a sentence naming the team that benefits and the team that absorbs the new work. Include who funds that work and who can resolve a conflict.
If those responsibilities are disputed, settle them before adoption makes the boundary expensive to change. The design is not complete when its components fit together. It must also describe a workable agreement between the people expected to operate them.