官方系统架构设计师教程-ch15-架构师的管理实践

架构师的管理实践

在实践过程中，软件架构的主要障碍往往在于组织方面而非技术。创造切实可行的软件架构需要对技术的深入把握、良好的认知能力和沟通技巧以及大量艰苦的工作。技术上出色的架构往往由于没有全面地处理好组织管理因素而失败。架构师利用自己的知识影响团队，常被大家认为是无冕之王，因此架构师需要管理技巧。本章介绍了架构师的VRAPS实践。

VRAPS组织管理原则

VRAPS是为实践软件架构的组织管理原则提出的，包括构想、节奏、预见、协作和简化5个相关联的原则。每项原则都是实际可操作的，原则的提出都来源于构建软件架构的直接经验，并且都可以用来解释实践。VRAPS模型的焦点在开发和使用软件架构过程的组织管理方面，其应用环境不仅包括建立和部署架构的团队，还包括利用架构开发和利用产品线的团队和使用这些产品的客户。

受益人是指建立并长期保持架构的价值有重要影响的人或组织。受益人一般包括发起人、应用开发人员和应用客户，还可能包括其他重要的参与者，如技术供应方。

（1）构想原则：说明了如何向架构的受益人描述一幅一致的、有约束力和灵活的未来图景。

（2）节奏原则：刻画了一种在整个组织范围内的协调程度，即定期地根据可预测的速度、内容和质量对制品生产进行检查与规划。

（3）预见原则：要在预测未来与检查并适应现状之间做出平衡。

（4）协作原则：解决了如何识别对架构成功关键的团体，以及如何确保这些合作伙伴的有效支持。

（5）简化原则：要求理解组织的结构，了解架构最小的基本特征并最小化架构。

各个原则之间不是相互孤立的，图15-1解释了构想原则如何与其他原则交互。构想原则确立了总体方向，使得节奏原则所要求的协调工作能够进行。而一个好的节奏又可以使组织朝着构想原则制定的目标不断提供递增的进展。构想原则中的假设根据预见原则进行测试和验证。在架构演化中，应注意环境的变化，并把这些变化加入到构想中。构想帮助建立准则，以挑选合作伙伴和理解他人给架构带来的价值。这些合作伙伴的约束是一个好的构想的关键要素。构想对简化原则也起到了作用。预期的价值经过解释被运用到架构的决策中，而反过来又帮助完善构想。

图15-1　构想与其他原则之间的交互关系

所有其他的原则也是彼此之间相互影响的。例如，节奏原则中的协调组活动如果没有了协作是不可能完成的。通过在每个开发周期中关注最小的关键需求，节奏原则又帮助了简化原则的进行。

概念框架

为了更好地使用VRAPS原则，我们用准则、模式和反模式来对各项原则进行补充。准则用于判断每项原则的实施效果如何。模式描述了开发和使用软件架构时可能遇到的常见问题和解决方法，能够帮助组织改进原则。反模式则描述了组织在实践中可能遇到的陷阱。

准则

为了把原则运用到实践中，需要可操作的实施细节。准则把广泛的原则翻译成是否和如何执行原则的细节。

模式

第一项原则都附有一组模式，它描述了开发或者使用软件架构时可能遇到的常见问题的解决方法。模式更注重于解决特定情况下的问题，传达了在给定背景和多方竞争因素下针对常见问题的解决方案。

反模式

反模式描述了组织在实践中可能遇到的陷阱，描述了不该做的事情，或者用在错误背景下的解决方案，可以帮助更深入地理解原则。

形成并统一构想

构想描述了架构的未来，提供了架构使用的环境和动机。构想是未来价值到架构约束的映射，构想要成功，则必须把它所能提供的价值与客户的约束相对应。构想也必须是明晰的、有约束力的、一致的和灵活的，从而能够被其受益人理解并有效地运用。

例如，在大型组织中，管理层可能把项目架构师与维护产品构想的高级经理分隔开来。这种距离会维持构想一致性，导致架构难以满足维护要求，引发后期运行成本问题。为了应对类似组织结构产生的复杂性，高级经理和架构师之间建立稳固的、积极的关系以及共享统一的构想至关重要。

把价值映射为架构约束，要求开发人员把约束诸如接口、开发语言和模块边界等映射到特定的客户价值上。促使受益人把约束与客户价值捆绑需要高超的技艺，用例建模是把架构的预期使用与能够被满足的切实的用户目标连接起来的一种方法。例如，识别并表达出似乎无关的用例之间的实质性联系是建立构想的一个重要内容。

形成构想

构想需要维持一致性与协调性。一致性是指受益人的各种期望之间妥协，以及它们与现在和将来的架构之间的需求满足程度。灵活性是指受益人在不破坏架构的情况下，在现有架构之上完成事先没有预料到的需求的容易程度。

