关于系统架构师

      最近看了一些关于2010系统架构师大会的内容，多半谈到的是和运维相关的架构问题，即项目形成产品后的架构运维问题，而非项目形成产品前的架构设计问题，也即我们常说的基础规划架构师和软件开发架构师吧！

     那么，到底如何理解架构师呢？他的职责是什么？应当具备什么样的知识储备？与系统分析师、与系统设计师以及与项目经理间有何不同侧重点？

     为了简要说明这个问题，摘录了两篇网络博文：《系统架构师是怎样炼成的？》和《系统架构师》。

     《系统架构师是怎样炼成的？》一文主要总结了架构师应当具备的能力：

写道

在谈到架构师需要具备的能力上，张友邦认为架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。

在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信（对象访问、函数调用、数据交换、线程同步等）以及进程外（包括跨计算机）的通信（如RMI、DCOM、Web Service）。在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图；而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括ASP.NET Web Service、.NET Remoting、企业服务组件等。总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。

其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。

再次，张友邦提到，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。

另外，张友邦认为架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。

 

  《系统架构师》这篇来自于文章互动百科，着眼于大局，阐述了系统架构师的职业概述、专业活动、职业区分、职业评估、职业评价，比较全面的介绍了系统架构师这个角色：

目录

• 1 职业概述
• 2 专业活动
• 3 职业区分
• 4 职业评估
• 5 职业评价
• 6 相关词条

写道

摘要 系统构架，是对已确定的需求的技术实现构架。与产品设计相比，系统构架设计的工作更明确，而该领域也已经形成了较为成熟、完善的方法论和一整套易于掌握、传授的知识。相应地，系统架构师是一个不折不扣的技术人员，主要着眼于系统的“技术实现”。责任是最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。因此应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。
系统架构师-职业概述
思科亚太区IP NGN首席构架师殷康系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单，等等；系统架构师的工作在于针对不同的情况筛选出最优的技术解决方案，而不是沉在具体实现细节上。此外系统架构师是不可培养的，好的系统架构师也许不是一个优秀的程序员，但是不能不懂技术之间的差别，技术的发展趋势，采用该技术的当前成本和后继成本，该技术与具体应用的偶合程度，自己可以调配的资源状况，研发中可能会遇到的风险，如何回避风险。这些才是架构师需要考虑的主要内容。
另外，还必须注意，架构分为两种，第一种是基础架构的设计规划，例如：OS，硬件，网络，各种应用服务器等等。第二种是软件开发设计的架构师，他们负责规划程序的运行模式，层次结构，调用关系，规划具体的实现技术类型，甚至配合整个团队做好软件开发中的项目管理。

系统架构师的职责：理解系统的业务需求，制定系统的整体框架（包括：技术框架和业务框架）；对系统框架相关技术和业务进行培训，指导开发人员开发。并解决系统开发、运行中出现的各种问题。

系统架构师的目的：对系统的重用、扩展、安全、性能、伸缩性、简洁等做系统级的把握。

系统架构师-专业活动
系统构架及层次关系示意图1、角色：软件架构师SoftwareArchitect：主导系统全局分析设计和实施、负责软件构架和关键技术决策的角色；
2、职责：①领导与协调整个项目中的技术活动（分析、设计和实施等）；②推动主要的技术决策，并最终表达为软件构架；③确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”；④确定设计元素的分组以及这些主要分组之间的接口；⑤为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻；⑥理解、评价并接收系统需求；⑦评价和确认软件架构的实现；

3、专业技能：①技术全面、成熟练达、洞察力强、经验丰富，具备在缺乏完整信息、众多问题交织一团、模糊和矛盾的情况下，迅速抓住问题要害，并做出合理的关键决定的能力；②具备战略性和前瞻性思维能力，善于把握全局，能够在更高抽象级别上进行思考；③对项目开发涉及的所有问题领域都有经验，包括彻底地理解项目需求，开展分析设计之类软件工程活动等；④具备领导素质，以在各小组之间推进技术工作，并在项目压力下做出牢靠的关键决策；⑤拥有优秀的沟通能力，用以进行说服、鼓励和指


微软公司首席软件构架师导等活动，并赢得项目成员的信任；⑥以目标导向和主动的方式来不带任何感情色彩地关注项目结果，构架师应当是项目背后的技术推动力，而非构想者或梦想家（追求完美）；⑦精通构架设计的理论、实践和工具，并掌握多种参考构架、主要的可重用构架机制和模式（例如J2EE架构等）；⑧具备系统设计员的所有技能，但涉及面更广、抽象级别更高；

4、活动：确定用例或需求的优先级、进行构架分析、创建构架的概念验证原型、评估构架的概念验证原型的可行性、组织系统实施模型、描述系统分布结构、描述运行时刻构架、确定设计机制、确定设计元素、合并已有设计元素；

5、工件：软件构架文档、参考构架、分析模型、设计模型、实施模型、部署模型、构架概念验证原型、接口、事件、信号与协议；

系统架构师-职业区分
IBM电信行业高级构架师李永正1、产品经理和系统架构师的区别：
如果把开发软件比作摄制电影，产品经理之于系统架构师，就正像编剧之于导演。产品经理虽然要有一定技术背景，但仍应属于“商业人士(businesspeople)”，而系统架构师则肯定是一个技术专家。二者看待问题的立场、角度和出发点完全不同。对于特定的开发领域或项目，产品经理和系统架构师这两种角色的重合也可能是无害、甚至有益的(如编程语言的设计)。

2、系统构架师与项目经理的关系及区别

