Day29-10｜8.3.1 阶段1——演示（Presentation）：让评估团队建立共同架构认知

一、教材定位

ATAM 是一种以质量属性和架构权衡为核心的架构评估方法。它通常通过若干阶段组织利益相关者、架构团队和评估团队，从业务驱动因素出发，理解架构方案，生成和排序质量属性场景，分析敏感点与权衡点，最后形成风险和建议。阶段1“演示”是整个评估的起点，目标不是立即评价架构好坏，而是让所有参与者对系统、业务、架构范围和评估目标建立共同认知。

二、为什么首先要进行演示

架构评估参与者来自不同背景，对系统的理解通常不一致。业务人员习惯使用业务语言，开发人员关注模块和接口，运维人员关注节点和故障，安全人员关注信任边界，管理者关心成本和交付。如果没有统一演示，后续的风险讨论可能建立在不同假设上：有人认为系统是单体，有人认为系统已经服务化；有人认为数据最终一致可以接受，有人认为交易必须强一致。

演示阶段通过结构化说明回答几个基础问题：系统解决什么业务问题，谁使用它，架构边界在哪里，主要组件如何协作，关键数据如何流动，部署在哪里，最重要的质量目标是什么，本次评估希望解决哪些疑问。

三、阶段1的主要参与者

演示人不一定是唯一的架构师。复杂系统可以由业务负责人、领域架构师、基础设施架构师和安全架构师分别介绍相关部分，但必须由主持人控制术语、时间和范围，避免演示变成无序的产品宣讲。

四、演示的内容结构

1. 业务背景和系统目标

首先说明系统为什么建设、服务哪些用户、解决什么业务问题、成功标准是什么。业务背景要突出业务驱动因素，例如交易规模增长、监管要求、服务连续性、产品快速上线或遗留系统替换。不能直接从技术框架和部署图开始，否则参与者无法判断技术选择是否服务于业务目标。

2. 评估目标和范围

说明本次评估关注哪些系统和质量属性，不关注哪些内容，以及需要形成什么结果。例如本次评估关注峰值性能、跨地域可用性和数据安全，范围包括订单、库存、支付和部署平台，不包含外围报表系统的内部实现。明确范围能够防止会议被无关细节占用。

3. 架构上下文

介绍系统与外部用户、组织、设备、第三方平台和遗留系统的关系。上下文图应标出外部交互、信任边界、数据输入输出和主要责任边界。外部依赖是架构风险的重要来源，演示阶段应说明接口协议、可用性承诺、延迟、限流和故障处理方式。

4. 架构视图

根据评估目标选择合适的视图，而不是把所有图表一次性展示。逻辑视图说明主要子系统和职责；开发视图说明模块和依赖；过程视图说明并发、通信、事务和消息；部署视图说明节点、网络、存储和冗余；数据视图说明数据所有权、一致性和生命周期。

5. 关键架构决策

重点说明影响质量属性的决策，例如采用同步还是异步，集中式还是分布式，单体还是服务化，共享数据库还是自治数据，单地域还是多地域，强一致还是最终一致。每个决策都应说明背景、候选方案、选择理由、后果和待验证假设。

五、演示中的质量属性表达

演示不能只说“系统高性能、高可用、安全可靠”，应给出质量属性场景或至少给出目标方向。比如峰值期间每秒5000个查询请求，核心接口95%响应时间不超过300毫秒；单个应用节点故障时服务自动切换，恢复时间不超过5分钟；敏感字段只能由授权角色访问，所有访问进入审计。

质量目标的表达可以分为业务优先级、约束、期望和待验证假设。演示阶段不一定已经拥有全部精确指标，但必须标出哪些指标已确认，哪些仍需业务和运维团队确认，哪些需要通过原型和测试验证。

六、演示与架构假设

架构假设是评估中非常重要的内容。常见假设包括外部接口能提供足够吞吐，数据库复制延迟可接受，网络分区不会长期持续，团队具备某项技术能力，某个供应商会持续支持版本。假设如果没有验证，可能成为架构风险。

演示人应主动说明假设，而不是隐藏不确定性。对于关键假设，应列出验证方式和责任人。例如通过接口压测验证外部支付平台容量，通过网络模拟验证跨地域复制延迟，通过演练验证数据库切换，通过原型验证团队能否完成构件替换。

