第二周 企业中的架构师

■ 2.1软件架构师的定义、分类和职责

 

从1985年开始，在过去二十多年中，关于什么是“软件架构（Software Architecture)” 已经基本得到了软件工程领域普遍的认同。其中一些重要的定义介绍如下。

“软件架构代表了一个系统的组织结构•这包括将系统分解为不同的部分、界定它们之

间的连接、确定它们之间的交換机制、并且为后续的设计提供指导性的原则”一出自UML

 

的著名原创者James Rumbaugh、Grady Booch及Ivar Jacobson (即架构界俗称的“三

 

个火枪手”)。

 

“软件架构表述了一个系统的一个或一系列组织结构。这包括了软件构件、这些构件的

 

外部可见特征•以及这些构件之间的关系”——出自Bass Len、Paul Clements、Rick Kazman在2003年出版的经典的《架构的实践》一书。

 

IEEE在2004年4月公布的“IEEE Standard 1471，，中，提出了 IEEE自己对软件架 构的定义：“软件系统架构是根据具有参考意义的实践而定义出来的.主要表述了一个系统 的基本组织结构、基本组成构件和相互的关系，以及构件于外部环境间的关系。同时，软 件系统架构为后续的设计和架构演化提供了指导性原則”。IEEE Standard 1471也澄清了

架构领域的许多其他概念，例如架构描述、架构标准等。

 

面向客户的流程：该流程扮演了公司与客户直接进行交互的角色。例如：市场推 广、售前、销售、物流配送、产品管理、产品服务、技术支持等。这也是公司收入 的主要入口。

 

方针决策和计則流程：这是一个面向未来的管理流程。该流程主要是服务与公司未 来的目标。例如：界定公司产品未来长期的发展方向、制定产品长期发展的路线图 与时间表、中期的发展预算与发展计划等。

 

产品开发流程••该流程为面向客户的流程持续不断地提供新的产品，为面向客户的 流程能够在“明天”获得更多的收入创造了条件，这样也确保了公司的持续发展。

 

人贝与技术管理洗班：这是公司重要资产的管理流程。确保了公司的知识积累和人 员技术发展等得到有效的管理和使用。

 

产品线开发洗猓(可选）••有些公司引用这样的流程是因为它们从事着产品线的制 造。例如：产品共性的分析、产品线共用子系统的开发、产品线共用构件的开发等。

 

 

桥梁二：方针决策和计划流程与产品开发流程，如图2-3所示。事实上很多公司和架

 

构人员没有认识到这种与方针决策和计划相关工作的桥梁作用。这样就导致产生了一些问 题或现象，例如产品还在开发过程中就突然对其在市场上的定位进行短视的调整；已经制 定的中长期产品开发方针和计划与实际的产品发展不相符，陷于空谈。解决这种问题的最 佳实践，就是架构师帮助界定公司产品未来长期的发展方向，帮助制定产品长期发展的路 线图与时间表，并对中期产品的发展预算与发展计划进行评审。通會我们把这种架构师叫 做 “ Portfolio 架构师（Portfolio Architect) ”。

 

 

桥梁三：产品线开发流程与产品开发流程。产品的开发只是整个产品线家族中的一个 产品实例的开发。产品线开发工作的原动力，其实是长期相关产品开发所引起的复用的需 要。所谓产品线中各个产品所共用子系统的开发、产品线中共用平台的开发、产品线共用 构件的开发等，都是架构师从相关产品的开发实践中，总结产品共性、分析产品的个性得 到的。当然，这些共性与个性的总结和分析，形成了所谓的产品线架构（详细讲述请参考 第8章)。并且这样的架构，也要服从于方针决策和计划流程所制定的产品Portfolio、产品 远景规划等的要求。负责抽取共性、剥离个性的架构师,就是所谓的“产品线架构师(Product Line Architect)”。

 

桥梁四：人员与技术管理流程与产品开发流程。从实践中我们就可以注意到，架构师

 

要和很多岗位的工作人员进行技术层面的交流，这也是架构师同人员与技术管理流程的连 接点。架构师为人员与技术管理流程提供了强有力的输入，例如工程师的技术培训、详细 设计指导和评审以及新技术的研究和探索等。

 

