TL;DR

While domain knowledge is always useful, the Scrum Master is not expected to be a domain expert beyond the Scrum framework and organizational processes. The Scrum framework expertise is essential to being a facilitator and process referee. Organizational process expertise is essential to facilitating the team's progress in the face of organizational or process impediments.

Interpreting the "Remove Impediments" Guidance

The Scrum Guide entry for the Scrum Master role actually says:

Removing impediments to the Development Team’s progress

In my experience, this is often misunderstood. The Scrum Master isn't really responsible for solving the problem directly; rather, he or she leverages the Scrum Master's roles as facilitator and process referee to address the various impediments to progress that the team is facing.

Another way to say this is that the Scrum Master enables the team to be self-organizing, identify process impediments, and support the team's efforts to address those impediments. This isn't really a "momma bear taking care of her cubs" task. It's more of a coaching and facilitation task.

How This Applies to Your Example

[T]he team is blocked because requires a design decision from an external architect. The lack of this decision is blocking the progress on this task. At this stage, I see two options:

• The Scrum Master understands the problem and discuss the options (potentially suggested by the engineers) and discuss aspects with the architects
• The Scrum Master acknowledges the blocker and points the engineers to discuss with the architects

Neither one of these options is ideal. In the first option, the Scrum Master is acting alone, rather than facilitating, coaching, or empowering the Development Team. In the second, the Scrum Master is taking a hands-off approach rather than facilitating the discussion.

In the real world, both of these are actually viable. I wouldn't dismiss either of them out of hand in all contexts. However, a more framework-appropriate solution is generally to address the process issues, and to facilitate learning and self-actualization within the team. For example, I'd suggest the following:

1. The Scrum Master involves the team in identifying the blockers (in this case, the need for an external design decision).

2. The Scrum Master involves the team in identifying solutions at both the process level (during the Sprint Retrospective) and at the immediate blocker level.

   This two-level approach is critical. Even if the team gets the design decision approved or resolved this time around, the fact that the team is dependent on external resources is a fundamental process problem that should be addressed by the Scrum Team with organizational management, and should be taken into account during Sprint Planning and Backlog Refinement.

3. The Scrum Master facilitates a meeting between the Development Team and the architect.

   • "Facilitate" may mean coordinating the meeting, or simply pointing the Development Team to the resource they need to collaborate with.
   • "Facilitate" also means being present at the meeting, to ensure that there's a meeting referee and to gently steer the meeting towards a productive outcome.
   • "Facilitate" may also mean knowing the paths of escalation, should that be necessary.

4. The Scrum Master works with the organization to escalate issues that the Scrum Team can't resolve.

5. The Scrum Master works with the Product Owner to facilitate whole-team discussions about early termination when the Sprint Goal is at risk because of a blocker.

As you can see, at each step the Scrum Master is facilitating the Development or Scrum Team's actions, rather than simply handling it directly. As a member of the Scrum Team, it may be appropriate for the Scrum Master to perform tasks on behalf of the Development Team in some circumstances, but care must be taken to place the power into the hands of the whole team rather than the role of Scrum Master.

Conclusion

There's definitely a lot of things a Scrum Master can and should do to help the team. However, it's rarely beneficial for the Scrum Master to take either a hands-off approach or take unilateral action. The former isn't terribly helpful to less-mature teams, and the latter doesn't provide any learning or growth opportunities for the Development Team.

As a general rule, I'd extend the Scrum Master's core role as a facilitator and process referee to the task of removing impediments. Support the Scrum Team's efforts to solve its own problems by giving them the tools to do it, and then support them through that effort. That's the best way I know to help teams grow in maturity and process efficiency!