一致性并不意味着所有受益人之间拥有一张完全一致的构想视图，而是指各受益人共享的视图根据他们不同的视角保持一致。RUP的“4＋1架构视图”体现了获得这种一致性的方法。RUP通过逻辑视图（Logic View）、实现视图（Implementation View）、进程视图（Process View）、部署视图（Deployment View）和用例视图（Use case View）建立了架构视图。这些架构视图的不同点在于，它们根据不同目的表示系统（例如，用例视图表示了系统的最终用户功能）。

架构师常负有将现实引入业务构想和将构想变成现实的责任。架构师可以推荐技术，包括如何以及何时采用这些技术，由此来帮助确定业务构想的哪些部分可以在短期内实现，以及各部分实现的次序。

架构师更像管理者而并非实施者，Dean Thompson说：“作为架构师更多地意味着权衡业务、组织运作和使用技术，而不仅仅是技术细节。”例如，架构师应该全面研究整个组织，找出各利益方关注的重点，然后妥善平衡，建立符合主要关注问题的架构描述。

多方整合能促进构想的形成。多方整合是组织各利益方的机制，用于确保获得构想并使其稳定；是指在一个公共的组织层次上对信息、决策和资源进行协调。多方整合能使从事硬件设计的基层经理理解软件设计和开发人员，以及市场营销、客户支持和市场营销的同事的期望，包括增强组织与客户和外部供应者沟通的能力。

Thompson归纳了形成架构构想的三步方法：清楚明确地阐述一条迫切的客户价值；将客户价值映射为少数特定的能解决的问题；将以上问题转译成一组特定的约束条件。

成功的架构师用明确的客户价值映射规划未来，以使用户及它们的客户能将其与约束联系起来。架构师必须格外关注产品开发人员和最终的客户，而且为了成功，还要发动所有其他人做类似的事情。

将构想原则付诸实践

下面的准则、反模式和模式能帮助建立、形成、维护一个被共享的构想，将构想原则付诸实践。

用于检验构想原则是否起作用的准则如下。

（1）架构师的构想与发起人、用户、最终客户期望实现的目标是否保持一致。

（2）实施人员是否信任并使用架构。

（3）关于架构和构件的潜藏知识对其用户（开发团队）是否是可见的、可获得的。

构想原则中准则到模式、反模式的映射如表15-1所示。

表15-1　准则到模式、反模式的映射

下面详细介绍与各准则相关的反模式和模式。

准则1：架构师的构想与发起人、用户、最终客户期望实现的目标是否保持一致。

为了获得一致、迫切和灵活的架构，需要产品线经理、架构师和实施经理等达成共识。而如果没有阐明用户价值，则会导致构想脱离了重点。

与准则1相关的反模式与模式如下。

1）反模式：风险后置

形容这样统一受益人的构想：用最小的妥协、最大的优化规划出一个构件以满足所有冲突利益的需要。这种统一方法的问题是，设计出来的构件往往在理论上可行，但实际运行中出现风险。

一条新产品线的架构师或经理，需要开发看似很棒但实现有风险的构件。这些要完成构件可能需要打破“物理定律”才能完成，这些风险可能在制品交付的最后才能显现。可是有一批工程师仍然坚持开发这些构件。风险构件被安排到最后完成，以为这样可以有时间消除风险。可是，当计划好的完成日期临近时，依然无法交付。尽管架构在演示的幻灯片上运转良好，实际上却无法正常工作。

面对这种情况，需要分析并阐明风险，向高级经理提供一个选择，要么承认风险，要么调整任务。

2）模式：前后一致

要求推动架构投资的高级经理积极地维护构想，并防止构想受到短期压力的影响。

一个公共的架构被几个产品共享，它已经变得比预期要复杂得多。而客户们针对每件产品又提出了以前没有预计到的功能特性。如果加入这些功能特性，则不能保证进度，但如果不开发这个特性则可能失去一位重要客户。

这样的情况下，需要评估架构构想的质量和稳定性。只有当两者都正常时，才能采取进一步行动。如果该新特性不属于原来的产品构想支持的代价范围，那就应该放弃开发这个新特性。如果构想不明确，在短期内就交付很可能导致大量缺陷。此时应与客户、架构师和销售、产品、支持人员以及开发经理一起加强产品的构想。如果这个特性确实属于一个稳定的产品构想，那么应该在开发组织内核实这种一致性。

准则2：实施人员信任并使用架构。

只有使用架构，才能从中获得价值。然而，要让开发人员对架构构想充分信任需要做更多的工作，仅仅靠不断兑现承诺是不够的。开发人员需要把他们对构想的了解与他们认为对下一步行动有用的东西联系起来。开发人员在利用架构的过程中，可能会使架构向许多不同的方向发展。一个良好架构应与构想保持一致，同时又能满足用户的需求。

与准则2相关的反模式和模式如下。

1）反模式：墙头草