我们能够发现，产品线开发和产品开发是两个至关重要的流程。方针决策和计划流程 为产品线开发和产品开发流程提供了平台，人员与技术管理流程为产品线开发和产品开发 流程提供了合格的人员，面向客户的流程其实是产品线开发和产品开发流程最终服务的对 象。

 

事实上，产品线开发和产品开发是架构师的主要工作环境，甚至可以说架构师是这两 个流程的主角。如果参照IS09000对设计控制的要求，我们就能看到架构师在这两个流程 中主要完成了 “设计控制”的任务。我们借用常用的划分方式，对产品线开发和产品开发 进行阶段划分，以便于看清“设计控制”是如何逐步完成的，如图2*4所示。

 

我们可以看到，产品线开发和产品开发实际上是一个跨流程的流程。因为市场拓展人 员、销售人员、物流人员、产品服务人员、产品方针决策和计划人员、产品设计与开发人 员等也参与了不同阶段的不同工作，协助架构师完成设计控制的总目标。

 

可以淸晰地看出，从市场跟踪开始，在界定需求、可行性研究、产品定义、架构与设 计、开发与制造、测试、未来跟踪等整个生命周期上，架构师起到了不可替代的重要作用 如果从产品生命周期的角度上来看，架构师可以分为解决方案架构师、产品Portfolio架构 师、产品线架构师、产品架构师、子系统架构师。

 

从面对的问题上来看，有些架构师主要是解决那些较为宏观的问题，例如：帮助客户 进行商业分析、分解商业结构与关系、商业流程建模、制定产品线及产品发展规划（如路 线图、计划与蓝图等）、参照经典的问题分析模型（例如JamesCoplien的“漏桶计数模型”） 分析并构建问题解决方法等。而有些架构师的主要角色是集中在技术的层面上，例如：利 用经典的“Pipes and Filters”架构风格分割系统、利用“Leader and Follower”结构解决 系统并发问题等。所以’我们也可以将架构师分为两大类：面向业务设计的架构师与面向 技术设计的架构师。

 

•与客户、销售、市场和其他相关的需求发起人员进行交互，理解整个业务背景，确 定即将开发的产品的要求（例如：性能的要求、成本的要求、演化的要求、市场的

 

定位)。

 

•严格界定客户（客户、市场、销售、物流配送、产品服务）的需求。经过沟通，确 保满足各方stakeholders的约束条件（时间、进度、成本)。在平衡各方利益与要 求的基础上，形成完整、正确的需求规格说明。

 

•与产品线人员沟通协调，满足产品线的路线图与计划。根据成本效益分析模型，确 定实现需求的实现方法（利用产品线公共平台、公共子系统、公共构件等）。

 

^利用系统分割模型（例如减少各部分的依赖程度、减少通信次数>,将系统结构切 分为子系统。并且考虑架构的实现技术与可利用的工具（例如使用已经拥有的产品 线共用部件，或者考虑外购）。在子系统与构件设计阶段，监督设计的进行，确保 跃•定的架构原則得到执行。并及时与客户（客户、市场、销售、物流配送、产品服 务）进行架构与设计的沟通。

 

澹在编程实现阶段，计划、跟踪和监控系统的开发，确保架构思想和既定问题解决方 案得到了执行，从而避免了架构在实施阶段的漂移。

 

•与设计人负、測试工程师以及客户一起，制定測试和验收的标准。确保客户在最高 层面上的各个重要要求得到了满足（例如：人机界面的友好等）。

 

•产品交付后，对物流配送、产品服务进行支持。与最终用户、市场、销售、服务人 员进行交流，收集产品改进意见和建议，为产品线及产品的演化提供信息。

明确了架构师的职责,我们就可以引用Frank Buschmann的经典论述来定义一个架构 师：“一个软件系统的架构师是一个要担负起软件系统的定义、架构的实现、系统的实施、 系统架构演化和系统演化的人。换句话说|是一个要为系统整个生命周期负责的人。“

 

2-2软件架构师具备的素质

 

随着软件工程行业对“软件架构师”的工作职责和角色的认识愈来愈清晰，人们也逐步认识到具备优秀素质的软件架构师的资源稀缺的问题。1997年Eberharttt Rechtin就说

 

