Handling Requirements from Architects Outside the Team

I was recently asked what I thought about using the "Wise Architects" in a company to provide technical oversight to the multiple teams on a project.

A common objection to this is that the architects are outside the team and should not, therefore, have any say in how the team builds whatever it is that they are building.

This argument doesn't hold water, though, as there are other outsiders who provide requirements to the team. But those requirements are always filtered through a product owner who decides whether they are important or not.

An organization's Wise Architects often provide requirements to a team in the form of non-functional requirements. I think of non-functional requirements as "constraints" on how a team solves a problem. So the Wise Architect cannot tell a team how they solve a problem, but can provide constraints on how it's solved---the system must scale to a certain number of concurrent users, it must process this many transactions per minute, it must run on Linux, it must integrate with our such-and-such, etc.  Non-fucntional requirements become product backlog items and can be prioritized by the product owner based on how important the product owner views compliance with each. For example, if a product owner decides that running on Linux is not critical and the product could be just as successful on a different server OS, the product owner would remove that non-functional requirement or perhaps place it low on the product backlog so the team is at least aware the architect wants it.