I'm a big fan of #1 being "State the problem." rather than "Is this a 'Good Idea'?" they are inter-related of course, but any good software architect has their eyes fixed on the problem so they don't get distracted by the opportunities to 'decorate'.
I like asking people what they think the 'architect' does, that is to weed out people who think architect implies a leadership role, it can be but it isn't necessarily. In the 'real' world the architect is the person who notices you've got a banquet room for 100 people but the nearest restroom is two floors down, or a single hallway connecting both the people and the kitchen to the room. They see the 'whole' goal (feed large groups of people) and then work out what has to be true for it to be not a problem.
I look for similar skills in software architects, they don't care if the implementation is rails/django/node but they do care that individuals can be identified as users or guests, given capabilities or not, can be disabled or not, and the largest possible number are welcome.
Sometimes architecture is combined with the person who does design, sometimes with the person who does coding, and sometimes its just a person asking really good questions at the launch planning meeting.
That's too context-specific to answer without a whole lot more questions. Plus, if we're actually talking about code, physical metaphors break down anyhow. First-cut answer is "move bathrooms closer"/"make the hallway bigger" but one must also ask the question, "How did this mismatch arise in the first place?" Anything is possible, especially in software; the hallway may in fact be adequate and it's everything else that is grossly overspec'ed... or in fact, you might have ended up with a poorly-designed dining room for 100 people because that's all the previous guy knew how to build, when in fact you need a stadium for 100,000 people. (I've been there before.)
Ideally the architect is looking at a 'proposed' plan rather than what got implemented.
There is an entirely different (and very valuable) class of folks to can take an existing screw up and map out a series of steps to un-screw it up [1]. :-)
[1] I used to watch the New Yankee Workshop on PBS and see Norm cut lumber and then have it fit together so closely and smoothly that it practically didn't need glue. I suggested to my wife we could make a TV show which explored creative uses for a 2 x 4 that was 1/2" too short for its original purpose, or other parts that were made scrap by an imprecise execution of the 'cut to size' phase.
I'm a big fan of #1 being "State the problem." rather than "Is this a 'Good Idea'?" they are inter-related of course, but any good software architect has their eyes fixed on the problem so they don't get distracted by the opportunities to 'decorate'.
I like asking people what they think the 'architect' does, that is to weed out people who think architect implies a leadership role, it can be but it isn't necessarily. In the 'real' world the architect is the person who notices you've got a banquet room for 100 people but the nearest restroom is two floors down, or a single hallway connecting both the people and the kitchen to the room. They see the 'whole' goal (feed large groups of people) and then work out what has to be true for it to be not a problem.
I look for similar skills in software architects, they don't care if the implementation is rails/django/node but they do care that individuals can be identified as users or guests, given capabilities or not, can be disabled or not, and the largest possible number are welcome.
Sometimes architecture is combined with the person who does design, sometimes with the person who does coding, and sometimes its just a person asking really good questions at the launch planning meeting.