过的“在我们日常的软件工程活动中，软件架构师是一种越来越稀缺的资源”。的确是这样， 随着产品系统对软件的日益依赖，随着架构师职责的演化和扩大，软件生产与软件开发也 越来越依赖与经验丰富的架构师。为了满足产品与项目开发的计划、架构、设计、系统演 化的需要，对架构师所需经验和知识的要求也越来越髙。

 

我们首先可以先来分析一下Chuck Kilmer在2006年提出的架构师成长模型,如图2-5 所示。从Chuck Kilmer的模型中可以看出，一个典型的架构师是需要多方面的知识、技能和经验的。

基本上任何架构师都是从技术开发人员成长起来的。作为架构师的预备阶段，在有限 的时间和有限的精力下，技术开发人员一般都是对某个单一技术方向进行了深入细致的研 究和应用，从而积累了技术细节方向的经验，成为了这项技术的“技术专家”，这为他们曰 后成为架构师起到了技术铺垫的作用。随着涉足的专业技术领域日渐扩展，开发人员开始 在多个领域进行深入的实践活动，从而成为了多个方向的技术专家。这样的日积月累，开 发人员作为技术多面手，就会成为软件生产和开发方面的“全方位专家”，这正是一个架构 师所必备的一系列专业技术技能。

 

于是，这样的两种专家型人员成为软件生产活动中的重要角色：我们需要开发人员这 样的“技术专家”在某个具体专业领域内的深入经验；另外我们更需要具有“全方位经验” 的专家成为系统分解和集成活动中的掌舵人，因为他们一般是自上向下展开工作的。当然， 由于软件活动的技术特点，对“技术专家”人员的需求量一般比“全方位专家”的霈求量 要大些。

幵发人员这样的单一技术专家转型为架构师这样的全方位专家，并不是一夜之间就能

促成的。这种转型也是有一个发展曲线，如图2乇所示。

 

经过了多项技术深入的经验积累，开发人员已经具备了作为初级架构师的技术广度。 达到这样的广度后，就可以从事软件系统某些方面的架构工作，例如：通信子系统的架构。 随着软件系统复杂度的增加，子系统架构师也会涉及或者配合更多类型的子系统设计工作, 从而积累了更为广泛的技术经验。只有在广度上不断进行积累，才能最终发展为一个“全 方位专家”，即“软件架构师”。当然，由于当今系统复杂度的提髙，作为“全方位专家,， 的架构师不可能在每个技术方向上都具有非常精深的经验，这就意味着软件系统架构师依 然不能离开各项技术专家的支持。

 

从上面的发展曲线我们能够看出：如果没有这样的经历，在以后的架构师生涯中就不 能最合理、最优化地拆分系统单元，从而不能充分发挥各个技术领域内“技术专家”的作 用。同时，没有先前“技术专家”的经验作为参照，也很难在架构和设计时与各个“技术 专家”进行有效的沟通。尤其是在一些设计决策时会产生严重的失误，最终的结果，要么 是构建的架构不具有可实施性，要么是这种掺杂了很多错误决策的架构本身的安全会受到 严重威胁。

当技术的广度达到一定范围时，我们就会意识到，软件产品生产或开发中其他深层次

的问题，就不仅仅是一系列的技术问题了。按照ChuckKi丨mer模型，摆在初级架构师面前 的发展路径有以下两个方向。

商业方面的发展：早在2003年，Luke Hohmann就在自己的研究结果中指出了一

个成功架构背后的非技术方面的作用。这意味着为了实现这样一个成功的软件架 构，架构师需要涉及许多业务活动：诸如与产品市场人员配合制订市场开拓计划、 分析竞争对手的产品特征、与客户/销售/产品经理等沟通产品要求和产品特征、与 产品线/产品规划人员制定产品路线图、协助商业经理计算产品的投入产出比 (ROI)、支持客服人员的产品服务活动等。这样一系列商业经验的积累，才能使架 构师在未来的架构活动中确保架构、设计、开发的高质量。

 

