I used to be a lead developer who had to make most of the design decisions, be responsible for requirements, quality, etc. - a kind of de facto architect. I suspect this is typical for many lead developers as they meet the need for architecture without an architect. So in a way I was an "architect". But now I'm actually an architect I find that what I used to do was really only the tip of the iceberg and my "style" has changed notably.
As a lead developer responsible for the architecture I would naturally design systems that played to the strengths of the development team. As a result, the code would be high-quality but the technology selection not necessarily best-of-breed. It was easy to stagnate even while continuing to deliver successful projects as the design decisions were driven by what the team was proven to be successful at delivering. Technical authority stemmed from you and your team's ability to develop high-quality, functioning code in more or less the same way time and again.
As an architect it would appear that relying on your own existing capabilities is not sufficient. Indeed, it's probably a sign that you've missed something - how can you be an authority in a field as diverse and volatile as software development without having learned something new recently? Part of the role would appear to be to embrace the unfamiliar and make it accessible to those tasked with delivery. Technical authority may therefore come from research and intuition as much as experience.
Contrary to my expectations, I've found that being separated from the development team has made me more tolerant of their mistakes, despite being less able to address these mistakes directly. This I attribute, in part, to being better able to see the value of less costly development. Of course, this is not to say that code quality, mentoring and review aren't still very important! However, I find that I'm less exacting and more pragmatic - if I were to press for the quality that I'd deliver myself (as a lead developer) then I'd be negating some of the cost benefits of having got someone else to do it in the first place! As a lead developer I knew when things weren't up to scratch and I'd do something about it; as an architect I have the context and obligation to determine when things are "good enough" and be confident not doing anything about it. Sure, it's frustrating not being able to roll your sleeves up and show everybody how it should be done ;) but there's also satisfaction to be taken from making a call on whether something's fit for purpose.
It's been my experience that the formal role of architect is considerably broader, deeper and less familiar than I anticipated from my experiences "architecting" as a lead developer but I'm finding new abilities taking on these unexpected challenges.