系统架构师学习笔记_第十五章_连载

第十五章  架构师的管理实践

软件架构师的主要障碍 往往在于组织方面 而非技术，技术上出色的架构往往由于 没有全面地处理好组织管理因素而失效。

15.1  VRAPS 组织管理原则

VRAPS 包括 构想、节奏、预见、协作、简化 5个相关联的原则。

受益人 是指 建立并长期保持 架构的价值 有重要影响的人或组织。

1、构想原则：描述一副 一致的、有约束力和灵活的未来图景。

2、节奏原则：协调程度，根据可预测的 速度、内容、质量 对制品生产进行检查与规划。

3、预见原则。

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

5、简化原则：理解组织的结构。

所有其他的原则 也是彼此之间相互影响的。

15.2  概念框架

用 准则、模式、反模式 对各项原则进行补充。

准则用于 判断每个原则的实施效果如何。

模式描述了 常见问题和解决方法。

反模式描述了 在实践中可能遇到的陷阱。描述了不该做的事情，或者用在错误背景下的解决方案。

15.3  形成并统一构想

构想描述了架构的未来，提供了 架构使用的环境和动机。

必须把它所能提供的价值 与客户的约束相对应。

明晰、有约束力、一致、灵活。

15.3.1  形成构想

构想需要维持 一致性与协调性。

一致性 是指 受益人的各种期望之间妥协，以及 需求满足程度。

灵活性 是指 不破坏架构的情况下，完成事先没有预料到的需求的容易程度。

RUP 的 “4+1 架构视图”体现了获得这种一致性的方法，逻辑视图、实现视图、进程视图、部署视图、用例视图，它们根据不同目的表示系统。

架构师可以推荐技术，如何 以及 即使采用这些技术。

架构师更多地意味着 权衡业务、组织运作、使用技术，找出各利益方关注的重点，在一个公共的组织层次上对 信息、决策、资源 进行协调。

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

成功的架构师用明确的客户价值映射规划未来，架构师必须格外关注产品开发人员和最终的客户。

15.3.2  将构想原则付诸实践

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

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

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

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

准则1

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

反模式：风险后置。

用最小的妥协、最大的优化 规划出一个构件以满足所有冲突利益的需要。往往在理论上可行，但实际运行中出现风险。

模式：前后一致。

一个公共的架构 被几个产品共享，已经变得比预期要复杂得多，客户们针对每件产品又提出了以前 没有预计到的 功能特性。

需要评估架构构想的质量和稳定性，只有当两者都正常时，才能采取进一步行动，如果新特性不属于 原来构想的代价范围，就应该放弃。

如果这个特性确实属于一个文档的产品构想，应该在开发组织内 核实这种一致性。

准则2

开发人员 可能会使架构向许多不同的方向发展。一个良好架构应与构想保持一致，同时又能满足用户的需求。

反模式：墙头草。

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

以后发布 会因需要提供向后兼容而变得更为复杂。

方便变更需求 是成功构想的一部分，高级主管要与架构师一起紧密地工作，理解变更的后果并做出正确的权衡。

需要一种固定的机制。

模式：三个臭皮匠。

架构师并非总是架构构想的来源，共同的架构或平台 是产品线战略的关键。

抵制 创建 无所不能的架构 诱惑。

高级经理只提供 构想、目标、原则。

成功的产品线架构必须能为适应市场变化，能适应和采用新技术，能解决在概念阶段还不知道的但变化场景可预见的问题。

准则3

反模式：一叶障目。

开发人员过份专注于 应用，以致不知道其他架构解决同类问题的通用解决方案。

需创造一种分享知识的愿望，如，工程师培训、启用知识管理平台。

模式：轮流工作。

帮教制（Apprenticeship）模式 阶段性地轮流交换构件的所有权 可以解决上面的问题。

组织和鼓励 构件的前任负责人 抽出时间帮助新的负责人，轮转周期应该尽可能地与发布进度保持同步。

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

15.4.1  节奏定义

节奏是 反复出现的、可预测的 工件交换活动。

节奏三个元素：速度、内容、质量。

节奏在团体和组织之间 与内部提供一种协调活动的 稳定力量，帮助移交管理。

节奏很强时，能培养很强的 预见、实施移交、交接 的技能。

15.4.2  将节奏原则付诸实践

