架构师的职责

Why

• 互联网架构活动的挑战较多，如：
  1. 反射式的研发行为。由于对长远规划思考少等主观因素或者倒排期等客观因素，采取短期的技术方案，不影响当前的业务迭代，但是留下大量技术债。
  2. 大规模活动。后台系统通常采用微服务架构，这种相对独立自主的研发方式对跨团队的协作构成挑战。
  3. 分布式研发中心。对于跨国家、跨地域、跨语言的公司来说，每个研发中心之间相对交流较少，随时间推移，康威定律（系统的结构和产生这些设计的组织的沟通结构是同构的）就开始发挥作用。
  4. 普遍存在认知差异。每个团队，甚至每个研发，平时都在自己的隔离环境下高强度地开发代码，一般没有统一的语言和全局的认知，达成共识困难。即螺丝钉效应。
  5. 活动本身的挑战。高风险、高工作强度和高复杂度的场景。
• 所以需要一个岗位组织架构活动和制定架构方案。

What

1. 建设共识。引导参与者在对架构活动的认知上达成共识。包括对目标的共识、对决策方法的共识，对各自责任边界的共识、对资源分配的共识，以及对交付时间、内容和质量的共识等等。
2. 控制风险。在架构活动的全生命周期持续收集、发现、评估、控制和传递风险，不断提升对风险的理解，逐步完善预案，并在成本可控的情况下选择合理冒险。同时随时跟踪由外部环境和事件引起的风险变化，及时传递重大风险，最终把风险控制在可接受的范围内。
3. 保障交付。架构师需要尽量降低大型架构活动的不确定性和复杂度，最小化架构方案。要做到这点，架构师不仅需要提前行动，关注用户价值；还要不断提纯目标，保障交付的价值；以及，需要反复分解架构计划，持续去除盲区，提升 API 的鲁棒性。最后，以分领域、分阶段、最小化的交付来保障项目完成。
4. 沉淀知识。一方面，需要完整记录架构活动的历史与决策逻辑；另一方面，需要通过文档来驱动理性思维，通过正式文档、Review 流程来提升企业的宏观思考与决策质量。最终，保证这些内容将会形成复盘的主要输入，为企业之后的类似活动积累经验。

How

1. 建设共识。找到架构活动参与方的认知差异点，然后再想办法消除。
   1. 利益不同。scope。
      1. 利益分配保障创新和价值创造可以长期持续。对受到利益损失的个体补偿。
   2. 视角不同。对参与者来说，架构师的架构活动只是他们众多需求中的一个。
      1. 换位思考，充分考虑到局部视角，设计出一个包容的架构规划。
   3. 内在差异。
      1. 职能、工作背景。跟每个参与者都进行一次深度对谈，并针对对方的疑惑做专门的解答。
      2. 语言和文化不同，相对来说比较难解决。先在少数意见领袖中建立共识，让他们去影响和说服其他人。
2. 控制风险。避免风险发生的概率和一旦发生带来的损失都很大。
   1. 逐渐形成量化认知。搭车制，持续预留一定带宽，关注当前已知的最大的几个风险，并对这些风险加深认知，做量化评估和预案。
   2. 可以冒险。如果可以接受损失或者预案成本和损失差别不大，可以忽略风险，以更快的速度迭代业务。
   3. 不能不说。架构师的权责，还没有大到可以代替公司去决定风险政策的地步，所以必须向上及时传递重大风险和冒险行为。
3. 保障交付。
   1. 降低不确定性（问题随时间推移，发生了不连续的、不可预测的变化）。
      1. 目的不确定。赞助方对目标的不确定导致。
      2. 资源不确定。技术资源、运营资源、办公环境等资源有限，只要是有限的资源，最终都会变成稀缺资源。
      3. 商业与技术环境的不确定。在缩短阶段性交付周期的同时，增加技术方案的抽象性，即分阶段上线并支持调整具体的实现方案。
      4. 用户需求的不确定。需求与期望不一致或者随时间发生变化，通过线上用户行为和调研之间的差异性分析，决定是否需要调整。
   2. 复杂度控制（问题或者解决方案，很难用几个简单的维度去描述）。
      1. 从问题域层面分解架构规划和交付方案。研发团队通常是按照问题域拆解，可以最大限度的利用已有机制。
      2. 增加架构设计方案本身的结构性。不同领域、不同模块的设计是同构的，即除了业务逻辑不同，使用的技术框架、研发流程等是相同的。
      3. 按照多种方式分割交付模块。分期交付，比如按部门、领域、架构分层。
   3. 最小化架构方案。大多数架构活动会以失败告终，最小且必要原则，是提升交付成功率的最重要的方法。