•流程方面的发展：架构师在工作的过程中，还需要深入到具体的业务流程中，对产 品可能应用的行业内的各个业务流程（子流程）进行深入的分析，清晰地总结出各 个行业内的工作流程，从而达到对这些行业核心商业机制和商业运作的理解。同时， 架构师需要精准定位各个行业内的角色设置及其所承担的职责，并且明确角色在各 个业务流程中的作用，从而在自己公司生产或开发软件产品时能够精确把握客户行 业流程上的需求。

在上述两个重要维度上’架构师视野的拓宽，标志着架构师知识和经验领域的重要发 展。到达这个境界的架构师，已经开始不单单以技术的视角去考虑问题’而是结合了更多 的非技术因素去更全面地考虑问题。架构师通过分析问题所发生的业务流程节点去理解问 题背后的商业情景，通过定位解决问题的备选方案在市场上的竞争能力，确定解决方案对 客户服务的要求等。这使得架构师能够取得更为长足的进步和更为丰富的经验积累。

 

如心理学和社会学方面的经验积累等。这更有助于架构师在纷繁芜杂的环境中进行有效地 规划、组织、交流、分析、平衡、决策和反馈。只有很好地积累和运用这些非技术方面的 经验，才能高质量地解决所负责的软件系统产品的开发问题。

 

完整经历了上述各发展阶段的架构师，已经成为了软件产品开发流程中的主角。我们 可以从架构师的工作流程上来分析架构师的职责，从而进一步分辨出架构师所应具备的能 力，如图2-7所示。

 

从软件产品开发流程上来看，架构师主要担负了八项主要的职责，而且这些职责贯穿 了整个流程。

平衡：架构师需要持续不断地在不同的维度和不同的需求之间进行平衡。平衡和 取舍各个利益千系人stakeholders的要求（客户、销售、市场、客服等）、平衡系统 特征要求和设计实施中现实约束条件的差距、帮助子系统架构师平衡性能与功能的差 距、平衡系统开发成本与系统要求的差距等。

 

一致：架构师需要保证各个stakeholders需求的一致性；确保公司产品规划、产 品线架构规划与本产品架构与设计的一致；确保客户要求、架构约束、设计准则在实 施阶段得到一致贯彻。

 

分解：为了解决大规模系统所带来的复杂问題，采取正确的分解动作是架构师必 要的应对能力之一。将负责问题分解为各个子问題（子系统），将子问题再分解为单项 问題（模块）等一系列的分解，是架构师的主要职责之一。

 

集成：作为分解动作的有效补充，集成能力是架构师的另外一项重要职责和能 力。与分解动作相比较，集成动作会更为困难一些。因为集成动作的主要目标是将 功能上的分解与系统性能和质量上的要求进行衔接，以便于正确引导下一步的分解 动作。只有高质量地完成了这种功能与质量的集成，才能使后续的系统分解更加可 行。这就是经典的“总-分•总•分”循环原理的实践应用。举例来说，当一个人攀登 一座高山时，不要闷头往上爬，最好边爬边看着山顶这个目标，及时校正自己的爬山 路线。

 

级览：纵览全局的能力是另外一个重要的方面。纵观整个系统及其存在的商业背 景，以便于制定出重要的设计指导规则和设计控制规則。这样在设计时，设计人员 就能做出正确的设计抉择。同时，纵览全局的能力也指引着设计人员逐步桄理出产 品的全面完整信息，为负责具体部分的设计人员提供了全方位的视角和完整的商业 情节。

 

靖捷和优美：一个“好”的问題分析模型，或一个“好”的问題解决模型，或一 个“好”的架构和设计，其中一个重要的特征就是简捷和优美。架构师不仅要使自己 的架构做到这一点，同时也要尽量使各个部分的设计工作做到这一点。但是，需要注 意的是，这种所谓的“优美”不是架构师个人的主观认知，而是要得到整个架构设计 人员统一的认同，这才是客观的“优美”。

 

保持龙整：随着开发工作的进行，开发的任务重点和待解决的重点问题也在慢慢 地发生变化和漂移。架构师要保持系统的要求能够平衡均匀地、有側重地、逐步地、 一丝不苟并且完整地实施。例如当开发成本发生了变化，架构师要使产品或项目开发 依然能够尽量完整地实现系统要求的性能和可靠性等。

 

