项目经理与架构师.doc

项目经理和架构师一、软件项目经理兼职架构师的无奈 1. 国内似乎流行软件项目经理兼职架构师2. 其实大家都知道软件项目经理不是架构师3. 合格的架构师凤毛麟角4. 为了保证项目成功，还是由软件项目经理兼职架构师吧1. 国内似乎流行软件项目经理兼职架构师软件项目经理兼职架构师，在国内的软件项目中随处可见。一个项目，不管是2、3个人的小项目还是10多人的大项目，大多数软件项目经理都是一把抓，亲自参与程序的设计和核心代码的编程。不光是小公司，国内知名软件企业不少项目也是这么干出来的。2. 其实大家都知道软件项目经理不是架构师这种现象历来有不少所谓的管理大师对此大加批评。大师们总是提出项目管理理论证明项目经理兼职架构师是管理不善，是决不可取的；并经常举出IBM、微软等例子证明他们的观点。对于这种纸上谈兵的论调，笔者颇不以为然；这种废话也并非什么高深理论，其实大家都知道软件项目经理不是架构师。3. 合格的架构师凤毛麟角出现这种现象的真正原因其实很简单。因为几乎找不到合格的架构师所致现在不单是小企业，就是国内知名的软件企业也奇缺合格的架构师。合格的架构师一般要求有8年左右的软件开发经验，而且要具备非常强的技术能力。笔者提出软件项目经理技术能力100分应该有80分左右（软件项目经理需不需要懂技术/blog/static/31017001200751453125410/），架构师则应该有90分以上。以这个条件，想找合格的架构师，难！当然，牛人也有，而且大多数牛人远比这个条件优秀的多，可惜的是他们都已经是技术总监或者首席架构师了。4. 为了保证项目成功，还是由软件项目经理兼职架构师吧在这种情况下，具有5年左右开发经验的项目经理当然应当承担构架师的责任。不然谁敢让1、2年经验的员工去冒险？所以，项目经理兼做架构是现有国情下的正确选择，绝对是明智的；如果项目经理让经验不足的开发人员勉强去做架构，那才是项目经理的失职如果出现这种情况，高层管理者应当反思是不是找了个冒牌货。说到这里，相信大家不难明白为什么IBM、微软能够职责分明的原因了。二、架构师之路/系统分析员、系统架构师、项目经理的区别架构师（Architecture）是目前很多软件企业最急需的人才，也是一个软件企业中薪水最高的技术人才。换句话说，架构师是企业的人力资本，与人力资源相比其能够通过架构、创新使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师、架构师的作用、如何定位一个架构师和如何成为一个架构师呢？这是许多企业、许多程序员朋友希望知道的或希望参与讨论的话题内容。 所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。 在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。 与建筑学类似，如果软件系统没有一个好的架构是不可能成为成功的软件系统的。没有图纸的建筑工地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是，软件工程中亦然！ 由于国内合格、胜任的软件架构师极为少见，直接导致了我国民族软件产业水平的落后。在未来以信息产业为主导的社会，信息产业水平的低下将直接影响国家核心竞争力。究其原因，无企业非急功近利、个人缺乏引导。 企业的急功近利是有无法克服的原因的，那就是社会发展总体水平。“生存是第一位的，赚钱是第一位的”，多年来许多客户抱怨国内的软件公司无法信任、系统项目累做累败、公司越换越差，但因国外不可能给中国做应用系统项目还不得不找国内软件公司做。由于人月费用低、公司开发成本高，软件企业对于应用只能草草了事，拿钱走人（很多公司拿不到后期尾款）。这样的环境下，企业几乎无法投入更多资源培养自己的架构师，加上眼花缭乱的跳槽风气企业更是不愿投入 那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。关于软件学院我接触过不少，其宗旨绝大部分都是造就（or打造）企业需要的软件架构师（or程序员or人才）。教师来源与企业、学员来源与企业、人才输送到企业是他们办学的手段。尽管各个如雨后春笋般出现的软件学院口号差不多，但恐怕大多只是为了圈钱卖学位了事. 架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考： 1、架构师胚胎（程序员）学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c+、uml、RUP、XML、socket通信（通信协议）学习搭建应用系统所必须的原材料。 2、架构师萌芽（高级程序员）学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice（研究生可以研究网络计算机、高性能并发处理等内容） 3、架构师幼苗（设计师）应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式（c+版本、java版本）、ejb设计模式、J2EE架构、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。 4、软件架构师的正式成型在于机遇、个人努力和天赋，软件架构师其实是一种职位，但一个程序员在充分掌握软架构师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理架构、如何不断的抽象和归纳自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才这可不是每个人都能够遇上的馅饼 然而学海无涯，精力有限，个人如何能够很快将这些所谓的架构师知识掌握？这是秘密，每个人都有自己的独门家传秘笈就不敢一一暴露了。不过有一点就是广泛学习的基础之上一定要根据个人兴趣、从事领域确定一条自己的主线来努力。如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。所以我们希望在软件系统构建过程中，人和机器发挥各自的长处，也就是说，让人来扮演架构师的角色，而让机器来扮演程序施工者的角色。事实上，目前已经有了成功的模式了，那就是KCOM 商业工程（）企业应用平台所采用的基于设计的全自动化软件工厂模式，采用这种模式，架构师在工具平台所提供的模型图设计环境里做软件系统的设计，设计结果由工具平台自身所带的“软件工厂”自动加工成最终企业应用软件系统。这样的开发模式，能使企业应用软件系统的开发在效率、质量上有了质的提升，从根本上区别于传统的设计模式，因为这里的设计模式已经包含在软件工厂编译器之中了。系统分析员、系统架构师、项目经理的区别系统分析员重点关注客户的业务，将客户的需求转化成类似用例图这样的表示，从而架起客户与系统设计人员之间的桥梁，所以系统分析员要朝着客户业务专家的方向发展针对现有系统在业务/数据/组织结构等方面进行合理的分析和优化等功能,就是能指出系统中哪些东西是好的哪些有问题等等.，比如专注电信行业、电力行业、金融行业等。系统架构师关注的是软件的骨架，就像设计大楼的设计师一样，把大楼的框架设计好，至于里面的分隔、装修等不是他的关注点，所以系统架构师往往能够从系统需求（规格）书中很快的抽象出今后系统将会成为怎么样的一个系统的轮廓，然后将部件、部件与部件之间的交互用类似UML这样的建模语言表达出来，供详细设计人员参照。系统架构师必须拥有相当的工作经验，并善于从以往的项目中总结出各种设计模式并加以引用到新的系统中来。项目经理一般是指软件开发项目经理，其关注点是开发计划的编制、计划的执行、计划的检查等，以按时保质开发出软件为终极目标，但涉及面却非常广，既要有良好的技术背景，又要有与人沟通的能力（一般技术人员出身的人最欠缺的），要讲究一定的方法论，但更要掌握管理方方面面的最佳实践。常和好友孙向晖探讨软件开发之道，他把我作为架构师推荐到程序员杂志，提笔良久却不敢下笔。虽然多年来一直负责开发浪潮软件的企业应用架构，却总觉软件架构师在软件行业中是一神圣的称号，所以不敢随便妄称架构师。 本文叙述了笔者工作以来的历程，穿插谈谈工作以来的一些关于架构师的体会。尚在大学时候，非常崇拜那些技术天才，特别对求伯君前辈等以一己之力编写著名软件的前辈豪杰等佩服得五体 投地，期望有一天也能像他们那样成为大侠。无论黑天白夜，挥斥键盘程序人生，累了可以游戏中十步杀一人，何等自由与潇洒？ 毕业后到公司，有了机器，抱床被子到办公室，静躺着躲过12点钟保安手电的扫射检查，就可以在里面通宵奋战了。两个月时间,也终于把自己打造成气质癫狂、头发蓬乱、脸色苍白、双眼通红、键盘敲得满屋响，具备技术高手的一切外表特征的狂人了。和大多数新工作的程序员一样，那时是比较喜欢搞纯技术的工作，隔壁办公室还有另外一位气质癫狂的战友，和我一样喜欢键盘敲得满屋响，闲暇时候常聊些技术话题，也都对写数据库的增删改程序比较深恶痛绝，觉得比较俗。 不甘于平静的生活，决定跳槽去淘金，新去的公司使用Lotus，在这个公司持续了短暂的两个月的通宵奋战。对Lotus学得也算小有心得。(回头想想，如果没有工作前几年的知识积累和对技术的狂热，我或许永远也走不到现在这条路。) 对技术的狂热兴趣和爱好，不仅对于架构师，而且对于想做好任何工作的人都是必要的，只有对真正感兴趣的工作，方能做得出类拔萃。转眼间风气云涌，.COM泡沫正起，BS开始大行其道，试用期没有结束就辞职开始了短暂的创业经历。头是个为了搞个程序可以几天不合眼的人。他认准了BS结构和J2EE，带着我们追逐J2EE之梦，那时是2000年初。不过这次是完全不用Lotus，改为使用Java了，从学校时候使用VB，到工作后用Unix下C，新的公司用Lotus，现在又完全不用Lotus改用Java了。从学校时候使用VB，到工作后用Unix下C，新的公司用Lotus，每样在周边环境中都能成为佼佼者。有一段时间也是比较浮躁，寻思刨根究底每样都学明白又有什么用？书到看时方去学就行了。这种心态前前后后持续了半年，其间虽然还熬夜，却是都打游戏了。一段时间下来，做J2EE的应用心里还是没有一点底，募然回首，发觉这一段时间收获空空如也。在头的指导下，对自己做了反思和重新定位，其时架构师的概念在国内开始比较热了，于是我对给自己树立了一个目标，做架构师。目标树立起来后，回顾工作两年来的情况，分析和目标的差距，朝着目标一步步前进。下面是当时的一些反思和体会：补充基础理论知识。IT的技术发展是非常快的，新技术层出不穷，但是各种技术之间很多原理是一样的，是相通的，重要的是要把原理搞通。笔者所在的学校以管理严格、学生基础扎实、踏实勤奋而著称。但在大学的时候毕竟由于缺乏实践对理论的认识不到位，工作以后回过头来看看老书，发觉有更深刻的认识和丰厚的收获。扩宽知识面。当时知识面还是太窄，当时对于网络，对于存储，对于大小型机，大于大型数据库几乎都没有深入的接触和使用。对于构建一个全新大型的基于J2EE的企业应用系统来说，架构师需要熟悉数据库技术、操作系统技术、存储、网络技术，J2EE体系架构，MVC框架，Java程序语言，还需要熟悉一到两个应用服务器、一到两门大型数据库。架构师需要具备扎实全面的技术，掌握广泛的开发技能，超离于程序语言之上，熟悉多种系统架构，有丰富的开发经验，能选择并设计合理的方案。学习尽可能多的领域知识。软件架构师可细分为应用架构师和技术架构师，应用架构是软件本身作为一个应用而存在的结构，技术架构是使应用能够运转的支撑架构。就像软件是为社会为生活服务一样，技术架构是服务于应用架构的。因此，要做架构师，不能只喜欢纯技术，还要学习尽可能多的领域知识。要深入、深入到本质里面去，绝对不能浮躁。不光要了解表象，还必须了解隐藏在表象里面的本质。架构师不只是使用者，更多的是建造者，创新者，每一个决定都可能会影响几十个开发人员和成百上千的使用者，因此必须深入熟悉技术的本质，了解原理，才能灵活运用，不可能临时抱佛脚，现学现卖。（我后来曾见过一些立志做J2EE架构师的程序员，不但不愿意深入学习Java虚拟机规范，对于API也只是一知半解。问其理由，答曰，犯不着搞明白，到用的时候查查API就行了。天哪，到用的时候查查API就行了，如果你是一个摩天大楼的建筑师，到盖高楼的时候现查查各种建材的参数规格指标就能盖起大楼来了么？就能把水、电、梁、管、消防等搭配得合情合理么？想想看，我们做的架构可能也会影响大批设计师和程序员，影响大批使用的用户，岂是现查API就能行的？）浮躁只会让人一事无成。曾见过一些人，写了两月程序，就嫌写程序低级要去做设计，刚写了两月设计，就嫌设计低级，就要去搞需求分析，刚搞了两天分析，又觉得搞技术没前(钱)途，就要去搞管理或者搞市场。也见过一些人，搞了三月嫌工资低，跳一下涨点工资，再搞三月又跳跳涨点工资。跳来跳去，开始还能往“上”跳， 到后面是只能往被赶着往下跳了。加强交流和沟通。曾经闷头苦学，希望能学得很牛牛，把什么都研究透了，然后可以教徒弟，可以带出一批人来。在这过程中总是碰到一些槛，虽不至于灰心丧气，但也挺郁闷。头告诉说不要指望一个人都干完了，再厉害也不可能把啥都搞明白了，一方面要形成有一个学习的气氛，大家都很厉害，水涨才能船高，另外一方面要加强和业界尖端人士的交流，共同提高。关于交流和沟通，古语中提的文人相轻，感觉现在是国人相轻，市场和技术人员相轻，公司间的技术人员之间相轻，殊不知，家里如何横没用，我们应该瞄准的是国外的大厂商，超越他们才是我们中国软件同行的目标。前两天去建材市场买装修的材料，每家店主都回告诉你这个价高是因为使用了进口材料，那个价低是因为使用了国产的。让人感觉非常的不爽。要创新，树立正确的学习能力观。当时感觉头说得没错，需要加强交流沟通，自己距离目标差的太远，周边没法寄希望能有人带着做，于是甚至都想到跳槽赔着钱当学徒工都行。头告诉我做好自力更生的准备，国内当时就是欠缺好的架构师，干得好的大多都搞管理去了，剩下没搞管理的不见得碰得到，就算碰到了不见得肯带你，就算肯带你不见得真就比我厉害。我相信他绝对没有贬低同行的意思，只是为了激励我罢。学习能力对于一个搞IT的人来说非常重要，如果没有很强的学习能力，很难快速适应技术变化的能力。（我后来碰到不少新员工，因为基本都是从大学毕业的人，学习接收新东西的能力都挺快，但是成就迥然有别。有的人，也具有强烈的好奇心，但为了学习而学习，敝帚自珍，不愿意应用到开发和工作中去，这种人，学到一定程度就很难再提高，学习能力只能算是不及格。笔者后来在浪潮软件烟草事业部开始做基于J2EE的应用的时候，及时将以前学到的新知识和技术运用到开发中去，从而确立了楼上企业应用框架在浪潮软件的地位。)在那一年只做了一个物流管理系统一个单，基于J2EE的单子，一切都是从头做，单子额不大内容却不少。虽然最后顺利完成，却因为广泛使用了应用服务器提供商提供的一个不成熟的扩展包而吃尽了苦头。虽说架构师不纠缠于细节，但是忽略了细节却可能造成严重的后果。对于7X24小时系统，一个细节不处理好，就会造成停机和严重的损失。细节就是追求完美，架构师既要有好的大局观，也不能忽略细节，要求我们不仅对原理搞明白，很多时候必须对具体技术实现有透彻的了解。基于J2EE的BS应用毕竟市场还小，加上其它一些原因，在2001年上半年，公司倒闭员工整体并入浪潮软件成为了浪潮软件的烟草事业部，同时带进浪潮的还有一个J2EE的Framework，楼上Web应用框架1.0。倚靠浪潮的市场优势和品牌优势，依靠楼上架构的卓越品质和快速二次开发 的能力。浪潮软件在烟草业行业占有率连续几年排名第一。而楼上系列产品也以Web应用框架1.0为基础，发展到今天的包含Web应用框架、工作流平台、商业服务平台、业务规则引擎等的楼上企业应用框架3.0。楼上企业应用框架也已在除烟草外的通讯、卫生、政务、税务等行业全面开花。依赖楼上企业应用框架构建的在多个行业属于首例全省大型集中式企业Web应用。在使用楼上企业应用框架构建Web应用中，也有一些经验教训。在最初的程序中程序员把太多的东西都放到内存session之中，我看见了这个问题并提出来以后数据量大可能会存在问题，但是不少人都认为已经写了不少了改的话返工太多，决定以后再改吧，我屈服了没有继续抗争。但是事实证明我们大家都错了，我们后来有了更大范围的返工，造成不少宕机。架构师应该意志坚强，既不偏执，也不轻易屈服。客户有时候会提出一些超过条件所能承受的要求，比如说不愿意新建一个OLAP库，要在很繁忙的OLTP库上做复杂的报表查询。如果满足客户的要求，其结果是最后性能达不到要求，影响实时操作的使用。或者即使把性能优化到能满足客户的要求，却付出非常高的代价，最后客户和我们都得不偿失。这时候需要我们要不卑不亢，和客户沟通，说服客户采用更好的技术方案，架构师不仅要和客户沟通，还要和项目经理沟通，和程序员、测试人员沟通。架构师要对系统的功能负责，对系统的成熟度负责，对系统的成本负责，架构自软件始而始，自软件终而终。架构师需要参与拟定项目的各种标准和规范，要指导大家，要和低层设计人员探讨一些难点的设计问题，他不仅仅是一个技术高手，还要充当技术的领导者，因此，学习一些软件工程的知识和提高领导力是绝对有必要的。在项目组中，架构师是一个角色，不一定就是一个人，可能是一个小组。架构师虽然不要忽略细节，也要警惕过分追求完美，架构师学会放弃，在系统的功能、成熟度、成本中取得平衡，从客户的角度和开发者的角度来考虑问题。特别是要警惕技术情结，一味追求最新的不成熟的技术，对于难以完成的功能，需要暂时舍弃，不可能一下造成最完美的系统。架构是一门科学，更是一门艺术，触类旁通，除了掌握深厚的技术知识以外，要尽可能多的掌握领域知识。成为架构师，没有速成的办法，唯有实践+努力。感谢后记： 感谢我的父母及哥姐，他们教会我如何做一个有道德的中国人！感谢我的妻子，在我穷困潦倒的时候一如既往的支持我，在我失意颓废的时候鼓励我，在我骄傲的时候泼冷水清醒我！感谢我的头张晖，没有他的指导，我现在可能还在跳来跳去寻找职业！感谢我的领导和同事，他们让我对国产软件更加有信心，他们让楼上框架更上一层楼！感谢孙向晖同志，他是楼上框架中开发工具、开发方法和协同平台的架构师，参与本稿的审校！附笔者介绍：周恒，网名ZHNT,现年28岁，98年西安电子科技大学计算机软件专业毕业，毕业后一直从事一线的软件研发与管理工作，现任浪潮软件技术研究中心总经理。主持并参与了山东省建行电话银行系统、山东省建行中间业务系统、山东风翔物流管理系统以及大连、山东、南京、广西、黑龙江、吉林、山西、广西、兰州、江西等十余个省市集中烟草信息系统项目，对企业级应用软件开发有许多独到的见解。熟悉OOAD、J2EE、工作流技术和企业级应用建模技术，是IT之源专栏J2EE专家，具备丰富的平台和中间件开发经验。主持开发了浪潮企业级应用框架、浪潮工作流引擎、浪潮Web应用框架、浪潮商业服务平台、浪潮协同开发平台、浪潮门户平台等平台和中间件。上述平台和中间件广泛应用于浪潮开发的金融、烟草、移动、政务、卫生、税务等行业的多个产品中。个人爱好：足球、篮球、乒乓球等运动附参考书目：笔者所在部门，因为是作公司整个平台和架构的部门，要求所有的程序员都要熟读：编码的奥秘、Java虚拟机规范、JDK源码、深入Java虚拟机、Java编程思想、Java与模式、J2EE规范、分析模式、设计模式。附浪潮楼上企业应用框架介绍：浪潮楼上企业应用框架(LEAF，Langchao Enterprise Application Framework)是国内第一个基于J2EE规范的真正的应用软件开发平台。浪潮楼上企业应用框架是一套基于J2EE规范的面向企业级应用的企业级应用框架，代表商业应用的实体对象相互协作实现核心商业过程，允许开发者使用此框架来开发完成最终的不同需求。浪潮楼上企业应用框架博采众长，吸收了先进和成熟的技术和架构思想，借鉴了浪潮多年的大型企业及应用系统的经验，使用了大量企业级应用模式、企业级数据集成模式、企业级开发管理模式，并经过若干大型成功项目的检验。从1998年至今，经过多年的演变和发展，已在此基础上成功地构建了金融、烟草、移动、政务、卫生、税务等行业的众多大型应 用。3、 系统架构师软件架构师是软件行业中一种新兴职业，工作职责是在一个软件项目开发过程中，将客户的需求转换为规范的开发计划及文本，并制定这个项目的总体架构，指导整个开发团队完成这个计划。架构师的主要任务不是从事具体的软件程序的编写，而是从事更高层次的开发构架工作。他必须对开发技术非常了解，并且需要有良好的组织管理能力。可以这样说，一个架构师工作的好坏决定了整个软件开发项目的成败。软件架构师实际上就是软件的总体设计师。首席设计师就是总设计师，打个通俗的比方：邓小平是中国改革开放的总设计师，我们用现在的说法可以讲，邓小平是中国改革开放的首席架构师。架构师的形成一定是在实践中积累起来的，而并非上了几次培训班，读了几本书就可以成功的，架构师是在工程实践中培养出来的！架构师也并非是万能的。架构师是客户需求和开发者之间的桥梁。在软件行业中，一般提到的架构师是技术架构师，而忽略了领域架构师或者讲是领域工程师的概念。一个好的领域专家一定是业务领域的架构师，他能够给出某一个业务领域的架构，我们可以称为业务架构，只有技术架构和业务架构紧密结合才有可能真正创造出一个好的系统！架构师，首先让我想起的是高楼大厦的设计人员，通常一座大厦在建之前,都先由设计师将蓝图描绘出来，包括其形状、结构、尺寸、材料等等，然后建筑工程师带领工人们按照蓝图将大厦一层一层地建起来。近年来，软件领域也渐渐地流行起架构师的角色，特别是对一些大型软件产品或项目的开发，这一角色显得很关键，因为缺乏好的软件架构师而导致项目失败的例子不胜枚举，一个没有经验和能力的架构师也会使项目失败的速度加快。软件架构师的重要作用软件架构师在整个软件开发过程中都起着重要的作用，并随着开发进程的推进而其职责或关注点不断地变化，在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等等，此外，架构师还要经常审查和客户及市场人员所提出的需求，确认开发团队所提出的设计；在需求越来越明确后，架构师的关注点开始转移到组织开发团队成员和开发过程定义上；在软件设计阶段，架构师负责对整个软件体系结构、关键构件、接口和开发政策的设计；在编码阶段，架构师则成为详细设计者和代码编写者的顾问，并且经常性地要举行一些技术研讨会、技术培训班等；随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点；在软件维护开始时，软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策。如何成为优秀的软件架构师显而易见，在软件开发过程中，一个优秀软件架构师的重要性是不应低估的。那么如何成为优秀的软件架构师呢？首先必须具有丰富的软件设计与开发经验，这有助于理解并解释所进行的设计是如何映射到实现中去。其次要具有领导能力与团队协作技能，软件架构师必须是一个得到承认的技术领导，能在关键时候对技术的选择作出及时、有效的决定。第三是具有很强的沟通能力，呵呵，其时这一点好象什么鬼角色都最好具备，软件架构师需要与各路人马经常打交道，客户、市场人员、开发人员、测试人员、项目经理、网络管理员、数据库工程师等等，而且在很多角色之间还要起沟通者的作用。在技术能力方面，软件架构师最重要也是最需求掌握的知识是构件通信机制方面的知识，比如远程过程调用、JAVARMI、CORBA、COM/DCOM、各种标准的通信协议、网络服务、面对对象数据库、关系数据库等等，另外，架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法。开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。当然，行业的业务知识对软件架构师也是很重要的，有助于设计出一个满足客户需求的体系结构，优秀的软件架构师常常因为要尽快获得对行业业务的理解而必须快速学习并且进行敏锐的观察。上面的描述是枯燥乏味的，但作为一个软件架构师，在整个软件系统的开发过程中是乐趣无穷的，因为这个角色很具有挑战性，有时需要左右逢源八面玲珑，有时又需要果断坚定不留情面。在国内，较少软件企业拥有独立的架构师，通常一个软件高手身兼数职，既是项目经理，又是软件架构师，还是软件开发者，有时还要客串一个测试人员，这对软件的开发周期和产品质量是不利的，有时一个人的观点立场是很片面的，而且繁重的工作、沉重的压力会影响一个人的情绪，情绪会影响决策，决策影响结果，所以值得我们三思而后行。系统分析员、系统架构师、项目经理的区别上周从开发部转来一个刚毕业的小伙子，要我面试一下看看是否适合质量部的相关工作。交谈中，小伙子说大学里已经考过了系统分析员，于是我便问他：“ 系统分析员主要做什么？” 小伙子想了一会说道：“系统分析员主要就是组织、管理和规划系统”。于是我接着问道：“如果负责组织、管理、规划的话，那和项目经理的区别是什么？”小伙子想了半天，终于摇着头说：“不知道。”问这个问题倒不是为了为难小伙子，主要是希望他能够明白，书本上学来的东西必须和实践联系起来，在开发也好在质量部也好，都离不开自己的主动学习和思考，没有思考的学习只是在收集知识而已，是不能够化为己用的。在离开学校的头两年里，大部分人是无法找到自己真正的兴趣所在，我也是一样，所以刚开始无论在哪个岗位都必须主动学习和思考，包括对自己现有岗位的知识的学习，以及由于不满而对岗位之外的知识的学习（当然这是在工作之外），而不满正是思考的起点。不过，正是因为无法找到真正的兴趣所在，就需要坚守岗位，一方面也许它就是自己的兴趣所在，一方面也为了寻找真正的爱好而积蓄力量。 额外的话说了不少，还是回来看看，到底“系统分析员、架构师、项目经理”之间有着什么样的差别？下面按自己的理解粗略的整理了一下，也许并不全面，绿色部分代表每一个角色主要需要参与考虑的活动（注：下面所说的系统分析员混合了设计的职责）：首先看一下架构师和系统分析员的区别：1、系统分析员必须考虑自己所设计系统的方方面面，他是系统实现的原始作者，也对系统能否满足客户的技术要求以及产品成本是否可接受起着最直接的作用。2、架构师一般在软件组织内仅仅是少数人，他们主要负责对产品的架构进行评估以及子系统之间的接口批准上，评估的主要方面集中在系统级的质量属性和成本上，包括：当前架构是否满足可靠性要求、系统架构的可扩展性、可重用性、性能以及基础的公共功能等等。他们必须对系统分析员设计出来的系统进行最初的把关，所以责任重大，也需要经验非常丰富的人来承担。在公司其他部门和Ivar Jacobson的交流中，Jacobson明确的指出，架构委员会不是常设组织，通常都来源于团队的系统分析员，唯一常设的职位通常只有一个主席，其他的成员必须临时来源于系统开发的一线，只有他们最了解系统开发的基本思想。3、系统成本是架构师和系统分析员最容易忽略的事情，而这个也是他们最基本的职责之一。接下来看看系统分析员和项目经理的差别：1、一个不合理的计划往往被归咎于项目经理，但这并不是事实。计划的制定严重依赖于系统分析员所设计系统的部件完成工序，而唯一能对这个作出准确判断的只有系统分析员。所以，计划的最初版本是来源于系统分析员而不是项目经理。项目经理在这方面的主要作用是协助系统分析员制定计划，帮助考虑人员、资源方面的投入情况，并在项目的执行过程中严格监控项目的进度情况。2、质量目标的制定和计划一样，来源于系统分析员，尤其是性能、可靠性等关键技术指标，而这些的第一跟踪主体也是系统分析员。项目经理在其中的角色，只是协助系统分析员安排各种资源，完成这些目标的测试、跟踪等活动。3、成本是唯一的需要架构师、系统分析员以及项目经理共同关注并且严格控制的因素，原因很简单，这是大家靠着吃饭的来源。4、项目其他的非技术方面的因素，则基本都是由项目经理负责搞定，包括合同、人员沟通、采购等等。4、 西门子李伟：怎样才是真正的架构师西门子中国中央研究院首席架构师、图书架构之美软件架构的艺术作者李伟，从架构师的定义和内涵、能力和素质要求、成长途径等方面向您阐述成为一个真正的架构师需要经历的历程。记者： 您认为具备哪些能力，才算是真正的架构师？李伟：虽然业界有关什么是“软件架构”有着明确的定义及共识，但是确实没有软件架构师的定义。简单地讲，架构师是一个技术控制的角色。技术控制是从客户或市场开始，一直到交付或服务的整个链条。如果大家对一个应用研发机构或产品研制机构的主要活动熟悉的话，就知道该链条上存在很多需要架构师负责的控制点。以西门子为例，西门子的战略市场部门就会和业务部门的很多架构师进行协作。这主要是由于战略市场部门的职能之一就是对未来十到十五年的技术和创新进行预判。这样的技术预判，如果没有架构师作为技术控制，单凭MBA出身的市场人员，大家能相信这样的技术预判吗？所以架构师需要具备一定程度的技术及创新预判能力。从一个架构师的日常工作来看，他面对的基本上有七大问题：商业问题、系统问题、子系统问题、构件问题、技术问题、流程问题、项目管理问题。其中，前五项是一个架构师主要负责解决的。这里我尝试提几个问题，让大家检验一下自己是否具备解决这些问题的能力。如果进行企业应用开发，你知道经典的商业运营手段一般有哪些吗？例如：公司中一般有哪些典型的职能机构？最经典的公司财务部运作是什么样的？最经典的公司纯研究机构的运作是什么样的？或者，最经典的公司纯销售机构是怎样运作的？如果你负责一个实时系统的架构，经典的架构构建步骤有几步？一个医学CT机系统应该用什么架构风格来构建？军用舰艇上的3C系统又应该使用什么架构风格？除了我们都熟悉的MVC风格的架构，你还知道哪些架构风格？再具体一些，对于系统的并发问题，你知道业界流行的经典解决手段包括哪些?如果你负责子系统及构件设计，经典的设计步骤有几步？分别又有哪些活动？除了你熟悉的Gang of Four的23个设计模式，你还知道什么设计实践？再具体一些，设计中有关同步、事件、资源管理等，你知道哪些前人的最佳实践呢？实践工作中，我们遇到的现实是：盲目追随业界通用框架，即对框架或中间件的严重依赖。这些框架或中间件背后实际隐藏了很多技术、设计、应用场景，也就是说为设计开发人员隐藏了很多系统设计开发的复杂性。如果架构师把各项系统级架构质量的要求，想当然统统扔给这些框架或中间件去处理，将会带来灾难性的后果。业界有这样一句话：“框架或中间件是用来帮助你的，而不是代替你去思考和工作的。”所以我们必须根据现实的系统要求，自己动脑筋去构建适合现状的软件架构!简而言之，架构师需要具备的能力=熟知最佳实践+动脑灵活使用+技术及创新预判。记者： 在中国，一个程序员如何才能成长为一个职业架构师？李伟：曾经无意间读过一篇纪事报告最后的大师。此文作者是应钱学森先生的邀请，来记录自己的导师，清华大学物理系及清华大学创始人之一的叶企孙先生。叶先生早年在美国留学期间，在物理方面做出过杰出的贡献。虽然大多数后人并不知道叶先生，但是他的学生没有一个会忘记他，其中包括三钱、华罗庚、李政道、杨振宁等等。可以这样说，你所知道的中国大师，大多都是他的学生。阅读完此文，颇受启发：真可谓“大师培养大师”。我非常欣赏这句话。如果身边有大师，自然是从程序员成长为架构师的捷径了。我身边没有大师，便选择这样的道路：认真反思自己这些年来的学习和实践，并将其上升为智慧。毕竟，智慧既是指导我继续工作的原始动力，也将指导自己未来的创新工作。因此，我选择了阅读、学习和思考。记者： 您认为在中国的软件企业中，大家在普遍认识中对架构师这一职业有哪些误区？李伟：误区一，架构师与项目经理没有区别。大家经常在谈论架构师时，混淆了项目经理的职责和架构师的职能。项目经理要对人、流程、钱等内容负责。但是架构师主要是对技术负责。所以我个人不是很喜欢在谈论系统架构时，过多的谈论流程或管理。虽然我也是流程方面和管理方面的专家。误区二，技术好的人就能成为架构师。其实，职业架构师与职业编程人员有着同样重要的分量，只不过各自负责的工作内容及需要具备的能力各不相同。例如：架构师熟知如何将系统架构构建得适应系统后续国际化/本地化的工作;但是并不一定必须知道界面热键在.NET下调用什么来实现。误区三，架构师必须懂得业务领域的知识。从本质上来看，软件架构本身就是在模仿人类大脑的问题思考和解决习惯。自然，专业架构师所掌握的知识就是解决那些反复出现的相似问题的最佳手段。所以，业界都知道这样一个著名的故事：一个非航天专业的软件架构人员，可以被美国国家航天局请去做航天系统的架构评审。这一点儿都不奇怪，因为他知道解决系统并发问题时，当今最经典的那么几种手段，你能说航天系统的并发问题与企业应用并发问题本质上不一样吗？由于当前国内软件研发的各种局限，很多软件从业人员的认知还停留在“懂业务+技术好”就是架构师这样的层面上。其实，懂得经典的解决方法，并能从实践中抽象出理论或最佳实践的人，才是架构人员的专业水平。记者： 在架构之美软件架构的艺术一书中，您认为最创新的理念有哪些？李伟：一个架构从创建、进化、老化到消亡的整个过程，是此书的核心。如同宇宙万物，架构也存在一个生命周期的概念。即“架构生命周期(Architecture Lifecycle)”。怎样才是一个真正意义上的软件架构师？当面临构建一个软件架构时，应该采用怎样的流程去工作呢？怎么做才能构建出满意的高品质架构及设计呢？当我们阶段性地完成了架构的构建，如何去评估结果呢？软件产品在演化，软件架构也会跟随演化，如何应对这种变化？十年前开发的产品，架构文档残缺不全，设计人员已经离职，怎么把产品的架构从纷繁复杂的头绪中清理出来呢？如果我们要研发十几个功能相似的产品，该如何高效地工作呢？上述这些理念，基本上是一个职业架构人员所需具备的专业素养。奉献给大家，以供参考。5、 系统架构师高级职称考试介绍【职业名称】系统架构师（System Architecture）系统架构师是负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等等。 【职业定位】系统构架，是对已确定的需求的技术实现构架、作好规划，运用成套、完整的工具，在规划的步骤下去完成任务。相应地， 系统架构师（又称企业架构师或者系统设计师）是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。他/她主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。 系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单，等等。 【工作职责】系统构架师的职责 系统架构师的职责就是设计一个公司的基础架构，并提供关于怎样建立和维护系统的指 导方针。具体来讲，系统架构师的职责主要体现在以下几方面： 1负责公司系统的架构设计、研发工作； 2承担从业务向技术转换的桥梁作用； 3协助项目经理制定项目计划和控制项目进度； 4负责辅助并指导 SA开展设计工作； 5负责组织技术研究和攻关工作； 6负责组织和管理公司内部的技术培训工作； 7负责组织及带领公司内部员工研究与项目相关的新技术。 8管理技术支撑团队并给项目、产品开发实施团队提供技术保障。 11理解系统的业务需求，制定系统的整体框架（包括：技术框架和业务框架） 12对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。 系统架构师的目的： 13对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。 系统架构师的工作在于针对不同的情况筛选出最优的技术解决方案，而 不是沉在具体实现细节上。此外系统架构师是不可培养的，好的系统架构师也许不是一个优秀的程序员，但是不能不懂技术之间的差别，技术的发展趋势，采用该技术的当前成本和后继成本，该技术与具体应用的偶合程度，自己可以调配的资源状况，研发中可能会遇到的风险，如何回避风险。这些才是架构师需要考虑的主要内容。 另外，还必须注意，架构分为两种， 第一种是基础架构的设计规划，例如：OS，硬件，网络，各种应用服务器等等。 第二种是软件开发设计的架构师，他们负责规划程序的运行模式，层次结构，调用关 系，规划具体的实现技术类型，甚至配合整个团队做好软件开发中的项目管理。 【能力要求】一、系统架构相关的知识和经验。 二、很强的自学能力、分析能力、解决问题的能力。 三、写作、沟通表达、培训。 【职业概述】系统构架师是近几年来在国内外迅速成长并发展良好的一个职位，它的重要性及给 IT业所带来的影响是不言而喻的。在我国虽然还存在一定的争论性、不可预测性、不理解性，不确定性，但它确实是时代发展的需要。IT业各公司为了让他们现有的 IT系统实现更大的价值，纷纷进行了重大的技术变革， 这样一来，对高水平的架构师的需求激增。对负责架构的管理人员的需求不断增大，其增长速度比对 CIO的需求还要快，这是因为，架构师会给一个组织带来大量专门技术。公司需要一些在架构方面有真才实学，而且学得深且广的人才。 在比尔盖茨的众多称谓中，据说他更偏爱“首席软件架构师”。同样，在网易创始人丁磊名字前，也有“首席架构师”这样的称谓。由次可见，对于企业来说，架构师就是灵魂的创造者。 【系统构架师的作用】系统架构师该怎么来实现其“架构”企业的职能呢？尤其在设计企业 IT策略时，该怎样体现架构师的价值？ 这里以实例说明： 摩托罗拉的副总裁 Toby Redshaw说，架构师是“IT策略中的中枢”，而且这一角色对公司的影响确实非常大。当 Toby Reshaw在 2001年进入摩托罗拉并担任其策略暨架构副总裁时，他俨然一位购房者对一套摇摇欲坠的公寓进行估价一样。他并不是仅仅只作些表面上的修改，而是拟定了一个重建摩托罗拉整个基础结构的计划，这个计划可以彻底修整公司的 基础建设。 就像一个建筑师设计一幢房子一样，Redshaw拟出了一张技术构架蓝图，一座技术性的建筑，以便使被他称作“如意大利面条般错乱的应用程序，机器和管线”那些东西变得井然有序。他说，只要选择了正确的架构策略并用对了人，摩托就可以用比以前更快的速度生产出大量应用软件，而且可以减少维持重叠系统的费用。 Redshaw说：“如果你连建筑架构都搞不好，就算你的石匠技术再高明，又有什么用？架构师是 IT策略中的中枢。”像 Redshaw这样的系统架构师们在企业内部的影响力非常大。很久以来，虽然他们一直在信息技术部门担任重要职务，但是他们经常受委托提供全面概况分析，并提出一些关于如何遵照标准执行这些任务的建议，而这些对日常运作的影响极其有限。今天，随着各公司都在寻找重建他们的 IT系统，使其更能有效节省成本，更灵活的方法，架构师愈来愈被看作是至关重要的因素。 一个定义明确的架构的目标在于降低运行复杂的运算系统的费用。一个公司可以采用一种特定的数据库配置，如微软的数据库，进而将系统标准化，而不需要让公司的每个部门安装它们自己所需要的数据库服务器。 Express的技术架构副总裁 Andy Miller说：“如果你没有一项强有力的架构策略，人人各行其是，最后以得到六种服务器和软件平台而告终，你的系统变成了大杂烩，而那将使你的费用激增。”把架构师独立出来有很多好处，比如系统的整体把握，质量上的保障，技术上的先进性，架构的灵活性，高效性，还可有效地降低成本。试想，1个月薪 1w的架构师+10个月薪5k的工程师，肯定比 11个月薪 6k的高级工程师效果要好。一般来说，级别越高的架构师，经验更丰富，争相聘请的人也多，他们也是与公司全部的 IT策略密切相关的专业人员。 【系统构架师应具备的能力】作为软件开发的设计架构师，那么必须拥有一定的编程技能，同时有高超的学习新的架构设计、程序设计技能。另外，我觉得作为软件架构师，还必须了解一定的硬件、网络、服务器的基本知识。要不然，你都不知道有些什么材料可以用，你怎么去根据实际情况去规划你的软件架构呢？忽视程序设计能力的持续跟新，