描述了这样一种情况：因为没有良好的构想，导致架构方向在竞争和客户压力的影响下经常改变。这种构想永远不能达到稳定以便有效地被共享。

在开发过程中，经常会出现这样一种情况：来自客户、竞争对手和高级经理的压力使得需要在一次发布的中途加入一些代价高昂的功能，高级经理甚至可能在没有咨询架构师的情况下决定提供这些功能。可是一旦交付了某个激进的功能，组织马上就会陷入对该功能的支持工作中。以后的发布会因需要提供向后兼容而变得更为复杂。

在这种情况下，要做的是理解并阐明构想。方便变更需求是成功构想的一部分，要对其进行规划。高级主管要与架构师一起紧密地工作，理解变更的后果并做出正确的权衡。在建立了构想之后，可以用前后一致模式来评估特定的变更建议。在把功能特性加入到发布之前，要坚持达成一致意见。这需要一种固定的机制，以使达成一致成为正常业务的一部分。如果架构满足了高层的约束条件，那么在细节的实施方面可以允许更多的灵活性。在最极端的情况下，解决墙头草问题可能需要寻找新的、期望更为接近的受益人。

2）模式：三个臭皮匠

三个臭皮匠：反映了这样一种认识，即架构师并非总是架构构想的来源，架构师和客户一起充实、完善构想。

一个共同的架构或平台是产品线战略的关键，架构发起人希望产品团体能开发出“杀手解决方案”，而同时又能避免追随新的标准、潮流带来的困扰。

在这种情况下，需要抵制创建一个无所不能的架构的诱惑，建立一种能让架构师及其用户都能丰富、实现功能特性的构想。高级经理只提供构想、目标和原则，把架构和平台留给架构师，把实现细节留给合适的团队或层次。一个成功的产品线架构必须能为适应市场变化，能适应和采用新技术，能解决在概念阶段还不知道的但变化场景可预见的问题。

这是一项很少有架构师能独立完成的任务，然而，通过高级经理建立正确的顶层业务构想，架构师采取实现构想的正确行动就能取得成功。

准则3：关于架构和构件的潜藏知识对其用户是可见的、可获得的。

1）反模式：一叶障目

一叶障目：发生在这种情况下：开发人员过分专注于应用，以致不知道其他架构解决同类问题的通用的解决方案。

在一个组织中，工程团队正在实践代码所有制模式，工程师们都把精力集中在自己眼前的任务和职责上，没有把自己当作一个共享资源的看护者。陷入本反模式的工程师的视野很窄，面对其他开发同事的请求往往只求解决问题，不愿意多加考虑。这样导致的工作结果可能变得非常复杂、脆弱而且容易出错，这是由一名工程师所无法预见的情况造成的。

要解决上面的问题，需创造一种分享知识的愿望。例如，工程师培训等方式就可以起到一些作用，整个组织的人员启用知识管理平台也能促进产生这种愿望。

2）模式：轮流工作

轮流工作：要求参与架构的工作人员轮流在架构的不同部分上工作。这样能使他们对架构有更多的了解，并有机会发展非正式的人际网络。

当一个产品线的销售增长到一定程度，一个单一的、聚集的团队已无法支撑架构和实现，人员被重新组织到地理上分布不同的团队中。已有的沟通管道与新的形势已经不相适应。

通过帮教制（Apprenticeship）模式阶段性地轮流交换构件的所有权可以解决上面的问题。组织和鼓励构件的前任负责人抽出时间帮助新的负责人，轮转周期应该尽可能地与发布进度保持同步。该方法能使开发人员更容易地发现如何找到有关构件的知识，团队成员掌握某个构件或者在出现问题时知道应该问谁的可能性也大大增加了。因此，意外发生的次数减少了。

节奏：保证节拍、过程和进展

节奏原则使得软件架构在跨越组织边界的情况下开发和使用成为可能。由于许多参与开发和使用架构的团体是自治性的，不可能自上而下地协调这些团体，节奏原则提供了一个随时间变化的框架，可使团体同步各自的活动与期望。有了节奏，参与者就能知道何时关心和应该关心哪些活动。不仅计划中的活动可以被协调管理，节奏原则也可以协调那些非正式的但很关键的活动，例如团体间的交流，这样参与者就可以知道何时应该或不应该提出对于信息或支持的要求。

节奏定义

节奏是一个架构团体内部及它与客户和供应者之间反复出现的、可预测的工件交换活动。节奏有三个元素：速度、内容和质量。速度是指一个团体与另一个团体之间同类型交接发生的频率，例如架构团队与产品开发工程师之间。如果交接的时间是可预测的，移交则容易管理。稳定的发布计划是速度的一个例子。内容是指一个团体向另一个团体提供的价值。例如，一个团体开发一种新的或者要修改的特性被另一个团体用于满足某种需要。质量的含义是遵循开发过程确保架构没有缺陷。组织可以通过省略非增值的步骤来加快速度，但是如果重要的流程被截掉了，节奏就会遭到破坏。