4. 沉淀知识。
   1. 被动行为。收集、整理和编写文档。
   2. 主动行为。通过文档来驱动架构活动参与者的思想实验，通过理论推演来提升思考质量，降低今后类似活动的成本。

架构活动生命周期

• 从架构活动生命周期，明确架构师的职责。
• 分为7个节点。

环境搭建

• What：架构师为架构活动所搭建的虚拟的工作环境，包括：
  • 决策环境：在多个参与方 / 团队无法达成一致或者产生冲突时，通过投票、把冲突向上升级、决策者拍板等方式，确保参与者能解决冲突，迅速拿到大家遵守的决策。
  • 激励环境：能对参与者产生驱动力的激励，一般是额外的物质和精神上的奖励。
  • 资源环境：企业中留给架构活动所支配的资源非常有限，这是架构活动的主要约束条件。比如技术资源、运营资源、办公环境等。
  • 团队构成：参与架构活动的成员和团队大致构成。我们需要通过这个条件来确定架构活动的可行性。
  • 工作空间：指物理上的工作空间。比如让所有参与者在同一个办公区内，或者建立一个虚拟的线上社区，促进参与者之间形成深度交流，减少误解，以便及时解决问题或冲突。
• Why：减少外部环境对架构活动的影响。
• How：
  1. 决策环境：依靠机制，而不是靠单个人的判断来找到正确决策。
     • 高效的必要条件是决策的正确性。
     • 样例：亚马逊客服部门的信条机制，人性本善、选择信任、不对抗。
  2. 激励、资源、团队、工作空间：游说这些稀缺资源的管理者，取得架构活动的最小必须资源。
     • 清晰描述架构活动要创造的价值，通过分析投入产出比，来解释为什么这些有限资源的一部分，应该投入到你组织的架构活动中去。

目标确认

• What：保障目标的正确性、合理性、可达性，符合SMART原则。
  • 正确性（决策者角度）：符合企业当下阶段的目标，比如在电商的不同阶段，追求GMV、订单数、DAU、利润中的一个。
  • 合理性（执行者角度）：既具备足够的挑战性，但是又不会引起大面积的动作变形。包括具体的目标值、交付时间和质量期望。
  • 可达性（赞助者角度）：某个风险发生的时候，这个目标实现的成本可能会增加，但是最终仍然会实现。
  • SMART原则：具体（Specific）、可度量（Measurable）、可达（Achievable）、相关（Relevant）、有时效的（Time-bound）。比如：三个月内，把 90% 的商家发布商品的时间，从平均每件 30 分钟降低到平均每件 1 分钟以内。
• How：
  1. 靠多个职能之间反复讨论和反复演算，获得符合SMART原则的目标。
  2. 如果不能做到1，说服相关方放弃该目标，重新树立正确、合理、可达的目标。

可行性探索

• Why：让决策者和赞助者对架构目标是否可达，形成一个相对清晰的认知。
• How
  1. 重大风险发掘。通过自己判断和专家沟通，短时高效地从多个视角挖掘会大幅降低预期价值的风险，每个视角最好不超过3个。
     1. 项目交付视角。在有限的人力和时间限制下，评估质量底线、团队协同、处理问题的buffer。
     2. 商业价值视角。是否存在会大幅影响最终产出的商业价值的因素，比如互联网的恶性竞争导致的红海。
     3. 人性视角。符合关键研发人员和用户的利益。
     4. 资源视角。架构环境中提及的最小必要资源是否可以就位。
     5. 其他视角。比如监管、法律、隐私等。
  2. 风险预估。对重大风险做思想实验，确认存在预案，并且体验大致可以接受。对预案的量化指标可以包括：总时间成本、总人力成本、总资金成本、商业价值损失、用户体验损失。
  3. 风险沟通。和执行者、赞助者同步风险，协商解决方案。
  4. 风险决策。站在决策者的角度给出全局有利的决策建议，要敢于冒险并理智冒险。
  5. 完成探索。整理决策者的建议，并整理成架构文档。

架构规划

统一语义