以下准则出现时，才说明节奏起了作用。

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

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

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

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

必须在稳定的 间隙上 再评估、同步、调整 他们的架构计划。

反模式：一步成功。

过于专注地向市场推出某项功能特性 而 导致内部节奏遭到破坏。

组织被竞争所蒙蔽，全身心地专注于向市场提供该特性，却削减了质量。

如果在实现关键特性的时候难以保持节奏，说明该特性的风险和复杂度比预计的要大，需要重新规划。

模式：发布委员会。

该模式向经理们介绍了 架构发布的最后阶段 再评估、同步、调整架构 的 方法。

在会议中，要复审产品 功能特性 和 优先级 的变更，从而使 产品文档、市场承诺、公共关系、测试、开发 保持一致。

与会人员应该有 足够的决定权。

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

用户对架构发布的进度和内容缺乏信心是一个警告信号，说明没有设立一个良好的节奏。

反模式：超敏捷。

抄近路以维持稳定的发布节拍，对用户所期望的架构质量和内容进行妥协。

是否已经分配了足够的资源 来执行计划中的步骤，经理们是否创建明确的目标 来保证对节奏的维持都有非常重要的影响。

模式：舍兵保帅。

把不太重要的特性移到后面的发布周期。

准则3：通过节奏协调明确的活动。

软件架构的受益人分布在许多不同的组织中。

反模式：销售未检验的产品。

由于团队不把编译和测试用例的失败当回事，导致积累下来的问题越来越多，无法按时发布。

对定期建立的流程进行修改，防止在修正失败的建立之前开展新的工作。

模式：同步发布。

如果架构中的一些变化需要互补产品做出重大变更，那么应让这些变化出现在最早的发布中。

15.5  预测、验证、调整

为了使对软件产品线的长期投资能产生回报，必须明确架构满足许多应用的需求。

能够预见变化并对变化做出反映，包括那些在设计架构时还没想到的需求。

能够适应新的 技术、标准、市场、竞争对手。

15.5.1  预测、验证、调度 的定义

竞争形式 运行环境 新的组织结构 像银行业这样 合并、接管 司空见惯的领域中，预测不可能总是正确的，所以需要验证。

在架构成型前 要对这些假定进行 检查和确认。

调整要求 具有敏捷性。

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

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

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

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

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

反模式：遗漏细节。

每个人都关注发布的强大新特性，以致忽视了一些用户必不可少的功能。

需要识别关键用户群，和他们一起找出最重要的需求。

模式：示范区。

挑选一个项目初步实现架构。该项目的客户渴望采用新技术，而且也愿意容忍获得该技术时可能存在的不便。

在架构大范围应用之前，缺陷将被发现并解决，修订后兼容问题的约束较小。

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

反模式：品尝未成熟的果实。

被以前的换代或升级害苦了的客户 对关于未成熟技术的承诺极度不信任。

要审慎地选择引入新技术的正确场所，要为最初用户提供额外的支持。

不要假定一个未经验证的架构能够实现所有的承诺，应该分别在 开发人员和产品 用户的特定环境下测试你的解决方案。

模式：架构复审。

对开发中的架构组织执行一次有重点的专家评估，有重大影响的问题和机遇。

在开发周期的关键时刻成立一个架构复审委员会以检查架构。

需求基线初步确定首次复审，有经验的架构师、架构小组成员，客户。

注意让这些复审保持重点。

早起发现缺陷，及时修正，能发现取代新的开发活动的构件，还增强了客户对架构提供已承诺能力的信心。

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

反模式：创造奇迹。

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

1. 找到架构的基础假设并积极努力测试这些假设。

2. 一旦发现错误的估计或假设，必须准备好对此采取行动。

无论何种情况，都应该确保把足够的资源编入预算计划，使得当不可避免的意外发生时，有可分配的进度和人员。

模式：外包。

合适及怎样选择一个已有的第三方构件，或者与提供者合作。

要确定潜在的合作伙伴是否把你需要的构件视为其主营业务的一部分。

他们必须为你做的专门开发越多，信任程度要求越高。类似地，信任度越低，你面临的进度和财政风险就就越高。

15.6  协作：建立合作型组织

每一个对架构关键的团体必须知道如何使用、努力改进架构从而为自己的利益服务。

如何识别对架构成功起关键作用的团体，如何确保这些合作伙伴的支持。