节奏在团体和组织之间与内部提供一种协调活动的稳定力量，帮助移交管理。当节奏很强时，受益人能培养很强的预见、实施移交和交接的技能。节奏还能驱动活动完结，拥有良好节奏的组织通过建立有规律的阶段间隙来推动评估、再评估和其他工作的进展。

将节奏原则付诸实践

没有建立节奏会导致客户不满意、不期望的错误发生和工件无法一起工作。只有当以下准则出现时，才说明节奏原则起了作用。

（1）经理们定期地再评估、同步和调整架构。

（2）架构用户对架构发布的进度和内容具有高度的信心。

（3）通过节奏协调明确的活动。

节奏原则中，准则到模式、反模式的映射如表15-2所示。

表15-2　准则到模式、反模式的映射

准则1：经理们定期地再评估、同步和调整架构。

好的节奏需要有规律的节拍。对于架构组织的管理者，这意味着他们必须在稳定的间隙上再评估、同步和调整他们的架构计划。节奏的节拍还能提供一个计划过程的框架。具有良好节奏的一个组织用节拍而不是时间来衡量进度。

预测、验证和调整

为了使对软件产品线的长期投资能产生回报，组织必须确保架构满足许多应用的需求。组织应能够预见变化并对变化做出反应，包括那些在设计架构时还没想到的需求。架构必须能够适应新的技术、标准、市场和竞争对手。刚开始设计架构时正确的假设几年以后可能就失效了，这就要求组织必须能够对架构进行预测和演化。

预测、验证和调整的定义

预见是指建立和实现架构的人员根据变化的技术、竞争和客户需求预测、验证和调整架构的程度。

软件架构师不可能总能预测到未来。但是，既然一个成功的架构将被持续使用很长时间，架构师至少要对未来将发生什么做出合理的猜测。架构师必须考虑架构用户可能怎么变化，竞争形势将如何改变，未来的运行环境是怎样的。架构必须能够适应新的组织结构，特别是在一些像银行业这样合并和接管司空见惯的领域中。许多计划建立在对未来的假定上，但是预测意味着这些假定是作为架构描述的一部分而明确表述的。例如，有关的假定可能基于这样一种未来的情况：处理器速度依然遵循摩尔定律，在以后的10年里每18个月翻一番。当然，除非架构师有预知未来的超自然能力，否则这些预测不可能总是正确，所以需要验证。

验证不仅局限于传统软件工程的测试和检查技术，也包括对架构的基础假定的测试。例如，用户真的想要计划好的东西吗？现有的技术能实现用户的需求吗？分析这些假定的重要原因是，架构师及其发起人做出了许多关于架构的艰难决策。在架构成型前要对这些假定进行检查和确认，否则会导致代价高昂的错误。

软件架构的长期成功依赖于对假定的变更和通过预测及验证所获信息的适应程度。调整就是对架构计划及架构本身修正以加入新特性，从而能参与新兴市场的竞争或者在新的环境中生存。因此，调整要求组织具有敏捷性。调整可能不仅包含架构本身，还包括计划，甚至整个架构构想。

将预见原则付诸实践：准则、反模式与模式

下面的准则、反模式和模式为帮助判定组织在预见验证、调整架构方面提供了指导。当以下情况发生时，说明预见原则发生了作用。

（1）不断增强架构的响应能力：预见到的风险和架构客户及其客户的需求；市场驱动的标准和演变的技术；战略性业务方向的改变。

（2）通过快速复审和开发周期，评估技术和业务上的风险与机会。

（3）当认识到关键的估计或假设有错时，及时调整功能特性、预算。

表15-3　准则到模式、反模式的映射

表15-3　准则到模式、反模式的映射-续表

准则1：不断增强架构的能力以响应预见到的风险和架构客户及其客户的需求，市场驱动的标准和演变的技术，战略性业务方向的改变。

与此相关的反模式与模式如下。

1）反模式：遗漏细节

遗漏细节：描述了发现一个明显的功能特性被遗漏时的尴尬经历。每个人都关注发布的强大新特性，以致忽视了一些用户必不可少的功能。

对这种情况，需要识别关键用户群，和他们一起找出最重要的需求。这意味着要有一位对这些用户群有着深入了解的专题事务专家的参与。要调查的问题包括“哪些产品会建立在这个架构之上？”，“哪些产品是最重要的？”该方法也可以用来指导架构方向的改变。调研的覆盖面很重要，需要让高级经理了解这一过程以使他们在敦促实现其他高级特性和技术的时候，不会在无意中破坏这些基本特性的交付。

2）模式：示范区

示范区模式应用在如何决定哪个产品应该引入一个新架构的情况下。