• What：多方有各自的语境，在各自表达，没有办法理解对方真实意图时，需要统一语义，确保整个架构规划在一个逻辑完备且语义一致的环境中进行。
• Why：语境差异的来源包括员工的文化、职级、团队分工等。
• How：消除语义分歧的做法有
  1. 发现语境。语境之间有一定的连续性。
  2. 定义概念。一旦发现了一个新的语境中，存在词语表达相同但语义不同的概念，需要准确描述这些概念了，更要准确描述概念背后的场景。比如：
     1. 生产商的语境。生产商是产品的生产者，提供产品的权威描述和售后保障等。他们一般不会与平台直接发生关系。当然，也有一种特殊的生产商叫做品牌商，他们会验证商品的真假，或者对商品的分销价格和领域等进行限制，因此会与平台发生关系。不过在我们这个语境中并不涉及品牌商。
     2. 实物商品的商家。产品被商家以不同方式获取后，这个实物的产品就到了商家的仓库中，也就是未来要发送给客户的货品。那么商家将会控制这个货品的物权，甚至会在原有产品中增加额外保障，比如 7 天免运费退款、1 年换新等，作为商家提供的商品的一部分。可以说，商家和平台发生关系，就是通过提供对自己货品的商品描述。
     3. 实物电商平台。平台在获取不同商家的商品描述后，会整合成一个平台的权威商品描述，也就是刚才提到的商品（Item），并把商品提供给平台用户。订单则是用户和商家形成的一笔交易。用户虽然把钱交给了平台，但物权还是在商家手里。用户确认收货之后，钱再由平台打给商家。需要注意的是，钱始终不属于平台，只是这个过程中的一个担保者。
     4. 平台用户。用户在平台上可以购买实物商品，也可以购买数字商品。对于他们而言，花钱就是买一个消费的东西（Consumable Item），能享受就行了。
     5. 发行商。拿电影来举例，发行商在某个国家或者地区内对这个电影有发行权。他们会为该地生产一个标准的数字产品(Digital Product)，也就是翻译好、剪辑好，并且按地区植入相关内容的数字电影。除此之外，发行商也会和一个数字电商平台达成售卖协议，然后由这个数字电商平台向用户售卖数字商品（Digital Item）。
     6. 数字电商平台。平台跟多个发行商都存在商务关系。发行商提供一个数字产品的版权，由数字电商平台负责售卖。数字平台不是在售卖一个电影，而是这部电影在某个地区内不可以转交的、在限定时长内的、仅仅用于个人观看的版权，比如《沙丘》这部电影
  3. 语义建模。合并不同语境，分离各个语境共性和差异，最好能用图描述语义的关系。如实物商品和数字商品。
     
     
  4. 反馈修正。
  5. 公布、维护和使用统一的语境。不断使用并打磨。

需求确认

• What：在统一语境赋能下，将需求无损的分解给执行者。
• How：

  1. 确认准备。

     1. 从产品角度梳理需求：客户（赞助者，业务部门），用户（使用者，包括供应商等），核心场景（客户和用户的核心诉求，诉求会在哪些场景体现）
     2. 从执行者角度梳理执行域：执行团队（为哪些用户服务，可以创造什么价值），执行域划分（需要特别尬尊户重叠部分和没有覆盖的部分），其他承接放（除了执行团队外，应该、愿意、有能力承接的团队）
     3. 确认取舍规则。需求优先级的决策信条，哪些是必保需求，

  2. 问题域划分。如绿色代表商品域，古铜色代表实物商家域，蓝色代表发行商域，紫色代表货品和履约域，黑色的部分代表数字商品域。
     

  3. 目标到需求的映射。

     1. 评估需求，最小必要的需求和无关紧要的需求。指标包括：必要性（价值、确实的影响），正确性（和赞助者的预期是否一个数量级），合理性（在交付时间的约束下，交付时间和质量是否合理，会不会导致设计的完全变形），可达性（是否有足够的资源处理风险），需求的承接方（有哪些，他们是否应该、愿意、能够承接，是否有研发带宽）
     2. 必要时可以联合执行域的负责人砍掉不必要的需求。

  4. 需求到问题域的映射（粗粒度）。

  5. 问题域到执行域的映射。逐个确认某个需求的承接方是否有执行瓶颈，如果有是什么。可能的冲突和应对如下：

     1. 有限资源的争夺。如果没办法缩减交付项，就必须在这个时间和赞助方、决策方、参与方讲明白。要么调整质量预期，要么调整上线时间。
     2. 生存空间的争夺。务必请决策者迅速裁决，因为这是没办法调和的冲突。
     3. 个人与团队之间的矛盾。随着项目压力的增加，矛盾必然会放大。需要请决策者进行处理或者提前指定一位裁决人出问题时拍板。
     4. 组织和决策结构的问题。可以通过搭建架构环境、设立决策信条等方法予以解决。
        

  6. 发现冲突。优先级的冲突（多个业务共享研发资源），定位的冲突（如营销和合规团队），团队和个人的冲突（赛马），边界冲突（垂直执行域的重叠如交易、支付，水平执行域的重叠如低代码导致的后端做前端工作），问题域到执行域的映射关系的冲突（非一对一导致的混乱和抢地盘），生存空间的冲突（主要是在大厂），决策权的冲突（架构师的决策权被某个领域抢走，如支付一类强势的共享技术域）。