软件项目经理是指对项目控制/管理，关注项目本身的进度、质量，分配、调动、协调、管理好人、财、物等资源的负责人。对于软件项目经理来讲，包括项目计划、进度跟踪/监控、质量保证、配置/发布/版本/变更管理、人员绩效评估等方面。优秀的项目经理需要的素质，并不仅在于会使用几种软件或是了解若干抽象的方法论原则，更重要的在于从大量项目实践中获得的宝贵经验，以及交流、协调、激励的能力，甚至还应具备某种个性魅力或领袖气质（Charisma）。

从性格因素上讲，单纯的技术人员倾向于忽视“人”的因素，而这正是管理活动的一个主要方面。项目经理能够应付开发过程中大量的偶发事件和杂务。

在一个项目中，推动项目发展的是系统构架师，而不是项目经理。项目经理的职责只是配合系统构架师，提供各个方面的支持。主要职责是与内外部沟通和管理资源（包括人）。系统构架师提出系统的总体构架，给出开发指导。

3、系统构架师与系统分析师的关系及区别

系统分析师（Systemanalyst）是指对系统开发中进行分析、设计和领导实施的人。一般意思上讲，系统分析师的水平将影响系统开发的质量，甚至成败。但在一个完善的系统开发队伍中，还需要有业务专家，技术专家和其他辅助人员。所以，系统分析师只是其中的角色之一。但中国许多的IT公司，一般只有系统分析师而没有技术专家。

系统分析师固然是对特定系统进行分析、设计。所以他的任务、目标是明确的。他只是去执行任务，完成系统的最终设计。系统架构师应该和系统分析师分开，但架构师必须具备系统分析师的所有能力，同时还应该具备设计员所没有的很多能力。

系统架构师是指导、检督系统分析师的工作，要求系统分析师按什么标准，什么工具，什么模式，什么技术去设计系统的。同时，系统架构师应该对系统分析师所提出的问题，碰到的难题及时地提出解决的方法。并检查、评审系统分析师的工作。

系统架构师-职业评估
IBM系统科技事业部大中华区资深系统架构师叶郁辉1.系统构架师是否是某一技术领域的专家；
2.系统构架师能否指导系统分析师的设计工作，发现并指出设计存在的问题并提出解决方法，评审他们的工作；

3.系统构架师能否指导软件工程师进行开发工作，发现并指出编码存在的问题并提出解决方法，评审他们的工作；

4.系统构架师能否协助好项目经理制定项目计划和控制项目进度；

5.系统构架师能否及时有效地解决设计、开发人员所提出的问题，解决技术上的难题；

6.系统构架师能否制订并规范系统设计和开发文档、工具、模型；能否让其他人员容易理解；

7.系统构架师能否经常组织并带领公司内部员工研究、学习与项目相关的新技术；

8.系统构架师能否组织和管理好公司内部的技术培训工作，技术研究和攻关工作；

9.能否给公司降低开发成本，提高效率；

10.系统构架师是否有良好的团队意识和协作精神，有较强的内外沟通能力；

11.系统构架师是否能管理好技术支撑团队并给项目、产品开发实施团队提供技术保障；

12.系统构架师所设计的系统架构是否合理，技术是否先进，能否满足客户的要求；

13.系统构架是否有扩展性，安全性，能否经受压力测试，网络流量在超用户数下如何控制；

14.系统边界如何处理，瓶颈问题如何解决等；

15.系统设计前期、中期、后期所要解决的问题，是否有阶段性，里程碑的标识；

16.是否有分析、识别并尽可能地回避风险，降低风险所引发问题成本的能力；

系统架构师-职业评价
Amdocs资深解决方案构架师汪雷鸣做好了架构师的工作，可以使程序更稳定，因为程序子系统之间的结构是稳定的。可以减少维护的工作量，一个好的架构师，绝对不会让系统中出现重复的逻辑和数据，这必然减少系统的开发工作；架构师还可以使构建新系统的工作更容易，因为架构师会抽象出底层的模块，在各个程序之间共享。
摩托罗拉的副总裁TobyRedshaw说，架构师是“IT策略中的中枢”。当TobyReshaw在2001年进入摩托罗拉并担任其策略暨架构副总裁时，他并不是仅仅只作些表面上的修改，而是拟定了一个重建摩托罗拉整个基础结构的计划，拟出了一张技术构架蓝图，一座技术性的建筑，使被他称作“如意大利面条般错乱的应用程序，机器和管线”变得井然有序。他说，只要选择了正确的架构策略并用对了人，摩托就可以用比以前更快的速度生产出大量应用软件，而且可以减少维持重叠系统的费用。

一个定义明确的架构的目标在于降低运行复杂的运算系统的费用。一个公司可以采用一种特定的数据库配置，如微软的数据库，进而将系统标准化，而不需要让公司的每个部门安装它们自己所需要的数据库服务器。

Express的技术架构副总裁AndyMiller说：“如果你没有一项强有力的架构策略，人人各行其是，最后以得到六种服务器和软件平台而告终，你的系统变成了大杂烩，而那将使你的费用激增。”把架构师独立出来有很多好处，比如系统的整体把握，质量上的保障，技术上的先进性，架构的灵活性，高效性，还可有效地降低成本。试想，1个月薪1w的架构师+10个月薪5k的工程师，肯定比11个月薪6k的高级工程师效果要好。一般来说，级别越高的架构师，经验更丰富，争相聘请的人也多，他们也是与公司全部的IT策略密切相关的专业人员。

 

    个人感觉，以上两篇文章能够比较好的解答《系统架构师》这个角色的职责与知识储备，故，收藏之与君分享！