I mean...
I'm looking for concrete advice, especially from your own experience!
Stop doing anything that might be misconstrued as "useful" and get some metal business cards pressed with your new title.
I would say be careful of the developer/architect divide. A good architect is a good developer. Good architecture means you have lots and lots of solid coding experience and have learned what works and what doesn't. That learning never stops.
I would not "stop" reading programming books but I would pick up some pattern books. Even developers are served by reading those. I'm on the MS platform too, but good technology and tools transcends any one vendor. Defenately broaden your horizons beyond MS.
Why do you want to be an "architect"? Your other post asked about being a PM at Microsoft? Which do you want to be? Or are you just trying to spam the site tonight?
Software architects primarily design at broader and higher level than software developers. They perform analysis and design, but typically don't perform much implementation, instead providing guidance to the developers to perform that step. They also decide how to interface different systems, and create guidelines for designing and developing applications.
Everything you know as a developer is important, but it's good to learn architectural patterns in addition to design patterns. A Google for "architecture patterns" yields a pretty good selection of materials. And if you'd like to perform any system integration architecture that uses messaging, the book Enterprise Integration Patterns is a good read.
Here's how I moved from programmer to architect.
I was at a client site.
The client said, go to these meetings and work out the architecture we're supposed to implement.
Nothing else changed. I was still designing more and programming more. I was still reading programming books and architecture books. (I never used Microsoft Technologies). I was still detail-oriented and I was still overview-oriented.
It's all about balance and what's necessary.
It's all about perception of the client.
In preface to this answer, there are different notions of what people mean by the term "architect" as it pertains to software development. The Wikipedia article on software architect offers a pretty good overview of the different definitions. Unfortunately, the article does not yet address the emerging concept of the "Agile Architect", a concept born out of the recognized incongruity between the role of the traditional Ivory-tower/UML-only/Zachman Framework-esque architect and agile development. In addition to the different notions of architect classification, there exists varied opinions on how well the concept applies to software development as a whole. Moreover, a distinction can be made between the formal role/title of architect and the process of software architecture.
How one answers the question of "how to become an architect" really depends upon both the classification of architect you are referring to, and one's philosophy toward software development in general.
I ascribe to the view that all software development concerns software architecture and therefore that all developers fall somewhere on a spectrum of architecture skill. The point at which you become qualified to serve in a formal architect role within a company is somewhat arbitrary and varies wildly between companies, so I'll limit my answer to attempting to provide some avenues you can take to become better at the process of software architecture.
First, pursue a firm understanding of the basics. For those working in Object-oriented development environments, this means having a good grasp of encapsulation, inheritance, and polymorphism.
Second, pursue the study of software design principles. A great book for those specializing in .Net development is Agile Principles, Patterns, and Practices in C# by Robert and Micah Martin.
Third, pursue the study of design patterns. A great starting point is Design Patterns : Elements of Reusable Object Oriented Software by Gamma, et al., and Patterns of Enterprise Application Architecture by Fowler.
Forth, pursue the study of domain modeling philosophies. A must read is Domain-Driven Design by Evans, but a shorter introduction to the concepts contained therein can be found in Domain-Driven Design Quickly.
While pursuing these areas, get plugged into the development community. In addition to reading books on software architecture, seek out good bloggers who write on these topics, get involved with local events like user groups, code camps, etc., and consider even starting a blog yourself. For many, writing about a topic is the best way to learn.
Most importantly, write as much code as possible. Architecture is about software design, and What Is Software Design but the production of working code? You can read about, talk about it, blog about it, tweet about it and draw pictures of it, but if you don't write code then you are like a painter that doesn't paint, but only philosophies about painting. If you want to be good at it, you have to do it.
Along this journey, you'll tend to pick up other skills that will contribute to better software architecture, like being exposed to various techniques for discussing/representing software architecture, development processes which contribute to better architecture, and tools which you'll need to actually do the job.