Update: the two links are both broken, I will try and find some replacement content but in the meantime this page has a list of different architect types, FWIW: http://en.wikipedia.org/wiki/Systems_architect
~~~~~~~~~~~~~~~~~~~~~~~~~~~
It depends what you call "Technical Architect", as well as where you want to go.
Also, your experience (as far as you've described it) is programming / software related, so the term "Technical Architecture" might not be exactly what you're after.
As I understand it, a Technical Architect is concerned more with standards are so forth, as opposed to a Software Architect which who would deal more with code and design patterns.
My general advice to you is this:
- Research: read books, articles, blogs and (most importantly)...
- Interaction: talk with actual architects about what it is they do and how they got there. Sure you can ask questions on forums like this, but a deep thorough discussion is what you're after - and not just one or two. One way of doing this is to...
- Join a local architects forum or community group in your area, or attend the odd talk. Big conferences like Tech Ed will have an architectuire track - so keep an eye out for interesting topics.
- Bide you Time: I landed the formal title of "Solutions Architect" after 8 years in software development, which is probably on the fast side; so prepare yourself for a long but "deep" journey.
- In terms of domain do you want to stay in software or move into infrastructure? Security specialist perhaps? The only way to know is to get your hands dirty on a few of them; and having a lot of little bits of wide experience (such as in infrastructure, security, data) does nicely augment a deep "center of gravity" in something like software architecture.
Things to consider on the way:
- Being an architect isn't just about coming up with technical solutions to technical probelms, it's also (at least half) about "soft skills"...
- Leading development teams / project teams, advising project managers; they'll be looking to you for guidance.
- Resolving ambiguity, dealing with conflicting needs. analysis of business problems, etc.
- Thinking outside the square and asking (re-asking) the basic questions, e.g: Question: "What's the best way to do X?", Your Answer: "Why do X in the first place?"
FYI, "Aspiring Architects" is a favorite topic of mine.
Update Jan 2017 - finally updated the broken link (content written in 2010!), and in addition added a new one regarding how to define architecture-roles.
