I am not aware of a standard (and in depth) definition of what a software architect is; other than it being the next step after team lead, and the last step before pure management (unless your company offers a research track - which nearly no one does). The interpretations I've run into are pretty varied. My way is certainly not the only way, and my way is an amalgamation of aspects of others that I admired.

For reference, I'm 36, have been programming professionally for 20 years, and have been an architect for 10. I seek out difficult projects.

Here are some (likely idealized) descriptions of my favorite past architects:

"Never say no"

My first architect took immense pride that at 40 something, he had never had to say no to a product manager. We were going to build whatever the business wanted, with no push-back (only what he called lateral guidance, or "yes, and"). The business would arrive with specifications, and he'd treat them as if they were rough drafts; "OK, let's get to work". He'd disappear into meeting with the business, and emerge days later with a nearly completely rewritten specification (which he had written himself and was usually more feature rich than the original), and everyone was happy. He explained to me after a few years that most bugs and development problems come from the blind-spot the business has for how software works, and the blind-spot development has for the business. A specification with no blind-spots is much easier to turn into software. Every project I worked with him on went smooth, and was delivered on time. I strait up stole and expanded his technique as the foundation of my architecture philosophy.

"Make me one"

I worked with an architect that insisted everything be built in-house (no unnecessary external dependencies). He'd look at the features of some other framework or tool, copy the bits he liked out of their documentation (as if they were requirements), and turn to us and say "now we're going to build our own". I loved this guy, he pushed me so far outside of my comfort zone that every day was a frantic adventure. "Write me a sketch; you have 4 hours". He didn't like whiteboards, he liked code and rapid iteration. He was brutally honest and ripped my code apart at least twice a day. We'd play code tennis for a couple of days, then a polish phase before QA. I was in hyper-focus for 8 hours every work day, and the practice at rapidly building (and rebuilding and rebuilding) all sorts of difficult components (that all made it to production) made me fearless. I lost that job to the 2008 bubble burst, but the year I spent there easily advanced my skill set by 5 years.

"If it's not fast it's useless."

I worked with an architect who came from systems programming. He had an incredible resume. He spent a lot of time refactoring for performance. If he liked you, he'd explain what he did to your code and why; if not, that code became his now. He spent a lot of his time in instrumentation, testing this solution against that solution for execution time and memory usage, merging the best bits, and testing against a different approach. His favorite phrase was "prove it" (and I spent a lot of down time trying to prove things to him through examples and instrumentation). I learned a ton in an effort not to disappoint him. It was no longer enough to know how to do something; I had to know many ways to do it, and which performed better in what scenario. "What, as an individual programmer, do you bring to the table if not performance? If your solution doesn't perform, you let everyone else down." He dramatically and permanently changed the way I code and the way I design applications.

"If it's not predictable I hate it."

I worked with an architect who's main focus was the application as it ran in production. He spent a significant amount of his time combing through debug logs and recreating log messag...