吻合：在产品或项目启动、设计、开发、运行维护、服务等完整的生命周期内， 架构师的工作要吻合各个stakeholders的要求。这需要架构师对技术有着深入的把握， 同时在其他方面也需要有广博的阅历。

 

在软件产品生产和开发流程中充当主角的架构师，每日从事着各种各样的日常工作。 为了近距离地观察一个架构师，我们可以看看他们日常要做的一些典型工作，如图2-8所

 

架构师日常的大部分精力花在从那些非正式的场合进行细节信息的搜集、整理、预处 理’然后再经过缜密的思考和衡量后，以会议、走访、评审等较为正式的方式呈现出来， 这就意味着架构师要具备视角快速转换的素质，即从面向具体细节的视角到面向高层抽象 的视角之间进行转换。软件架构师的这种视角快速转换的能力，以及结合这两个视角并行 拓展的能力，可以说是资深架构师的一个重要标志。

 

需要注意的一点是，任何抽象都是基于具体事实而言的。架构师不能只停留在抽象这 样类似髙层面的活动中，因为这会使抽象脱离了实际，产生了抽象的漂移，成为架构师主 观认为的虚拟“现实”。

 

那么，到底什么样的人才具备成为一个架构师的潜质呢？怎样从众多的从业人员中选 择一个高素质的架构师呢？

 

对于软件从业人员来说，作为一个合格的软件架构师应该具备怎样的素质，这是困扰 着很多公司的问题。尤其在近些年来，越来越多的研究机构和公司开始关注类似的问题。 例如：2005年澳大利亚皇家墨尔本理工大学（RMIT)著名教授Keith Frampton在英国第

 

十届信息系统学术会议上就发表了著名的研究成果《架构师需要的能力》。

 

为全面透彻地分析架构师应该具备的素质，我们从一个架构师的成长轨迹、架构师在 公司业务流程上的职责以及架构师的日常工作j这三个视角的观察，就可以淸晰地看到一个 “理想架构师”的轮廓。

 

从图2-9列出的能力来看，一个理想的架构师的确需要非常广泛的技能和经验。这也 就导致从业人员中能够符合这种“多面手”要求的人并不是很多◎在实际工作中，当我们选择一个架构师或者努力成为一个架构师时，我们可以把上述的这些能力要求进行汇总， 突出如下一些重点的特征来作为衡量的标准。

•专业技能：一个架构师必须对专业技术领域具有足够深度（单项技术的专家）和广’ 度（技术全方位的专家）的实践经验。这样才能在工作中清晰界定每种技术的特点 及其相应的应用领域边界；同时深刻地认知应用每項技术所带来的可能收益和代 价；在客观条件发生变化时’及时明确每种技术可能的所有替代技术，或者及时明 确哪些技术之间本身就是互补的关系。只有这样深厚的技术技能，才能保证在设计 和实施阶段有选择性地、客观地抉择出适用的技术。更重要的是，在实施之前架构 师就能够在一定程度上预见到可能遇到的问題，这也是基于架构师先前对这些技术 的细节所拥有的丰富实践经验。

 

•商业经验：一个架构师对外应该熟悉客户的各项商业模式及流程原則，对内应该理 解本公司的商北运作模型和相关流程。更重要的是，要深入理解商业为什么会这样 运作，业务为什么会这样流转等这些最根本的原因。只有这样，才能在产品架构与

设计时准确地实现商业方面的要求，甚至在一定程度上帮助商业公司进行运作模型 和流程模型的优化，提供一定程度上的商业咨询。这也是所谓经典的“业务需求驱 动IT需要；IT发展驱动业务优化”中技术驱动商业的作用；同时，架构师还需要 在本公司内部产品生产与开发阶段中配合和遵循既定的商血及市场目标，对公司内 的产品战略规划及产品的市场定位原則提供强有力的支撑等。

 