挑选一个项目初步实现架构。该项目的客户渴望采用新技术，而且也愿意容忍获得该技术时可能存在的不便。当示范区项目投入使用后，架构师将从实际使用中得到关于架构的有价值反馈。在架构大范围应用之前，缺陷将被发现并解决，这也意味着缺陷的修订受后向兼容问题的约束较小。成功的示范区项目可以在建议其他项目时作为参考。

准则2：通过快速复审和开发周期，评估技术和业务上的风险与机会。

1）反模式：品尝未熟的果实

品尝未熟的果实：说明了当架构师没有考虑其用户的客户，而让其用户支持一种未成熟的技术时发生的情况。

在发起人的要求下，架构师采用了一种新技术来建立下一代架构，团队希望通过它胜过最接近的竞争对手。客户对架构糟糕的性能和各种各样的差错感到很失望，客户并不关心底层技术，他们只需要那些能帮助他们实现目标的东西，一些被以前的换代或升级害苦了的客户则对关于未成熟技术的承诺极度不信任。

在这种情况下，要审慎地选择引入新技术的正确场所。在引入后，要为最初用户提供额外的支持。在选择新架构解决方案时，必须愿意修改技术不完善的部分使其适合一个实际可用的解决方案。不要假定一个未经验证的架构能实现所有的承诺，应该分别在开发人员和产品用户的特定环境下测试你的解决方案。即便如此，还必须向采用新技术的用户提供大量的支持，要谨慎地设定用户正确的期望，留意他们可能遇到问题的迹象。

2）模式： $\color{green}{\text{架构复审}}$

架构复审模式总结了怎样针对开发中的架构组织执行一次有重点的专家评估，以揭示有重大影响的问题和机遇，例如假设的冲突、可重用的现有方案等。

该模式提出在开发周期的关键时刻成立一个架构复审委员会以检查架构。一旦需求基线初步确定就应该进行首次复审。复审委员会的成员应该包括有经验的架构师、架构小组成员，可能还有客户，人员不要太多，最多七、八个人。在早期复审中，应检测各种假设，看看市场上是否有可购买的解决方案，并进行其他条理性检查。后期的复审应验证假设，确认架构是否满足了需求。注意要让这些复审保持重点。

这种模式可以避免增加成本，因为复审能够在开发过程的早期发现缺陷，这样就可以及时修正。复审能发现可以取代新的开发活动的构件。此外，它还增强了客户对架构提供已承诺能力的信心，从而促进客户使用架构。

准则3：当认识到关键的估计或假设有错时，及时调整功能特性、预算。

1）反模式：创造奇迹

创造奇迹：描绘了当足够的证据显示基础假设和估计已经完全偏离目标时，对架构开发和实现计划不作任何修改将发生的情况。

解决方法分为如下两个部分。

（1）找到架构的基础假设并积极努力测试这些假设。架构复审和示范区模式提供了获取这类信息的手段

（2）一旦发现错误的估计或假设，必须准备好对此采取行动。这可能意味着调整项目进度、功能特性或者启动意外处理计划，此外还包括提醒客户并重新协调进度和发布的内容等。

还应该特别小心那些遏制信息和创意传播、掩盖错误假设的证据的组织文化。无论何种情况，都应该确保把足够的资源编入预算计划，使得当不可避免的意外发生时，有可分配的进度和人员。

2）模式：外包

外包模式展示了怎样适应这种情况，即客户要求的新标准或技术并不属于当前或计划中的核心能力。它提供了指导以说明何时及怎样选择一个已有的第三方构件，或者与供应者合作。

如果存在第三方构件，应考虑采用。如果没有这样的构件，那么组织应该找到合作伙伴来开发和支持该构件。要确定潜在的合作伙伴是否把你需要的构件视为其主营业务的一部分。例如，他们是否能够把它卖给许多其他的客户；评估他们交付和支持该构件所需的特定工作量。把潜在的合作伙伴当作供应商和业务伙伴以评估其能力和信用。基本的规律是，他们必须为你做的专门开发越多，信任程度就要求越高。类似地，信任度越低，你面临的进度和财务风险就越高。如果发现一个非常可靠的潜在供应商，就应该外包构件开发。

协作：建立合作型组织

协作也是软件架构成功的关键之一，因为不同团体参与者对架构的开发、实现和使用都是很重要的。这些团体跨越了各种各样的组织边界，如团队、地理位置、部门甚至公司。每一个对架构关键的团体必须知道如何使用、努力改进架构从而为自己的利益服务。协作原则解决了如何识别对架构成功起关键作用的团体，以及如何确保这些合作伙伴的支持等问题。

协作定义

协作是指架构受益人保持明确的、合作的角色并将其所提供和获得的价值最大化的程度。合作是指受益人彼此之间存在一些共享的预期，应该明确表示出达到或未达到预期会有哪些奖励和惩罚。成功协作不仅仅要求架构负责人满足契约条款，合作伙伴还必须采取行动确定和提供预期价值，根据已达成的条款给出特定问题的解决方案。

将协作原则付诸实践：准则、反模式与模式

