Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I have been programming in .NET for the last 5 years. I have used design patterns a lot in our projects. I do have some domain knowledge in financial jargon. My ultimate goal is to become a technical architect. But the problem is that I am not getting the opportunity to do so in our organization.

My question is in such a case how should I develop myself for becoming a successful technical architect? Also I have read somewhere that domain knowledge does matter for becoming a architect. Can some one please clarify this statement?


migration rejected from stackoverflow.com Sep 17 '14 at 6:23

This question came from our site for professional and enthusiast programmers. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as off-topic by gnat, Dan Pichelman, Snowman, MichaelT, Bart van Ingen Schenau Sep 17 '14 at 6:23

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions seeking career or education advice are off topic on Programmers. They are only meaningful to the asker and do not generate lasting value for the broader programming community. Furthermore, in most cases, any answer is going to be a subjective opinion that may not take into account all the nuances of a (your) particular circumstance." – gnat, Dan Pichelman, Snowman, MichaelT, Bart van Ingen Schenau
If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers 3

I find the only way to become something is to do it. This does raise the usual 'catch-22' jollity of not being able to do the thing because you're not a thing-doer already, but that's life.

so, if you want the lovely, important-sounding job title then you'll have to find a way to get to do some architecture in your current role. Try a white paper type of email explaining (constructively) how your group could improve an aspect of the current system. If people like it, and can implement it, then you'll be a step closer to being an architect. Next step after that would be to mention career progression at your review and push for a more formal promotion to that type of role.

You will haver to get more knowledge than just .net development though. Architects have to know systems in general, system designs (not those little development patterns), you have to explain how to produce scalable, reliable, fault-tolerant, maintainable, supportable systems. Much of that work doesn't really involve development (ie an architecture like that could be implemented in .net, or java, or c++ or ruby on rails, the coding aspects is of much less importance).

Of course, I might be describing a systems architect role there, or a solution architect. Which just goes to show how useless these pigeon-hole names are. You could do what myself and possibly Mr Butterworth thinks - just do your job the best you can and not worry about what kind of job-title-buzzwords you have on your business cards.


How will you know when you're an architect? Do you want to do the work, or do you just want the title (and possibly the pay)? If you want to do the work, then start designing systems with an eye towards performance and integration. How well do they play with the other systems? Come up with decent estimates for resource utilization (how much CPU will your system need, how much network traffic will it generate, how much disk space will it need, does it need a dedicated database)? Figure out how to set up a build server and CM system and make them work together. Architects don't just design software, they design systems, and a fair amount of system design has nothing to do with how the software works.

If you just want the title/money, then brush up your resume and start applying for architect-level positions. You might want to try applying within your own company first, if that's an option for you.


"Architect" can be an extremely tricky term. Some companies use it as a job title, some projects use it informally to describe the key technical decision maker on the project. Also, I've seen architects that were strongest on the technical tools and architects that were strongest in the problem domain and therefore best at working out the business logic for features. If your skills don't match what your team needs from an architect it may mean that you are simply not the right type of architect for the team.

My favorite definition of architect has always been: "the person making the final call on decisions that could make or break the product". So I'll go with that one. Here's the qualities I look for when trying figure out who should be in an architect role:

  • Does the person have a sweeping knowledge of the technical domain? Are they aware of multiple ways to solve a problem and can they discuss tradeoffs between them. Are they up to date on new developments in the style of development/programming environment so that they can be making recommendations for when to seriously refactor the product?

  • Has the person been through enough rounds of development to have experienced appropriate level of learning through mistakes? I have a hard time calling anyone an architect if they haven't been through a full development lifecycle -- preferably 2-3 lifecycles, and preferably on more than one product. I want the architect to have been through enough tough situations that they can keep the team from making obvious mistakes.

  • Does the person have a good knowledge of the customer domain, are they in sync with other stakeholders - sales engineering, business development, actual users, systems engineers - anyone else who has insight and expertise in how the product needs to perform.

  • Can the person establish team trust? If the team itself cannot recognize that this person is a leading expert, then it's unlikely that the person can survive as an architect. A manager can name someone an "architect", but if they are not the person that the team naturally comes to bother with questions, then it's unlikely that the person will actually be able to enforce their decisions.

  • Can the person teach? The architect has to transmit vision and get people competent to make the vision happen. If the architect can't transmit his understanding to the team, the architect is more or less useless.

  • Can the person present to outsiders? The architect also has to be able to dumb down the technology for the big bosses and/or customers and talk in general concepts about why the product is good.

  • Can the person levitate between big picture and details? The person has to be able to see code and offer meaningful thoughts. Preferably, the architect even carves out a few hours to write code. However, he can't be mired in the details. He has to be able to leap out to a big picture view and have his eye on that at all times.

IMO, there's a lot of trust in putting someone in an architect's position. Engineers must trust that the architect is making the right calls. Management has to trust that the architect is seeing the best vision for the product. Customers need to trust that the architecture of the product is the best possible option for their needs.

It's also an opportunity availability thing. I've drifted in and out of architect roles for the past several years. It's not that I get better or worse at it; it's just that, depending on the current project, I may not be the best person to fill that role. There can be only one architect in a given area, so if your company has one already, you may be out of luck.