• Gain the respect from the developers actually implementing solutions. You should be able to jump in and get your hands dirty. Also you need to have a good working relationship with system or business analysts.
• Prove yourself on successful projects. Word travels fast when your design is good.
• Develop diplomacy skills. Lots of managers feel that architectural decisions from somebody else make them look technically weak. You need to find a way to sell the best idea, and cut through red-tape.
• Think big picture, think strategically, think abstractly. The challenge of a good architect is to be tactically and strategically proficient. Developers and managers often fall to either side.
• Read, read, read.
IMHO, "architect" and especially "*A*rchitect" became very overload terms when it reached the peak of being fashionable (about 5 years or so ago)
qualifiers:
and also with all conceivable (and not is conceivable
- software architect
- technical architect
- solution architect
- enterprise architect
- business architect
- web architect
- data architect
- UI architect (not joking, seen these
etc
luckily the fad faded out a bit…since "Web 2.0" and mobile apps many bright tech folks realised you can make reasonable amount of case without having architect in the title;-)
but all of these points you list are good stuff and
if you want more like that you will like this little book:
http://www.amazon.com/Things-Every-Software-Architect-Should/dp/059652269X
(but remember these are about "software architects" only…