可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I have spent more than 3 years into dotnet (C#) programming and now want to look into the framework / design stuffs.

I have decided to become a good architect in future. I know that for this I need to work hard. I am ready to do so.

What I do not know is how to start with?

Could you people be kind enough in order to help me in getting the right stepping stone.

Thanks

回答1:

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.

回答2:

A real architect building real buildings will spend most of his time researching the building code, liasing with planning auhorities and discussing costs with the investors.

So a solution architect will spend most of his or her time ensuring that the solution complies with the various security and development standards at the site, complies with the enterprise roadmaps etc, and discussing budgets etc. and liasing with other teams defining interfaces and synchroning plans.

A real architect seldom gets the chance to be Richard Rodgers and build a substantial building on a new site for a client with deep pockets, instead they design "cookie cutter" houses for speculative developers, add extensions to exisiting buidlings or remodel old buildings for new uses.

In the same way the IT architect will spend most of his or her profesional life enhancing or replacing parts of an existing system within a limited budget, a limited timeframe and be severly constrained by the existing technoligy.

So my advice is to get a grip on the various standards and procedures where you work and try to get a handle on the architectural process as it works and the jargon as it is used in your organisation. If you were any good as a programmer you already know all the technical stuff you need.

回答3:

I personally learned most when I did refactor a big legacy system towards a modular architecture where you slice the old code into layers and glue it together with some dependency injection or other abstractions based on common architecture patterns. Like this you can see what are the common mistakes and why it makes sense to put effort into modularizing a system from beginning.

It all about building a system that can be maintained over time. Testability and modules are key!
You have to know about patterns, and see when they can help and why
" about different technologies used it the filed you work and how to glue them together
" about configuring a big system that it can be used in different contexts with minimal effort
" about tools that can measure a good architecture like pmd, findbugs in the java world
" about setting up a code, test, build environment which allows for agile development...
and many many more...
Architecture a system is a huge responsibility and if done wrong it can screw everything.

I personally would not let someone do any big architectural decisions without much less than 10 years experience.