How do I become a software architect?

TL;DR version:  There are courses you can take in UML and architectural thinking.   You can not start out as an architect - do another IT discipline first and when you are able to see the big picture, change to architecture if you like communicating a lot with others. [more info] If you work for a large company, they may have a defined software architect career path, often with a suggested set of courses to take and an indication of what experience is relevant.  IBM does this.     Note that software architect is not an entry level  profession;  you have to have done some other IT related work first and been able to see the relations between components other than your own. As you become more successful in software architecture, you will, as Tom Scott says, code less and less and draw many more diagrams.  A good portion of software architecture is not just designing a solution but communicating / selling  / explaining your design to the stake holders of the project.    Diagrams and pictures are a concise way of representing information and software architects use a lot of them.  There are standards you can learn (UML)and frameworks (TOGAF, DODAF) to provide a common technical vocabulary when communicating with other architects and no shortage of books on IT architecture, both in paper and online.  IBM has a nice series of redbooks and some good tooling for doing architecture (e.g. Rational Software Architect).  It's not that programming is not allowed.  The better architects I know see a project from conception to go-live implementation and often the architect will write small scripts to help out testing.  But an architect will rarely have the time to do real programming;  they'll be doing architecture and ensuring that the customer and developers stay aligned with the architectural vision.

Software architect is one of those titles that is nebulous in nature. I've held the title at a couple of large companies. Initially I was working as a senior programmer often being asked to lead teams as well as design software solutions and in that context reading as much material on best practices I could. My salary had reached the top level for that position and as such the VP I reported to saw more value in having me architect solutions then program. The next position I took was as a software architect - no programming allowed - based on the work I had been doing. Good communication skills both written and verbal, good understanding of all levels of the software stack and clear thinking are likely the skills that took me there. They are not always the skills evident in people in that position but by and large you need to be able to elucidate clearly a vision and the path to get there. Personally, I prefer programming to pure architecture.

You need 1) Experience in doing a varied number of things the right way     You need to have done a lot of differrent things, and do them the right way.      You can spend 20 years building web pages the exact same way, but you won't be an architect because all you know is how to build web pages. You might have spent 10 years building all kinds of innovative solutions, but most of the time you were either re-inventing wheels or building things that end up costing a lot more than they should. You won't be an architect because you are doing things the wrong way. The quality of your experiences matters a great deal     To be an architect, you should be able to take a crack any problem that the organization might face, be able to make build vs buy decisions. In case the decision is to build, you should be able to build it yourself (but you won't and will guide other people instead) 2) Ability to explain difficult concepts to a varied audience     You might be called upon to explain things to people. Sometimes, you are explaining things to the developer. Sometimes, you are explaining it to the technical CTO. Sometimes, you are explaining it to the non-technical CEO. You have to be able to understand where the person is coming from, and modulate your message to make it understandable to your audience     A lot of developers, even lead developers, struggle with this. When you have spent 6 years in college talking to developers, and then another 7 years at work talking with other developers, it's easy to train yourself to talk developer-ese. This means you are entirely incomprehensible to someone who doesn't speak your language. Unless, you start training yourself on translating concepts into language that makes sense to non-developers, it's hard to show people that you know a lot more than they think you do. 3) Authority to make people listen to you without having them think that you are an asshole   End of the day, it's easy to be mistaken as just another developer. Most people will assume you are a overpaid developer. It's easy, because they see you programming. You have to be able to say that your main goal is not to build stuff, but to show other people how to build stuff. You might be building stuff, so you can show people how to build stuff, but that doesn't mean that your main job is building stuff.   Also, non-technical managers might not be able to distinguish a highly skilled developers from average ones. You are speaking developer-ese, so they don't understand none of it.   Besides, no one reports to you. You have to be able to make people listen to you without having any sort of authority. How will you make the developers write better tests if they don't report to you? How will you make QA automate tests if the QA doesn;t report to you? How will you convince Project management to collect metrics when they don't report to you   Well, you can be the biggest asshole in the room. You can get things done in the short run, but no one is going to come to you in the long run   Or you can make the developers/QA listen to you. Techies recognize merit. They understand when someone is saying the right thing. Maybe not immediately. But eventually, if you say the right thing, and say it without insulting people, they come around. It's a slow process   Or you can convince the management. THis is easier said than done. Easier if the management is technical. Once you convince the managers, the managers can bring down the hammer for you. This last part is something that I struggle with myself. A lot of techies would agree with me:- talking to people is hard. Convincing people to change is a tough job. It's like a sales job. If I could sell, why would I be an engineer? In an ideal world, people would realize that they have a problem, and they would come to you with the problem, and you will give them this nice solutions. However, most of the time, a problem exists because people don't see the problem as a problem, and you have to work on convincing them to change the way they think.

Its more of a decision making process with lots of technical knowledge in programming,software engineering ,system analysis and design. Experiences are highly matters in this kind of profiles. check: https://www.sei.cmu.edu/architecture/research/previousresearch/duties.cfm

Since you are not Software Architect, lets start with the Starting point. You should target the role of an Application Architect. You should have an understanding of 1.Design principles (Could vary with the Type of programming you decide to use -Object Oriented, Functional) 2.Design Patterns(Could vary with the Type of programming you decide to use -Object Oriented, Functional) 3.Various Frameworks available for various components of your Application 4.Capability to do a modular design. 5.A good understanding of Software engineering practices. And their importance. 6.Capability to work in Uncertain environment, and take calls with the available information which might not be enough.(All engineers need to do that). 7.Good understanding of How various Software tools work. 8. Good analytical skills to understand business requirements and develop high level design based on requirements. Then there are certifications offered by various organizations.

My answer to a similar question:

Not exactly the answer, but may help you to understand what is the role of a software architect and how to become a good one: http://www.yegor256.com/2014/10/12/who-is-software-architect.html