Roadmap for Architecture

Question

Ok, I am a developer for 6 years now and I came from a hater to an enthusiast about technology.
I am a senior developer, almost all focused in web applications, asp.net, quite experienced and very, very focused in develop myself.
I come to a crossroads in my area, I want to become an Architect, not an analyst or a project manager. I like to get my hands dirty, to actually do things, and I, well,... have to admit it, that I am a little lost about what I should've already known, and what i should be studying, in order to enter in that field.
So here comes the question:

What an Architect should be proficient in?

Answer 1

Sales.

Architecture is all about selling a potential solution to folks who (a) trust you and (b) believe that what you're saying will work.

After that, you have to deliver.

But you'll never get to deliver if you can't sell the vision.

Answer 2

Understanding various trade-offs in different solutions, using different solution ideas, and getting both the big picture and being able to handle questions about some little details that may turn out to be a big deal with some plans.

Do you know how to build a large-scale web application? Do you know what priorities you value in a solution,e.g. ease of maintenance, scalability, reliability, simplicity, and performance to name a few? How well can you justify one approach over another? How many different design patterns have you seen or used? Those are some of the questions I'd consider if I was going to go down the road of becoming an architect.

Answer 3

I agree with both SLott and JB King; I'd also like to add a couple:

Negotiation: working out trade-offs is one thing, justifying it (politically) can be quite another. Similar to leadership in someways, but definitely a skill in it's own right.

Communication is the other one that goes hand-in-hand with that, leadership, etc.

Breadth: depending on the context of where you work, having a broad range of knowledge is useful even if you don't know the detail - as long as you know it's there and can refer to it when you need it.

Design Patterns: Interestingly, a lot of design patterns that you'd use at the code / class / method level also translate to higher levels of system design as well. Martin Fowler's Patterns of Enterprise Architecture is a good place to start - but there are many other good books and resources as well.

Reference Architectures and Frameworks: I found TOGAF helpful; even though it's aimed at the Enterprise Architecture level it has a lot which translates well down into the solution level. Knowing some relevant reference architectures is also a really good idea.

Other Architecture domains: get a feel for what some other specific architectural domain do,such as: data architecture and business architecture. Having a good grasp of these is helpful when your transitioning into solution architecture.