NB: The original question was updated to reflect the Scrum-like and SAFe elements of the OP's environment, and shift the focus from "hierarchy" to decision-making within the different layers/roles within SAFe.
TL;DR
Within each Agile Team—they're functionally Scrum Teams, but are not really allowed to be called that because they deviate in some ways from formal Scrum—whether within a scaled framework like SAFe, Nexus, or something else, architectural and engineering decisions are team-level decisions that the Agile Team agrees upon collaboratively between the Product Owner, Scrum Master, and Develoeprs on the team. However, decisions that are cross-team and may impact the the whole Agile Release Train are the responsibility of one or more roles based on the specific SAFe Configuration in use.
When in doubt, ask the Release Train Engineer (RTE) for guidance. It's explicitly listed in their job description to shepherd the ART through the release train process, facilitate synchronization, and help resolve impediments. They can't help you with things they don't know are going on, though, so make sure your team is keeping the lines of communication open with the RTE!
Analysis and Recommendations
Team-Level Decisions
Since you haven't defined the scope or context of your specific issues, if they are team-level decisions then it is the Scrum Team's responsibility to align their architectural and engineering decisions with the rest of the organization during PI Planning. PI Planning is where the whole release train defines what the Program Increment should deliver through PI Objectives, and then each team builds its own plan on a Team Backlog on how they will deliver their own increments via Team PI Objectives and the team's own Definition of Done so their work can be properly integrated into the Program Increment.
In short, it is entirely up to each Scrum Team to define how they will do the work that aligns with the rest of the Agile Release Train. As long as the deliverable can be aligned with the rest of the work being done for the PI, no one outside the team really needs to be consulted.
Train-Level Decisions
This is where the answer is "it depends." Depending on your version and level of SAFe, there are multiple roles responsible for ensuring that the work done by each Scrum Team can be integrated into a cohesive Program Increment. These sorts of questions are generally addressed during PI Planning, but if they arise during the course of the PI then the Release Train Engineer is the person who can direct you to the appropriate resource within the Agile Release Train (ART) for answers.
However, as a general rule, there's nothing stopping teams from collaborating with one another. Agility is founded on communications and collaboration, after all!
If your work depends on another team's input or output, that should have been captured during PI Planning. If not, then talk to the other team to see how you can work together. This may be as simple as two Scrum Masters informing one another of unexpected dependencies, or as complex as setting up a meeting between one or more teams to coordinate work.
Of course, if the problem is big enough, the Product Owner and/or Scrum Master should be involving others within the Agile Release Train to resolve the concerns. That will certainly involve the Release Train Engineer, and may involve other roles as well.
"Enforcement" Isn't a Thing; Agile Teams are Self-Managing
In any truly agile framework, there's no "enforcement" in the typical command-and-control sense. Agility is based on collaboration and working agreements, and teams and release trains self-managing to the working agreements or collectively changing them when necessary. The whole Agile Release Train is involved in collaboratively defining a Definition of Done (DoD) for the ART and each PI, and individual teams are also able to define their own DoDs so long as they are aligned with the ART.
That doesn't mean there can't be standards, though. Some are agreed-upon Definitions of Done across the ART, while others are provided by the Solution Train in versions of SAFe that have more than one ART. System Teams and Shared Services teams (if present) may also collaborate or provide standards across an ART or Solution Train as part of the Architectural Runway required to deliver the PI Objectives, increments, or other enablers.
Again, if you're using SAFe at that level of complexity, involve your Release Train Engineer, who may then involve the Solution Train Engineer (STE) or other roles if needed. Anything above the team level really ought to involve the Release Train Engineer for your team's ART; that person may not have the answers, but the RTE is the right person to point you in the correct direction, or to raise systemic implementation problems like a lack of role ownership with the correct people.
Retrospectives
Working agreements and collaborations that aren't effective should be brought up during the Scrum Team's Iteration Retrospective (if not blocking the work) or immediately to the RTE if it is blocking.
There are also inspect-and-adapt opportunities within the Post-PI Planning Retrospectives and Innovation and Planning Iterations. The first is a baked-in event for all levels of SAFe, and the Iteration Retrospective should be baked into all Agile Team planning. Non-standard or urgent inspect-and-adapt concerns should be raised to the RTE immediately by the Agile Team (usually through the Scrum Master), but definitely not left to linger if the concern would block the team's planned deliverables for the Program Increment.
See Also