任务边界划分

• Why：
  1. 需求确认中的划分是基于现有执行域的，导致架构设计会受到执行团队组织结构的约束。
  2. 依然会在架构活动中碰到执行域划分没有执行团队，或者有多个执行团队的情况。
  3. 执行域是非常粗粒度的任务划分，但部分有边界冲突的跨领域任务，需要在更细粒度的任务层面上做执行边界的划分。
• How。
  • 依据的信条有：
    1. 任务边界可以打破现有的执行边界。任务边界是暂时的，不一定需要完全遵守问题域执行域的映射，要从用户角度出发，交给能完成任务的团队。
    2. 任务边界划分有确定的决策优先级。如果划分有多种方案，以最小化整体成本为第一优先级，但是不能牺牲项目目标的完成度。
    3. 最小化架构目标之外的抽象。做阶段性的重构，在业务模式已经稳定且有明确浪费的情况下，对重点领域做针对性的重构。而不是在业务模式还没有稳定下来之前做架构抽象，因为抽象会提高系统复杂读，自动削弱系统迭代效率和稳定性。
    4. 任务边界划分时要最大化隔离。把两个实体的相关的任务分开来，确保独立封装和实现，业务稳定之后可以考虑抽象，否则对于大泥球式的应用只有重构了。
    5. 任务边界划分要面向未来最优。如打通团队边界，未来创建一个效率更优的组织架构。
  • 具体的做法：
    1. 任务梳理和粒度控制。依据信条，从技术视角理解用例对架构的影响：如期望复用某个功能，任务更倾向于分配给当前实现该功能的团队；如风控和业务需求对开发能力模型要求不同，需要分成两个任务，未来产生领域分支和技术专业性。
    2. 边界划分和任务分配。对成功概率最低的强依赖，做任务分配的调整，降低风险。
    3. 锁定项目必保需求的交付资源。强调收益，即画大饼。

确认规划完整性

• How。定稿架构文档，做到有人有图有承诺。文档包括：
  1. 用例文档。顶层用例不超过10个。
  2. 必保任务和交付节奏。
  3. 领域模型。让最终的执行者来确认领域模型。
  4. 各个子域技术方案。API 设计、消息和数据流等。
  5. 确认强依赖任务的交付节奏。

项目启动

• Why：详细的技术方案评审暴露了一些问题，比如
  1. 两个子域之间结论互相冲突。需要重新审视下之前的整体规划和风险梳理的正确性。
  2. 子域技术方案作出某些取舍，偏离了架构目标，可能是为了保障交付时间而并没有保障商业价值。
  3. 子域的技术文档缺失，后者仍然有大量待解决的问题点。
• How：
  1. 解除重大风险。同可行性探索，最后决定是否需要放弃。
  2. 建设风险预警和冲突解决机制。
     1. 建设一个畅通的沟通渠道，来确保重大问题能被决策者注意到，比如日报、日会等将风险逐层上报。
     2. 多方出现争议并且无法化解时，需要升级决策，各方执行。

阶段性价值交付

• Why：
  1. 项目经理通常会选择分时段、团队交付，降低项目风险，但是往往会忽略每个阶段的用户价值。
  2. 架构师更加清楚架构目标和规划细节，可以分割最小价值单元，更早的从最小价值单元的回报推导出整个项目的价值。

最小价值单元（MVPU）的定义：
1. 独立性：从用户视角看，这个单元可以被单独识别。
2. 结论的完整性：从商业价值的角度看，我们从这个单元得出的结论是完整的。
3. 可度量性：这个单元为目标用户创造的价值可以被数字化、被度量。