七、如何控制演示深度

演示过浅，评估团队无法理解架构；演示过深，会议会陷入代码和配置细节，失去架构评估重点。控制深度的原则是：只讲与业务目标、质量属性和架构决策相关的内容；对于需要进一步验证的细节，记录为问题或后续活动。

可以采用“概览—关键路径—重点决策—风险提示”的结构。先用概览建立全局，再选一到两个关键业务场景演示请求、数据和故障流转，随后解释关键决策，最后主动指出已知限制和待验证项。

八、阶段1的典型产物

演示阶段通常形成业务背景说明、评估目标与范围、架构上下文图、主要架构视图、关键质量属性清单、架构决策摘要、假设与限制清单、资料缺口和后续问题列表。这些内容成为后续场景生成、排序和分析的基础。

产物不一定都是正式长文档，但必须可追踪。后续评估中，如果有人提出“为什么采用异步”“为什么数据库可以分区”，主持人应能追溯到演示资料和架构决策记录。

九、案例分析：企业统一身份平台 ATAM 演示

某企业建设统一身份平台，为人力、财务、供应链和移动办公系统提供认证和授权。ATAM 评估开始时，架构团队先介绍业务背景：多个系统账号不一致、权限回收不及时、外部合作伙伴接入困难。评估范围包括认证中心、目录服务、权限服务、审计平台和接入网关，不包括各业务系统内部的页面实现。

随后介绍上下文和关键路径：用户通过网关发起认证，认证中心访问目录和多因素服务，成功后签发令牌，业务系统根据令牌和权限策略决定访问。关键决策包括采用标准协议、令牌短时有效、权限集中管理、审计异步写入以及多节点部署。架构团队主动说明假设：各业务系统能够完成协议改造，目录服务支持高峰查询，多因素服务在外部网络不可用时有备用策略。

演示后，评估团队提出后续场景：高峰登录、目录节点故障、权限撤销的生效时间、合作伙伴身份隔离、审计不可篡改和外部多因素服务不可用。这样，阶段1没有直接给出“架构通过”的结论，却为后续质量属性分析建立了共同基础。

十、常见错误

第一，把演示当成产品发布会，只讲功能，不讲架构驱动因素和质量目标。第二，展示过多技术细节，却没有说明这些技术如何支持业务和质量属性。第三，隐藏架构假设和已知限制，导致评估团队无法正确判断风险。第四，所有视图同时展示，造成信息过载。第五，演示结束没有记录问题、资料缺口和后续验证任务。

十一、练习题

题1

ATAM 阶段1“演示”的主要目标是什么？

参考答案

主要目标是让评估团队和利益相关者对业务背景、评估范围、系统上下文、架构视图、关键决策、质量目标和假设建立共同认知，为后续质量属性场景生成、排序和架构权衡分析提供基础。阶段1不是直接给出最终评估结论。

题2

为什么演示阶段必须说明架构假设？

参考答案

架构结论通常依赖一些尚未完全验证的条件。若假设不成立，架构可能无法满足质量目标。主动列出假设可以安排原型、压测和演练，避免把不确定性隐藏成风险。

题3

演示架构视图时应遵循什么原则？

参考答案

根据评估目标选择视图，优先展示与关键质量属性和架构决策相关的内容，遵循概览、关键路径、重点决策和风险提示的顺序，避免无关细节和信息过载。

十二、论文写作素材

论文中可以写“在架构评估启动阶段，我组织业务、开发、测试、运维和安全人员进行架构演示。先说明业务驱动因素、评估目标和系统范围，再通过上下文、逻辑、过程、部署和数据视图介绍架构，重点解释影响性能、可用性、安全和可修改性的决策，同时主动披露外部依赖、设计假设和已知限制。演示后将参与者提出的问题整理为质量属性场景、风险和验证任务，为后续评估提供共同基础。”

十三、今日复盘

阶段1的关键词是“建立共同认知”。记住演示顺序：业务背景、评估范围、系统上下文、架构视图、质量目标、关键决策、假设限制、问题记录。演示不是宣传，也不是最终评判，而是后续架构评估的共同起点。