Stakeholder Analysis
Identifying who is affected by an architecture, what each of them needs from it, and how much influence they have over whether it proceeds.
Architectures fail for non-technical reasons more often than technical ones, and almost always because a stakeholder's concern was discovered late.
The mapping is simple and rarely done: list who is affected, what each one cares about, what they can block, and how much they need to be involved. The classic grid is influence against interest — high influence and high interest means manage closely; high influence and low interest means keep satisfied, because they will notice at exactly the wrong moment.
The stakeholders most often missed are the ones with veto power but no seat: security and compliance (who can stop a launch late), operations (who will carry it and were not consulted), finance (who approves the run cost), legal and procurement (who set the timeline for anything bought), and the support organisation (who absorbs whatever the design gets wrong).
Get their constraints during design, not at the review board.