• How：
  1. MVPU 拆分。可从多个角度拆分。商业价值（GMV、总订单数、总成交客户数、首次下单客户数等），用户价值（新买家数、买家满意度等），技术价值（每秒峰值订单数等）
  2. 交付路径设计。在不破坏整体架构的基础上，尽早交付MVPU，包括：
     1. 梳理强依赖关系。对于最终不指向项目目标的节点，可以砍掉或者作为低优任务
        
     2. 控制联调的成本和节奏。通常两周到一个月，太短打乱开放节奏，太长积攒风险。
     3. 把握速度和结构性之间的平衡。可以在不影响整体架构的情况下快速交付MVPU，看清商业价值，之后再开始做稳定的整体设计。
  3. 交付跟踪与路径调整。主要关注MVPU交付之后未达到预期的原因，及时调整决策。
     1. 用户没有意愿，商业模式不成立等，需要大范围调整产品方案和目标。
     2. 技术实现漏洞，合作方问题等，越早发现可以越早处理。

复盘

• What：通过还原并深度思考架构活动的完整历程，来寻找可以提升未来架构活动成功概率的过程。
  • 对象包括成功案例和失败案例
  • 视角包括：对他人的视角（谁导致我的失败），自己的视角（我有什么地方可以改进）
  • 误区：止于问责（找到并惩罚责任人），止于意识提升（忽略系统、机制、文化的提升），止于错误补救（仅仅挽回损失）
• How：
  1. 回顾架构活动。以时间顺序多角度回顾当时的决策环节和最终决策，比如架构师、产品、研发角度等。
  2. 过程控制和整体规划。对复盘的内容引导：
     1. 视角：公司而不是个人视角，个人可以做什么而不是他人可以做什么的视角，彼时彼岸视角，找机会而不是问责视角，抓大机会放小确幸的视角。
     2. 思考维度：
        1. 整体流程：从目标设定到架构环境搭建，再到最终的交付，有什么可以改进或提升的地方？
        2. 决策质量：公司在大型决策中的质量怎么样？如何进一步提升决策质量？
        3. 架构规划：我们到底有没有真正意义上的架构规划？这个架构规划有无重大缺陷？取舍是否正确？架构规划对实施起到指导作用了吗？
        4. 执行和实施：实施过程是否忠于最初的目标？最终是否能交付预期的价值？
        5. 质量控制：核心模块的最终质量是否达到了预期？
        6. 组织维度：团队是否胜任？组织是否给力？协同是否高效？
        7. 文化维度：公司文化对架构活动的成功有帮助吗？还是阻碍了架构活动过程中的探索和求真？
  3. 梳理机会点。可以通过多轮思考，找到错失的最大机会点，而不用浪费太多时间在跟进措施上。思考的角度：
     1. 在某个维度或者某个组合维度上，我们错失的最大机会点是什么？
     2. 为什么这是个错失的机会点，而不是一个无法掌控的风险因素呢？未来碰到这样的机会点，我们可以把握住吗
     3. 这个错失的机会点有多大？可以从商业价值或者用户价值上来度量吗？
  4. 挖掘根因。针对最重要的三个机会点，彻底挖掘造成这个损失的根因，可以用 Five Whys 发文，追究到底，并发掘分支。
  5. 寻找新的模式与机制。比如如果发现问题是单点导致，未来设计规范里需要对单点加固；如果是强依赖导致，未来方案需要思考对强依赖的降级措施。
  6. 产出跟进项。各个团队都可以有跟进项，但是建议公司改变的不要超过3条，因为公司模式的改变需要一定的连续性，而且单个案例的复盘有一定局限。

经历过的典型案例

• 某O2O业务和中台支付团队强耦合。
  • 现象：中台的支付团队要求o2o业务使用另一个业务的4层订单模型，从而和支付模型一一对应。这样，提单页、下单、支付、履约、结算整条交易都需要考虑当前需求对订单模型的修改是否影响到中台支付团队，如果影响到需要给中台提需求适配业务。如果中台团队模型无法扩展，或者排期赶不上，需要前台业务适配中台模型。
  • 原因：支付团队不光对接外部支付渠道，提供统一的支付能力，还在支付能力之上抽了一层业务层，分别对接各个上层业务，对各个业务单读建模，美其名曰深入合作。如果不去和业务团队强绑定，支付团队的生存空间会极大被压缩。
  • 理论上的解决方案：这种属于生存空间的争夺，无法调和，两边leader理论上应该站出来battle一个低耦合的解决方案，如果不能达成一致上升直到CTO层次。
  • 事实情况：业务团队leader经常拥抱变化，更关注短期收益，比如双月需求定容率，双月故障率等。强耦合会导致的迭代速率降低并不关注，认为这些可以靠加班解决。

参考

• 郭东白的架构课