协作很容易理解，但将其付诸实践并不简单，当许多团体必须在一个组织内（外）的同一层次上进行合作时尤其如此。正式定义的协作网络与非正式协作网络决定了一个软件架构能否成功。以下准则提供了一种方法用来确定受益人为了使架构与产品服务的价值最大化而进行合作的程度。当出现以下几种情况时，说明协作是有效的。

（1）架构师不断地努力了解谁是最关键的受益人，他们如何贡献价值，以及他们需要什么。

（2）受益人之间达成明确和强制性的契约。

（3）通过社会行为制度和非正式规范强化合作。

表15-4介绍了准则到模式、反模式的映射。

表15-4　准则到模式、反模式的映射

准则1：架构师不断地努力了解谁是最关键的受益人，他们如何贡献价值，以及他们需要什么。

满足受益人的需求说起来很容易，实施起来要困难得多。挑选一批集中的首要客户，找出保证他们参与需要做些什么，然后交付这些内容，这样做可以增大成功的机会。

与准则1相关的反模式和模式如下。

1）反模式：光说不做

光说不做描述了这样一种情况，即架构师知道了用户的需求却遗漏了为了向他们提供有价值的东西所应该做的事情。

架构师忙于其他事务，没有与开发人员进行稳定的交流，各产品团队按照自己的理解开发并升级了产品，放弃了原来同意的清晰的接口。

与许多反模式一样，该反模式中最困难的部分就是，当发生这种情况时如何识别它。当你认为“我们可以以后再补充这些细节”时，应该保证你和你的团队至少理解一些关于开发人员如何从平台获益的明确的例子。模式“了解你的受益人”提供了一种掌握需要哪些措施让受益人参与协作的方法。客户互动模式提供了一些明确、简单和直接的规则与建议，有助于发展有效的协作关系。

2）模式：了解你的受益人

本模式说明了如何利用价值链来识别关键受益人，积极听取他们的意见并获得承诺与支持。

把架构成功的构想与那些最符合合作伙伴能力并积极去做的事情的活动统一起来。阐明设想中架构所能提供的价值，例如架构如何帮助现有产品取得一致的用户界面或者继续保持市场优势，或者是能打开一个针对新产品的全新市场。在初步阐明构想之后，确定潜在的合作伙伴以及他们的能力和利益如何与构想保持一致。

准则2：受益人之间达成明确和强制性的契约。

1）反模式：不记录讨论结果

不记录讨论结果说明了当一个架构团队回避采取必要的行动与其最直接的用户达成明确的契约时会发生什么情况。当用户们失去兴趣时，虽然对话仍在继续，但是讨论已经失去了实质内容，而且通常会浪费所有人的时间。

要确保取得对关键受益人的利益与职责的明确理解。把这些认识记录下来，当互动变得消极或者缺乏建设性时，可以求助于这些文件。这种做法总是很重要，对于那些对别人有强烈影响的参与者而言尤其关键。当状况似乎要失控时，回到当初的约定可以把架构团队从漩涡中解救出来。

2）模式：互惠互利

本模式介绍了一些非常重要的做法，用来建立足够稳固的关系以保障软件架构的共享和成功使用。

互惠互利要求在合作伙伴之间进行公平、主动的价值交换。当共享一个架构的团体之间的关系定义好之后，应该对正式和非正式的契约复审以保证公平的交换。预算中应该包括代码负责人响应其他团体请求所花的时间。要对各个团体支持其他团体的程度进行衡量，而不仅仅评估他们完成自身任务的情况。

准则3：通过社会行为制度和非正式规范强化合作。

协作包括正式和非正式两方面，为了真正巩固协作，需要用社会行为制度和非正式规范来促进合作。

1）反模式：非正式时间做正式工作

非正式时间做正式工作介绍了这样一个情况，即一位工程师申请修改某个构件以便让其他团体使用，却得到一个令人困惑的答复：“你可以做，但是要用你个人的时间。”

让工程师利用业余时间修改，架构师就失去了控制其过程和结果的能力，他可能没有采用组织的文档标准，诸如同级复审等步骤甚至连测试也有可能被删减或完全忽略。如果这种产品加入到其他团队的工件中，这位工程师在需要完成日常任务同时，还接到大量要求提供支持的请求，导致工程师精疲力竭。

对于以上情形，要制定计划奖励工程师花在共享构件上的时间，尽早兑现奖励能减少工作量和大量压力。应仔细考虑如何处理将来这一构件成为多个外部项目的关键的可能性，在权衡利弊时必须根据组织纪律和常理判断，包括企业文化、管理的洞察力、进度压力的程度以及当前状况的细节。很多组织把员工用于开发、维护被团体或项目外部所共享的解决方案的时间编入预算，这样能够预防工程师在利用非正式时间做正式工作开发时对项目的代码偷工减料，并确保你的小组对其他团队或项目的支持能力。

