只是开发，还谈不上架构。
架构师本来就是程序员,只是专注于架构设计和实现而已.
级别初级，中级，高级
职位，职能，职责的区别与联系
================================
了解自己的兴趣爱好，特长优势，和发展的需要，清楚自己的SWOT,然后设定1年 3年 5的目标，不断改进。
既然是个Team leader了，看来是技术转管理的时机 >>System Architecture
天赋比努力重要，选择比天赋更重要，这一切都是相对于成功而言的。
在职业发展中，首先要了解自己的特长与特质。天赋，努力，兴趣往往是一个正循环，如果你的职业能发挥天赋，那努力的效率就会更高。
尽管“天赋+努力”会让你更快，但不一定是成功的充分条件，选择往往比天赋更重要。每一次选择都成为人生的转折点。在岔路口，要做好选择题，
没有选择时，要不断丰富自己的知识面，等待机会。
会考虑转型到管理岗
如果有选择的机会，而自己恰好又有想法和意愿，可以尝试。
尝试之后如果觉得不合适，或想更专注于技术本身，可以再转回技术岗。
技术专家与管理岗位有不同的要求
管理其实是从亲力亲为到放权，再到相互成就的过程。要用几年的时间来适应角色的转变，直到激发团队来共同完成工作。
对于管理者而言，放权与推动只是第一阶段，更高级的管理应该是相互成就，共同成长。
根据每位工程师的个人能力特点，分配不同的任务，让他们参与到决策的不同环节，激发潜力的同时，能最大程度地释放自己的压力与时间，去思考更高层面的内容。
每个团队中，因为成员的不同成长阶段，都可以分为4种人：人口，人手，人才，人物
人口需要培养，还不能独立工作
人手可以起到执行的作用，做一些日常的基础工作
人才更愿意去学习与挑战，也需要更多的成长与施展空间
管理者就是要分清这几种人，管理者的工作就是识人善用，并争取为他人提供进阶的机会。
没有完美的个人，只有不断走近完美的团队
技术服务于业务，业务服务于用户
=============================
我从事大中型企业的IT系统管理，和运维工作已经五、六年了。技术出身，目前也是个Team leader，管理着三、四个人。技术方面属于相对全面型，并没有在某一项技术领域里成为专家级别。今年28，想在这里请教一下各方面的前辈。做为一个IT运维管理人员，应如果规划自身下一下五年的职业生涯
前端开发人员在跟 UI (用户界面设计工程师) UE (用户体验工程师)配合的过程中，需要我们把绚丽的图片切成我们所需要的图片，这个时候就要掌握字体转换，图片格式，以及将 PSD 转换成一张张小图片供我们使用。这就是俗称的切图。
Team Leader
程序员
产品经理 product manager
算法工程师、研发工程师、软件工程师
系统分析员
系统分析员重点关注客户的业务，将客户的需求转化成类似用例图这样的表示，从而架起客户与系统设计人员之间的桥梁， 所以系统分析员要朝着客户业务专家的方向发展针对现有系统在业务/数据/组织结构等方面进行合理的分析和优化等功能, 就是能指出系统中哪些东西是好的哪些有问题等等.，比如专注电信行业、电力行业、金融行业等。
系统设计人员
系统架构师/软件架构师
系统架构师关注的是软件的骨架，就像设计大楼的设计师一样，把大楼的框架设计好，至于里面的分隔、装修等不是他的关注点， 所以系统架构师往往能够从系统需求（规格）书中很快的抽象出今后系统将会成为怎么样的一个系统的轮廓， 然后将部件、部件与部件之间的交互用类似UML这样的建模语言表达出来，供详细设计人员参照。系统架构师必须拥有相当的工作经验， 并善于从以往的项目中总结出各种设计模式并加以引用到新的系统中来。
系统架构师的主要职能是介于产品设计和开发设计的桥梁。
1、最终确认进入开发流程的产品设计或者需求。
2、给出系统的逻辑分层和层次之间的关系，这是架构设计的重点。
3、扫清技术难点，并给出解决方案。很多情况下，都要建立原型。
4、保证和监督架构设计被执行。
系统架构师首先是技术权威，领导力倒是其次，除非兼任项目经理的职责。但是系统架构师对沟通能力要求很高，这点真的很重要。因为不但要和产品经理沟通，还要和开发人员沟通，还要与领导沟通，甚至要去说服不懂技术或者精通技术的领导。
开发语言的选择，要有针对性的。什么时候用C/C++、什么时候用JAVA，什么时候用脚本语言，选择哪种开源项目。这些都需要系统架构师作出决策，要求系统架构师有足够的能力去评估。拿着锤子，到处是钉子，是个大忌。
没有最好的系统架构，只有最合适的系统架构。每一种系统架构都有他的适用背景和边界条件。也没有一成不变的系统架构，系统架构需要进化。
软件架构师可细分为应用架构师和技术架构师，应用架构是软件本身作为一个应用而存在的结构，技术架构是使应用能够运转的支撑架构。就像软件是为社会为生活服务一样，技术架构是服务于应用架构的。因此，要做架构师，不能只喜欢纯技术，还要学习尽可能多的领域知识。
浮躁只会让人一事无成。曾见过一些人，写了两月程序，就嫌写程序低级要去做设计，刚写了两月设计，就嫌设计低级，就要去搞需求分析，刚搞了两天分析，又觉得搞技术没前(钱)途，就要去搞管理或者搞市场。也见过一些人，搞了三月嫌工资低，跳一下涨点工资，再搞三月又跳跳涨点工资。跳来跳去，开始还能往“上”跳， 到后面是只能往被赶着往下跳了。
在软件工程中，架构师的作用在于三方面：
1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；
2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；
3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。
那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。
总结架构师自我培养过程大致如下仅供参考：
1、架构师胚胎（程序员）学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信（通信协议）——学习搭建应用系统所必须的原材料。
2、架构师萌芽（高级程序员）学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice（研究生可以研究网络计算机、高性能并发处理等内容）
3、 架构师幼苗（设计师）应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式（c++版本、java版本）、ejb设计模 式、J2EE架构、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。
4、软件架构师的正 式成型在于机遇、个人努力和天赋，软件架构师其实是一种职位，但一个程序员在充分掌握软架构师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技 能进行应用的合理架构、如何不断的抽象和归纳自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才这可不是每个人都能够遇上的馅饼……
绝 大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架 构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然 在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。
最近一段时间都在做系统分析和设计工作，面对的业务是典型的重量级企业应用方向。突然发现很多以往觉得很简单的问题变得没有想象的那么容易，最大的问题就是职责如何分配。论系统架构设计的最大的问题，其实也就是职责的分配，分配的合理，实现起来就会很柔性，反之就会使架构很混乱。
软件的生命周期大概可以归纳为四个基本的过程，分析、设计、实现、测试，当然这仅仅是一个最为粗略的表示而已。不同的方法论有着不同的使用这几个过程的方式。RUP使用快速迭代的过程，在这个几个子过程中适当的输出一些过程制品，每次迭代都是进行相同的分析、设计、实现、测试。而在Scrum中，不提倡输出任何文档形式的过程制品，也同样有着上述几个过程，强调以人为中心，通过沟通来解决大部分的问题。
不能用好与不好来判断哪一种方法论，只能根据目前的实际情况综合权衡。RUP的每次迭代中有几个关键的制品对系统分析、设计很重要，可以说是非常重要，如：词汇表、业务规则文档、用例、领域草图。这几个制品对分析、设计很重要，需要从这几个制品中提炼出设计模型最终才能落地。这主要用在业务复杂的应用系统中。而Scrum更加的轻量级，可以用在互联网项目中，业务不是太复杂的情况下。
其实我为什么要强调软件工程及开发方法论，是因为我最近发现，做设计其实是建立在分析的基础上的，但是这里面又有很多问题。大型企业级应用，并不能通过一次性分析就可以得出准确和全部的需求，初期阶段建立的需求70%都是不准确的。所以做架构需要有分析的能力才行且是建立在适当的开发方论上的分析，什么时候该用RUP，什么时候该用Scrum，什么时候该用XP都很有讲究。分析与设计都需要有一个执行上下文，不同的上下文对分析、设计的执行有着不同的要求。
有句话我觉得对架构者来说很有启发：分析就是做正确的事，设计就是正确的做事。架构跟语言跟平台关系不大，毕竟架构是设计过程中的子过程，我想如果你的设计不合理，你用任何语言任何平台都解决不了问题。（这里的架构上下文指：企业应用架构不是基础设施的系统架构）
运维架构师
运维架构师
系统运维
应用运维
游戏运维（页游，手游，网游的运维还是不一样的）
开区合区
网站运维（电商网站，门户网站，视频网站，社交网站的运维也是不一样的）
运维过多个项目（小公司，大公司的项目）
http://blog.sina.com.cn/s/blog_81cfb986010147os.html 提到架构师，大家都觉得挺神秘的，而作为运维领域的架构师，站在系统稳定和高可用、高扩展的角度，其承载着太多的责任和挑战。对于运维工程师来说，运维架构师就像是一个目标抑或是一座山峰。如何成为一名优秀的运维架构师？运维架构师应该具备何种职业素质？需要什么样的知识体系呢？ 运维架构师一词应该是与系统架构师、软件架构师、网络架构师、业务架构师不同的，虽然都是架构师，但侧重不同。在一个企业的IT系统中，运维架构师更需要具备开放的眼光，各种平台、系统、数据库、网络架构及后端存储设计都能随手拈来皆可组合， 运维永远没有一劳永逸的时候，不管是运维体系多么完善，也不管是自动化运维做的多么漂亮，我们面临的新问题仍然不少。随着业务的发展，从基础架构到高层应用，从系统扩展、架构调整、数据安全，需要架构师去思考的问题会越来越复杂，不断的创新和学习，将是一个运维架构师的重要任务。 从以上的分析来看，成为一个优秀的运维架构师，需要自我有一个良好的职业规划。首先你可以选择先做2-3年的系统集成，全面了解各种服务器、系统部署、网络架构、数据库、存储等，从具体的实施中去学习和了解系统、网络、数据库的特点和应用；接着你可以选择去知名的公司和企业做一个专业的运维，工作2-3年，并在工作中从运维工程师提升到运维经理，精深技术的同时积累自己的管理经验；再接下来你可以尝试去能接到很多运维项目并做IT解决方案的专业的IT服务公司，做一名架构师，利用已有的工作经验和积累，来具体解决各行业的IT系统架构和拓展的问题，如此发展和成长你就真正的成长为一名运维架构师了。
IT经理，可以说自己是项目经理，也可以说自己是开发经理，但是说架构师，是不是有点偏了？
产品经理
项目经理
项目经理一般是指软件开发项目经理，其关注点是开发计划的编制、计划的执行、计划的检查等，以按时保质开发出软件为终极目标， 但涉及面却非常广，既要有良好的技术背景，又要有与人沟通的能力（一般技术人员出身的人最欠缺的），要讲究一定的方法论， 但更要掌握管理方方面面的最佳实践。