»沟通技貌：架构师的沟通能力是一个至关重要的能力，而且不断地与stakeholders 进行沟通是架构师贯穿整个产品或项目开发过程的职责之一。一个软件系统或软件 产品的开发，以客户、销售人员、产品经理、市场人员等的要求为起点，经过架构 师的沟通转化为软件工程中严格的需求规格说明，澄清了各项功能的要求、非功能 的要求、质量的要求、时间的要求、成本的要求等。同时也将那些没有明确的、甚 至是隐含在要求中的需求澄清出来；随着项目准备工作的进行，架构师与项目管理 人员一起沟通项目总目标、预算、时间、人员、技术准备等；与设计及开发人员沟 通架构思想、架构规划及设计准则；与设计人员沟通校验设计思想和设计手段；与 开发人员沟通开发细节；与測试人员沟通如何验证架构与实施的方法及工具等。

 

平衡决策能力：架构师需要在stakeholders间进行平衡，目的是满足他们各个方面、 各种各样的功能及质量方面的要求；平衡架构及设计与实际实现之间的差距，尽量 平衡概念化、理论化的设计思路与客观技术约束和实际开发约束之间的差距。那些 抽象及概念化的思路，往往在这种有效权衡和抉择之后，才具有可操作性或可实施 性，否則就陷于空谈。架构师要在整个产品开发的每个价段持续不断地进行平衡与 抉择，这样才能使未来交付的软件系统满足各方的要求，同时也实现在软件架构中 计划的目标。

 

多任务处蕙嫵力：从架构师每日要从事的工作中可以清晰地看到，架构师要同时处 理很多方面的问題：面对很多人的渍询和挑战、参加很多会议、安排设计人员并行 工作等。这要求架构师能够提供一个协作及并行的工作乎台。这样的平台有助于系 统研发其他相关人员既能专注于他们自己负责的工作，同时又能方便地进行高效沟 通，以避免由于低效沟通（例如会议、电话讨论、突发事件等）所造成的身心疲惫。 这就要求架构师本身就具有很强的并行处理问題的能力，同时也能很好地安排各种 并行的设计、开发、沟通。否則，架构师或设计人员一旦被某些事件所阻挡，就会 陆续阻挡住很多人员的后续工作.从而严重影响开发的进彦八_

 

规划能力：一个好的产品线架构规划能够为公司清晰地界定出产品家族成员的个性 和共性，从而有效地节约开发成本并提高公司资产的复用能力；一个好的公司产品 长远规划可以为公司在商业市场上的定位和生命力提供铎有力的支撑；一个好的架 构规划可以为设计和开发人员提供了方向性的指南；一个好的架构远景会回答系统 如何演化的问题；这些答案能够保证为未来软件产品演化提供预留的接口。一个好 的规划要求架构师具有洞察市场需求、了解各个行北存在的问題、清晰地掌握技术 的发展趋势及存在问题解决办法的能力。“市场需求+行业问題解决办法+技术趋 势”是架构师制定远景规划的强有力武器。

 

驱动能力：一个好的架构师，本身就对自己正在构建的架构具有很高的职业热情。 只有这样，创作出来的架构才包含了情感的价值。成为了架构师自己热忱情感的一 个重要表现。这样的热情也会感染和驱动后续的设计实施人员将自己的职业热情倾 注在手中的任务中。从客观实际上来讲，这样热情的产出物，本身就仿佛成为了一 个有生命力的实体。当然，这样的实体还表现出了强劲的生命力和演化能力，这往 往是任何一个stakeholders都非常愿意接受的软件产品。相反，死搬硬套一些书藉 上的理论，机械地为了解决问題而解决问題，没有倾注任何职北情感的产出物，只

                        图2-10 架构师能力-总图

 

另外有一点经常为大多数人所忽略，即在架构师与职能经理（尤其是高级经理）沟通 时需要强有力的呈现（Presentation)技能。再好的设想、再经典的全局观和问题解决方案、 再有用的实战视角’如果不能很好地向公司重要的管理层呈现出来，没有人会接受你所希 望的变革。架构师在做Presentation的时候，需要关注以下几点：

要精心准备Presentation材料；

 

•运用业务领域内通俗化的语言及图标来组织Presentation; 

♦尽量简化沟通的内容，突出重点；

 

#进行预演；

 

^汇报时要公正客观、澄清利弊；

 

•要包含财务方面的信息（架构师往往忽略了这个重要方面 

•收尾要，出一些建议方案’供管理层选择„