2）模式：杜绝意外

该模式描述了如何在不失去依赖你的构件的其他团体信任的情况下，调整对进度或功能特性的承诺。

要尽早提醒用户注意变更，并及时协商解决方案。在决定变更的内容之前，要确保通知、咨询了构件的用户。让他们了解虽然现在的做法对软件架构能产生直接的影响，但其实它们有着更为广泛的应用。

3）模式：和HR密切合作

和HR密切合作介绍了这样一种做法，即提拔雇员并不仅仅根据个人的技术技能和经验，还要考察其有效地、合乎道德地利用非正式人际网的能力。

软件开发是一种社会活动。可是，很多工程师属于内向型性格，工程师需要与他人交流以获得完成其工作所必需的信息，大部分高级技术岗位要求能迅速获得广泛的潜藏信息。有着广泛非正式人际网的工程师比没有这种网络的工程师能获得质量更好的信息。

在作提拔决定时，要考察一名工程师的非正式人际网的有效性。此时，应找出具体的事例，例如，这位工程师是否通过团队外部的合适人选，获得了曾困扰其同事、阻碍项目进展的问题的答案？如果组织已有晋升的明确标准，那么也可以对此标准做类似的调整。经理们应该避免破坏非正式人际网。

简化：澄清与最小化

架构师和高级经理必须协力保持架构和组织的平衡。聚焦于客户和业务价值，为架构师提供了方向和指南。确定关键价值是不容易的，尤其是当新客户和新产品的加入使架构偏离原来的方向时，困难会显著增加。构想定义了这种关键价值，而且为实现价值建立了约束。简化则将构想翻译成产品。

简化软件架构的原则概念上看似简单，而实践中它要求对价值非常坚定地专注，以及对架构所生存的组织的理解和支持。架构师必须了解架构最小的基本特征。简化原则还要求通过努力，把这些特征传达给实现架构团队的每一位成员。

简化定义

简化是指将所作用组织与环境都进行巧妙地理解与最小化，组织形成架构并且思考架构。在决定简化架构时，应当留意组织的结构；否则，你会发现你所做的改变只是暂时的。因此在简化架构之前，必须澄清组织和架构。

澄清组织意味着真实地理解你计划部署架构于其中的组织结构及其影响力（force）。架构对架构团队和客户都必须是清晰的。在简化架构之前，架构师必须精确地知道架构被期望做什么和如何完成这些任务。有时候看似很容易的任务，结果实现起来却很复杂，如果这些复杂性没有被理解清楚，那么建立的架构就可能完全不适合目标任务，而这样的架构会使实现更加复杂。澄清架构就是提供用户所需要的细节。

如果一个组织具备简化、协作和节奏等技能，长期共享架构就能够最小化代码、文档和过程。不必去新发明大量新的代码，却可以开发一种被工程师跨组织共享的公共语言。共享也能促进理解，因为它能最小化用同样术语描述完全不同概念的风险。共享并不能自动产生最小化，在有些不好的组织情况下，共享可能导致架构膨胀。

将简化原则付诸实践：准则、反模式与模式

当以下准则都满足时，说明简化原则起作用了。

（1）开发人员长期使用架构，减少了总成本和复杂性。

（2）架构小组明确理解关键最小需求，并且将其构造成多应用共享的核心元素。

（3）通过长期的预算和行动确保当相关元素没有被共享、增加了不必要的复杂性时，或者是因为有明确的业务理由时，把相关元素从核心移走。

表15-5介绍了准则到模式、反模式的映射。

表15-5　准则到模式、反模式的映射

准则1：开发人员长期不断地使用架构，减少了总成本和复杂性。

使架构被正确地使用，需要获得并维持经理和实施人员的信任。当存在一个明晰的公共架构构想时，系统可以逐渐变得更加简单。Grady Boody发现，“只有对一个系统的架构有清楚的理解，才能揭示公共的抽象和机制。”利用这种公共性能构造出更简单、更小和更可靠的系统。

与准则1相关的反模式和模式如下。

1）反模式：简单复制并修改

描述了当程序员在学会使用或重视架构之前被强迫迅速完成任务时发生的情况。他们不与构件负责人协商变更就复制并修改架构的部分代码，虽然复制提供了一个快速应付开发新特性的压力的方法，但是它通常会带来深远的后果。例如，如果在原始代码中发现了一个缺陷，组织怎样才能确保修正你和同事复制的所有代码呢？

在一个构件的生命周期中，有几个时机可以避免复制。鼓励工程师在复制构件之前先从构件负责人那里获得变更。可以把避免复制的推测方法加入编程风格指南，以便在代码复制期间识别和去除复制；如果有恰当的理由，这些推测方法可以允许有限的复制。也可以用自动化工具来识别复制代码，特别是在大型遗留系统中。当复制被识别后，可以用一些代码重组技术来去除重复的代码。

