师傅引进门，修行在个人--架构培训感言
新视野 “软件架构”定义的决策因素
定义1：架构是一系列重要决策的集合
一直以来，学习架构，使用架构，关注点都仅限于技术层面，没有认识到架构和“决策”的关系，这说明架构是一个很重要的概念，从软件架构概念产生的背景可以得出：
——-其实，软件架构(Software Architecture，软件体系结构)一词早在20世纪60年代就被E.W.Dijkstra提出，但是直到20世纪90年代初才开始流行起来。为了提高软件需求和软件设计的质量，软件工程界提出了需求分析工程技术和各种软件建模技术。但是在需求和设计之间仍然存在一条很难逾越的鸿沟，即缺乏能够反映做决策的中间过程，从而很难有效地将需求转化为相应的设计。为此，软件架构的概念应运而生，并试图在软件需求与软件设计之间架起一座桥梁，着重解决软件系统的结构和需求向实现平坦过渡的问题。
定义2：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理。
还有很多其它的定义方式，但从这两个定义可以看出，架构对于决策的重要性，架构师的工作对于项目的成功运作具有决定性的作用。
“架构师”不是空头衔
——不是项目经理，开发人员，测试人员的兼职角色
在软件工程领域中，软件架构师实际上就是软件项目的总体设计师，是软件组织新产品的开发与集成、新技术体系的构建者。Martin Fowler（著名软件架构和设计大师，软件设计模式创始人）指出：
架构师是对所有重要事情做出决定的人。
软件架构师在整个软件开发过程中都起着重要作用，并随着开发进程的推进而其职责或关注点不断地变化。
在需求阶段，软件架构师主要负责理解和管理非功能性系统需求，比如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等。此外，架构师还要经常审查客户和市场人员所提出的需求，确认开发团队所提出的设计；在需求越来越明确后，架构师的关注点开始转移到组织开发团队成员和开发过程的定义上。
在软件设计阶段，架构师负责对整个软件架构、关键构件、接口的设计。
在编码阶段，架构师则成为程序员的顾问，并且经常性地要举行一些技术研讨会、技术培训班等。
随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点。
在软件维护开始时，软件架构师就要开始为下一版本的产品是否应该增加新的功能模块进行决策。
软件架构视图
——软件架构是一种无法以简单的一维方式进行说明的复杂实体。
——多重软件架构之所以必不可少，是因为各类涉众（用户，客户，开发人员，测试人员，维护人员，内部操作人员，其他人员）需要从各自的角度理解和使用架构。
常用的软件架构视图：
l 功能视图
l 开发视图
l 进程视图
l 部署视图
l 场景视图
l 数据视图
l 实现视图
注：在我们的实际项目中，用的最多的是功能视图，其次是开发视图，没想到还有这么多的视图需要考虑。比如，在MB一期的设计中，我曾考虑过是否有必要作一个软件的部署形式图，最后犹豫中还是出了一个，现在看来是很有必要的了，至少让运维人员明白了MB的软件部署是怎么回事。
新观念
架构的质量属性在现实的系统中，决定系统成功或者失败的关键因素中，满足非功能需求往往比满足功能性需求更为重要。从技术角度看，质量属性影响重要的架构和设计策略。
质量属性分为系统质量属性和商业质量属性，其中系统质量属性又分为运行时期的质量属性和开发时期的质量属性；商业质量属性包括政治因素，上市时间，成本和收益等。
我们虽然常常把性能，安全，可扩展等词挂在嘴边，但往往在实际开发中这些因素都忽略了，为了赶工期，功能实现是第一位的，最后软件做出来了，质量却不好，问题一堆。实际上，软件的质量不只是产品经理应该关注的，软件架构师也必须关注，给出建议，供管理层做出决策。MB的开发就是最明显的例子，上头规定了上线时间，满足必须的功能，及时上线是附在开发人员身上的魔咒，开发人员只得加班加点的工作，最后软件及时上线了，但后来在运行效率，易用性等方面成为诟病。
架构是有生命力的
运维人员说：软件运行这么慢，架构太烂了！
开发人员说：代码这么难写，架构太不灵活了！
客户说：软件太不稳定了，架构有没有问题啊？
XXX说：YYY架构师太差劲了，怎么就没有设计出一个好架构？
在所有人看来，架构必须是完美的，对所有人感觉都是良好的，能够适应未来的种种变化，能够一劳永逸！
起初我也是这么认为的，但是老师告诉了我们一个新观点：
架构是有生命力的！
“架构是有生命的，是不断变化的。因此，设计架构不能只想着要考虑到所有的问题，设计出一个能够包容所有可能问题的架构，这几乎是不可能完成的任务。因为变化是绝对的，架构总是会修改，关键问题是何时修改？一定不能在系统问题频出、已经来不及补救的时候才去考虑修改，而要在潜伏的问题逐渐露出端倪之前展开行动。”
——FreeWheel CTO和联合创始人 于晶纯
亚马逊，MySpace（进行了6次架构重构），eBay，淘宝网，这些大型网站都是不断地对架构进行重构，对应用进行升级来应对业务发展的需要的。
所以，我们不能一味的去指责FT的架构如何差劲，MB的架构如何糟糕，公司的这些产品线都是逐渐发展起来的，功能是一点点增加起来的，在功能开发第一的市场战略下，架构成了次要考虑的问题，所以我们不能说当初的架构设计的不好，问题是在于功能增加了，应用变复杂了，而架构没有跟上变化。
首先，架构师要有全局观，不能瞎子摸象，要看到架构的多个层面，多个角度。如架构的多个视图，架构的质量属性，架构设计，架构模式等，都是从项目的全局视角来看待问题的。
设计的本质就是一种权衡，是各类相互制约的模块间的一种权衡。明白这一点，就要求架构设计上对各个模块应有灵活的控制，以保证用户期望目标为设计出发点，平衡各类资源的使用。
一个好的架构的概念是完整的，模块间的关系是清晰简洁，弱耦合的，模块的接口是抽象稳定的，模块的实现是强内聚和可扩展的。
一个目标或一件设计任务，在架构师的头脑中，永远是有层次感的，是立体的，就如同草稿中的一个建筑物：它应该是一个什么类型的建筑物，需要多少个支撑面、大概需要多高（几层楼）、需要满足多少功能…。
实际上，这是一种考虑问题的习惯：分类思考，分层观察。
架构师的一个重要素养或价值是将一个问题或者方案的“分类学”搞清楚 - 从几个方面来考虑，最重要的“动因”是什么，关键的需要是什么，关键的设计要素是哪几个。当然，做到这一点需要很强的理论功底，也需要很丰富的经验，这样你拿出来的解决方案才有说服力。
要善于总结经验，找到解决问题的最佳方法—架构模式。
要善于分析和归纳问题，找到事情的变化点和风险点，并能够采取良好的设计规避这些不稳定因素，这是普通和优秀架构师的重要区别。
“我之所以成功，是因为站在巨人的肩上。”
——牛顿
“既全面又面向重点细节的思路，参考前人的实践经验，聚焦问题的症结，采用安全且有创意的手段，追求完美的精神。”
——西门子中国首席架构师 李伟
不要重复造轮子，把轮子的样式和制造方法告诉我吧！架构也是一样，业界有很多通用的商业或者开源软件架构，比如Java的Spring，Hibernate，.NET的Enterprise Library，Entity Framework 。我们可以参考别人用过的成功的架构，把它们作为参考架构。他们可以是现成的架构模式、架构机制和框架，也可以是具有已知特征并证实已在使用的完整系统。 使用经测试的参考架构是处理许多非功能性需求（尤其是质量需求）的一种有效方法。
“你们现在学的东西可能觉得对你们现在的工作没有太大的实际意义，但你应该先了解它，知道有这么回事，然后当你遇到问题的时候，想想有没有以前学习过的，有你就拿出来，仔细研究，使用，总结，最后你就能够驾驭它，这样你就成了专家，成了大师了。”
——这是老师最常给我们讲的一句话。
先知道有它，了解它，再使用它，驾驭它，这就是先知其然，再知其所以然。这是一种循序渐进的学习方式，软件架构的知识这么多，面这么广，不可能一下子全部掌握，现在学的以后可能会使用到的，到时候再来深研也不迟。
如果你不知道这些知识，这些方法，等你以后遇到问题，辛苦钻研出来，兴高采烈的宣称自己多么聪明，多么伟大的时候，说不定有人就会给你破盆冷水—这个问题某某人在很久之前就有好的解决方案了。
这不是说自己钻研不重要，而是这么做不值得，就像前面说的，不要重复造轮子，而在这之前，要有“先知其然，再知其所以然”的思维方式。
不是谁都可以段时间内直接成为架构师的，需要有一些必备的素质和培养成的良好习惯。
一个人拥有知识，但是却没有能力清晰的表达自己，这简直就和他从来没有任何思想一样。
——亚里士多德
交流不完全是一种知识，而是本领，是生产力。
——吴建民
沟通能力是通过书面、口头和其它沟通方式表达自己的观点的能力。架构师要和客户，领导，开发人员，测试人员，维护人员等架构涉众进行沟通交流，要能够清晰的表达架构目的。
光沟通还不行，还要会沟通，要深入浅出的展现沟通。把书看厚难，再把书看薄更难。理解起来是说，看很多很多书、掌握很多很多知识很难，可是能够把很多很多知识再融汇贯通、抽象成为言简意赅的、深入浅出的“浓缩版”知识更难。为什么一定要架构师具备这样的本领？架构师需要很多沟通：其中最重要的沟通是向上，与管理层沟通，向管理层报告方案的要点，获取管理层的理解、支持和批准。
架构师不是美术师（把建筑图纸画的很漂亮），架构师也不是力学家或材料学家。他精通主要技术，熟悉业界的最新动向，为我所用，甚至进而形成自己的设计风格和vision，然后说服管理层和团队成员。这是架构师（Architect）和某个专项专家（SME, Subject Matter Expert）的区别。
架构师从产品的生命周期上来看，他所涉及的层面很广，而且他所需要的知识面也会很广，需要过程更需要时间的学习和磨练。
另外，掌握很多知识，也是有备无患，说不定哪天就能够用上，就像上面说的“先知其然，再知其所以然”。
软件架构师除了技术知识和行业知识，还应该掌握一些其它行业和学科的知识，比如建筑学，美学，甚至哲学。
前面说过，架构是有生命力的，要明白软件架构的生命周期，设计合适的架构而不是超前的最新的架构。
架构师不仅需要掌握各种相关知识,还需要有一个能够评判利弊并进行最优组合的能力。有时候,还不得不考虑到开发团队的实际水平和效率,否则设计再理想却难以实现,也成了纸上谈兵.因此,还需要对开发团队的成员的知识水平能有准确的判断能力。
企业的IT技术不同于科学研究，技术永远都不能脱离成本来讨论，这就是你不能问奔驰和赛欧孰好孰坏的原因。
架构没有好坏之分，只有成本高低之分，如果成本过高，高过营收了，那公司赔钱，虽然也能把建筑物修建起来，但是没有意义了，因此，架构师最核心的要务是节约成本，通过合理的架构，在尽可能满足需求的前提下，节约成本。
出色的架构师拥有很强的成本概念，熟悉不同的技术方案的成本属性，了解不同的业务需求对于成本的基本限制。所以，出色的架构师可以向管理层和用户提供“适用”的、“可靠的” 的技术方案。
软件架构师是软件项目的总体设计师，是软件组织新产品开发与集成、新技术体系的构建者，是从宏观上驾驭大型系统的战略家，是对软件项目中所有重要架构事情做出决策的人，是策略制定者、组织协调高手、称职的顾问与领导者。
作为一个软件架构师，在整个软件系统的开发过程中是乐趣无穷的，因为这个角色很具有挑战性，有时需要左右逢源八面玲珑，有时又需要果断坚定不留情面。Philippe Kruchten曾经说过：当一个伟大的架构师领导开发团队时，团队的每个成员都感觉不到他的存在。次一点的架构师使开发团队的每个成员都喜欢他，再次一点的是害怕他，最次的是鄙视他。
具体来讲，架构师的职业道路有三个方向：
(1)行业应用架构。行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局。
(2)应用系统技术体系架构。技术架构师往往是技术高手中的高手，掌握各类技术架构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等。
(3)规范架构。规范架构师是通过多年磨砺或常年苦思顿悟后，把某一类架构抽象成一套架构规范。
这三个方向上面的道路怎么走，实在是一个太复杂的问题，而且国内很多公司可能要求一个架构师同时具备这三个方向上面的能力。所以，这路实在是不好走，而要成为前面说的那种优秀的架构师，这条道路实在是很长很长。
用开篇的话说：
师傅领进门，修行在个人！
架构师之路，任重而道远！
