Hi I have been a developer for approx 10 yrs. I want to know how can I consider myself to be an archtect level techie? How can developer move from code level development, to architect?
I obviously want to move up the tech ladder, and architecture seems appealing.
A second question would be, how do I learn about application architecture (big picture), in terms of 3.5 framework?
Any advise is appreciated.
There are two criteria for being a software architect:
(1) You have to call yourself one.
(2) You have to convince someone to pay you to architect software.
Everything else is just scaffolding. If you're good at "big picture" development and planning, try to sell yourself as an architect on your next job search. If someone buys it, you're an architect.
Being an architect is nothing more than a state of mind. There are potentially bad connotations that come along with having status of Architect. Particularly because nobody can truly answer the question, "What is an architect?"
First and foremost...
If so, that is something to work towards I guess... but how does one work towards it by just "drawing up solutions"? Practical experience is prerequisite and must. A truly good programmer ultimately has good problem solving skills. A good problem solver ultimately knows how to construct good solutions.
In my opinion, if one focuses on becoming an excellent programmer, the problem solving skills naturally start to develop. It's unavoidable that this will get recognized. Once recognized, people will start to ask for opinions on the best ways to solve problem X. When one starts getting asked these types of questions, one inherently become an architect.
In corporate organizations, one can move up to this state of mind and potentially have a physical title (and potential pay) to represent this state of mind. But we must not forget that it requires ACTUAL development of good solutions to problems. This is what ultimately brings us to this state of mind.
In the end, it's just a word that tells very little behind the person carrying the title.
At the risk of exposing myself to the nitpickers and word-parsers,
Being an "Architect" means you have to be able to design software "Systems", consisting of multiple "components" working together in a loosely coupled way to solve some fairly complex business problem, and be able to "lead" or "mentor" other developers in constructing said system.
In addition to being expert on the technology(ies) necessary to solve the problem, this also means you have to be able to understand the business problem at issue, from a business perspective, and be able to communicate fluently about it both with the business domain experts (using their language) and with the developers who will be constructing the components (in their language)
I think you're asking how to move up the career ladder within a company, and that's a different process than previous commentors are discussing. It's also vastly different from one company to the next, but there are still skills and practices that are important across the board.
The most obvious thing is breadth of vision. You have to be familiar with all of the parts of the system you are discussing. That means you have to have a desire to work on different areas of the code, even though you don't know as much about them as the area you've been working on. You have to be willing and able to help other people with stuff you know. That doesn't mean pushing your info onto them, it means answering helpfully when they ask. If your advice is helpful, people will come to you. The obvious place to start with this is helping the people who have taken over responsibility for something you've recently moved away from.
Architects talk to people working on other projects, both because they've been asked their opinion about that other project, and because they figure out who the other experts are and ask them questions when the other person has more experience in an area.
And of course, the code and projects you leave behind speak for you. If your code isn't readable and robust, then it won't matter how many projects you've visited. Your own work has to be impressive as well.
If you have to ask the second question, you are not yet ready to be an architect.
Read and write code. Be a generalist, not a specialist. Take a look at an overview of 3.5, and make sure you have done something in all areas. Just enough to recognize the problems and know where and to whom to look for answers. Take a look outside .net and see how similar problems are solved in other environments (cocoa, java, rails, glass, LAMP, delphi, flex)