2）模式：由慢而快

描述了当开发人员为了跟上进度而拒绝使用架构结果却更慢时应该怎么做。解决方法是：放宽进度，加强过程。

让开发人员参与架构期望解决的问题的讨论，并通过开发部分解决方案来培训他们，给予过程比进度更高的优先级。指导开发人员逐步采用架构，把以前使用过这种过程有能力修改架构或过程来解决不同问题的专家介绍给开发团队，系统地、认真地遵循验证过程。

准则2：架构小组明确理解关键最小需求，并且将其构造成多应用共享的核心元素。

与准则2相关的反模式与模式如下。

1）反模式：缺乏有效抽象

缺乏有效抽象是直接面对应用编程，虽然开始简洁，但随着应用发展，系统缺乏共享基础。该反模式描述了两种简化的努力走向极端的情况。榕树描述了长期建立单点解决方案的后果。单点解决方案通常是满足一个特定客户需求的最简单方法。根部肥大描述了一个架构或平台小组为平台所支持或可能支持的每个产品开发了专有的特性。

开发小组通过从头开发或者复制一个相关产品，然后根据当前问题进行修改来确保产品尽可能地简单。这样可以很快向客户提供初始产品。然而，这些产品没有共享任何东西。随着每个产品的维护和升级。榕树反模式开始出现，各个产品之间的分离越来越大。由于没有被一个共享平台强力支持，每一个分离产品都要求有自己的支撑结构，很像一棵榕树的分枝被很多枝蔓支撑。

对于这种情况，可以考虑采用类似先复制后合并模式的方法把很多为了适应特定功能特性而被修改的核心架构部分重新并入内核。如果先复制后合并和维护多个产品都不可行，就应考虑通过框架团队来建立一个共享平台。

根部肥大反模式则用枝少干粗的形象描述了这样一种情况，即一个架构或平台小组开发了太多针对单个客户的特性。结果共享了太多的功能，导致平台太大、太慢、推出太迟。根部肥大看起来就像一个倒立的马提尼酒杯，底部很大，杯口太小。

通过其他安排帮助产品小组开发不属于架构的产品特定模块，防止产品专有特性进入平台。把一个最小的共享特性集列入平台计划，并根据优先级以稳定的发布进度交付特性。

2）模式：迁移途径

迁移途径反应了在这样一种情形下的解决方案：架构师打算利用当前架构来支持一个新的有价值的应用领域。但是要在该新应用领域获得成功，需要当前用户所不具备的技能和观念，而拥有这些技能的用户团体却习惯于与当前平台不同的解决问题的方法。

对于这样一种情况，要选择一类最有可能扩大架构价值的采用者，并且努力使架构能被他们很快地理解和采用。考察所有类型的早期采用者，了解他们解决问题的方法和技能。确定哪一种类型最有可能理解或者预见到技术革新的成效，并且严格衡量该类型的用户是否具备解决方案所需的技能和知识。为有目标构想但缺乏重要技能集的专业人员提供迁移途径，提供一个简单的从平台获得基本成果的方法。然后，引导这些用户逐步更具体地使用平台。

准则3：通过长期的预算和行动确保当相关元素没有被共享、增加了不必要的复杂性时，或者是因为有明确的业务理由时，把相关元素从核心移走。

改进一个架构需要时间和经费的稳定投入。稳定性确实很重要，因为当高级经理或主管最不愿意专注于架构时，也是架构最脆弱的时候。他们很容易被诱惑把架构师拉去参加一个紧急的项目以实现一个新特性，而使架构无人照看。

与准则3相关的反模式与模式如下。

1）反模式：编码大于架构

该反模式表明要防止架构师成为实现者。

首席架构师负责调整和维护架构，却被调动了工作要求竭尽全力地实现一个新特性集。这些特性实现了，架构小组却失去了领路人。因为没有时间对架构做出深思熟虑的改变，只好创建了架构的一个特殊版本来解决问题。结果新特性无法适合当前的架构。因为维护一个缺乏概念完整性的产品的工作量太大，结果问题越来越多。

为了防止出现这种情况，应该把首席架构师的时间合理分配给实现新特性和调整架构两个任务，让最能干的工程师来领导实现新特性。在提供时间和资源的同时，允许首席架构师指导实现，以使架构适应新的需求。

2）模式：统计构件变更

统计构件变更是一种通过观察不稳定程度来挑选需要调整的架构构件的方法。

如何才能知道应该重组（Refractor）什么——即从内核去除或简化什么呢？通过长期观测每个构件或子系统的不稳定程度，那些最不稳定的构件就是重组的候选者。因为不稳定表明构件是脆弱和不灵活的，因此应当根本改变该构件。也可以采用其他监控策略，例如监控讨论组以掌握经常被请求的构件。一名经验丰富的实施人员利用该方法可以很快确定哪些构件和子系统是简化的最佳目标，从而节约了时间和精力。