Here are some of the quotes and ideas on the topic at hand - "How to become an Architect"
"-Gain the respect from the developers actually implementing solutions. You should be able to jump in and get your hands dirty. I've also found that 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 architecural [sic] 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 abstactly [sic] . The challenge of a good architect is to be tactically and strategically proficient. Developers and managers often fall to either side.
-Read, read, read. "
"Wether [sic] you use the term 'architect' or use another term I believe there is a need for a role where the end responsibility lies for the structure and *-ilities of the things you're delivering. "
"I have spent long hard hours thinking about this question :-)
My business card states exactly what I do . . . . I make stuff happen"
"For this discussion, I would also add that the architect must be a leader. Architects rarely have enough authority to truly enforce conformance to their architecture. I've never seen a single system blocked from going into production just because it didn't fit enterprise standards. That means the architect, if they aren't on the individual project teams, work through influence, not control. Hence, the need for leadership and earned (not demanded) respect. "
"The best way to become an Architect is by listening.
- Listen to your business customer. At the end the day your designs are only good if it meets his or her needs.
- Listen to developers. You may have the best blueprints, but they are worth nothing if you don't have developers on board to build them. "
"Being an architect is not about kissing ass with your managers. A lot of times it is about putting
your neck on the line for your developers and explaining to your managers that certain decisions
are detrimental to the project, that a schedule is unreasonable and will result in failure and so on
Lastly an architect should be very approachable. Developers do not like architects with an attitude. Such architect tend to create distrust for their own skills. Be there when your developers need you and please can that attitude. This helps team building and promotes a spirit of cooperativeness. Even the most hardened 'protect my territory' developer will come around if the architect is a approachable sharing member of the team. The cluture [sic] of a team is defined by the attitude of the architect."
Boiling it down to the key aspects . . . .
- An architect *must* code to gain the respect of developers and be approachable
- You must prove your ideas are successful and that you can "get it done"
- The (technical) buck stops with the Architect
- Architects succeed through influence not control
- Architects must listen to their two key audiences - the users and the developers
In a sense, being an Architect isn't all about being in a position of power, it's more a position of overall technical responsibility and also serving the needs of your users and your development teams. The concept of "Servant Leadership" is a bit overused on the 'business motivation' circuit but there's a good grain of truth in it. When you realize you can't really control (free) people, you also realize your 'leadership' role then becomes one of enabler rather than enforcer.