15.6.1  协作定义

协作是指架构受益人保持明确的、合作的角色并将所提供和获得的价值最大化的程度。

合作是指受益人彼此之间存在一些共享的预期，应该明确表示出达到或未达到预期会有哪些奖励和惩罚。

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

正式定义的协作网络与非正式协作网络决定了一个软件架构能否成功。当出现以下几种情况时，说明协作是有效的。

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

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

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

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

挑选一批集中的首要客户，找出保证他们参与需要做些什么，然后交付这些内容，这样做可以增大成功的机会。

反模式：光说不做。

架构师知道了用户的需求 却遗漏了 为了向他们提供有价值的的东西所应该做的事情。

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

模式：了解你的受益人。

利用价值链来识别关键受益人，积极听取他们的一键并获得承诺与支持。

在初步阐明构想之后，确定潜在的合作伙伴以及他们的能力和利益如何与构想保持一致。

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

反模式：不记录讨论结果。

不记录讨论结果说明了当一个架构团队回避采取必要的行动与其最直接的用户达成明确的契约时会发生什么情况。

要确保取得对关键受益人的利益与职责的明确理解，当互动变得消极或者缺乏建设性时，可以求助于这些文件。

模式：互惠互利。

互惠互利要求在合作伙伴之间进行 公平、主动 的价值交换。

应该对正式和非正式的契约复审以保证公平的交换。预算中应该包括代码负责人响应其他团体请求所花的时间。

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

反模式：非正式时间做正式工作。

让工程师利用业余时间修改，架构师就失去了控制其过程和结果的能力，甚至连测试也有可能被删除或完全忽略。

如果这种产品加入到其他团队的工件中，这位工程师在需要完成日常任务同时，还接到大量要求提供支持的请求，导致工程师精疲力竭。

要制订计划奖励工程师花在共享构件上的时间，尽早兑现奖励能减少工作量和大量压力。

把员工用于开发、维护被团体或项目外部所共享的解决方案的时间编入预算，预防工程师在利用非正式时间做正式工作。

模式：杜绝意外。

要尽早提醒用户注意变更，及时协商解决方案。

模式：和HR密切合作。

大部分高级技术岗位要求能迅速获得广泛的潜信息。有着广泛的非正式人际网的工程师比没有这种网络的工程师能获得质量更好的信息。

经理们应该避免破坏非正式人际网。

15.7  简化：澄清与最小化。

确定关键价值是不容易的，尤其是当新客户和新产品的加入使架构偏离原来的方向时，困难会显著增加。

简化软件架构的原则概念上看似简单，而实践中 它要求对价值非常坚定地专注，以及对架构所生存的组织理解和支持。

15.7.1 简化定义

在决定简化架构时，应当留意组织的结构；否则，你会发现你所做的改变只是暂时的。因此在简化架构之前，必须澄清组织和架构。

澄清组织意味着 真实地理解你计划部署架构于其中的组织结构及其影响力（Force）

架构对架构团队和客户都必须是清晰的，简化架构之前，必须准确地知道架构 被期望做什么、如何完成这些任务。

澄清架构就是提供用户所需要的细节。

如果一个组织具备简化、协作、节奏 等技能，长期共享架构就能最小化代码、文档、过程。

不好的组织情况下，共享可能导致架构膨胀。

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

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

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

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

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

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

反模式：简单复制并修改。

不与构件负责人协商变更 就复制并修改架构的部分代码，通常会带来深远的后果。

模式：由慢而快。

开发人员为了跟上进度，拒绝使用架构，解决方法是：放宽进度，加强过程。

指导开发人员逐步采用架构。

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

反模式：缺乏有效抽象。

由于没有被一个共享平台强力支持，每一个分离产品都要求自己的支撑结构。

通过框架团队来建立一个共享平台，防止产品专有特性进入平台。

模式：迁移途径。

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

把架构师拉去参加一个紧急项目以实现一个新特性，而使架构无人照看。

反模式：编码大于架构。

要防止架构师成为实现者，否则问题越来越多。

应该把首席架构师的时间合理分配给实现新特性和调整架构两个renwu

模式：统计构件变更。

通过观察不稳定程度 来挑选需要调整的架构构件的方法。

重组（Refractor）通过长期观测 每个构件或子系统不稳定的程度，那些最不稳定的构件就是重组的候选者。