为解决方案蓝图审查做准备
通常情况下，解决方案蓝图审查大约需要持续两到八个小时。 时间可能会因可供审查的详细信息的程度和总体解决方案的广度而异。 解决方案架构师将与实现团队领导层合作，根据要审查的解决方案的具体信息来计划研讨会。
在开展解决方案蓝图审查研讨会之前，研讨会参与者应确保其尽可能熟悉研讨会的结构以及将涵盖的主题类型和先决条件。 解决方案架构师将在研讨会之前提供一个包含主题和先决条件的议程。
注意
本质上，解决方案蓝图审查是一场讨论；它不是一份可以在脱机模式下填写和审查的调查问卷。 虽然提前定义和提供了先决条件，但不可能全面囊括对话可能引向的方向。
解决方案架构师将通过预先审查现有项目提前为研讨会做好准备。 有用的项目内容包括：
- 流程目录 - 实现范围内的流程、子流程和用户案例的列表或层次结构。
- 流程流图 - 可将上下文添加到流程目录并描述业务运营的图。 在解决方案蓝图审查阶段，高度概括的端到端流程最有帮助。
- 应用程序图 – 显示构成解决方案的各种组件的模块图。 这些图表还可以提供与功能如何映射到应用程序组件或应用程序组件如何相互连接相关的上下文。
- 差距要求 – 已知不受标准系统支持的功能区域。
- 数据流图 – 在包含多个 Dynamics 365 应用、旧版或外部服务及组件的解决方案中，能够识别数据的来源及其在解决方案中移动和使用的方式将很有帮助。
- 数据迁移策略 – 显示要迁移的实体、实体的来源、容量、时间和迁移方法的文档或登记薄。 在解决方案蓝图阶段，关键要确保您具有范围（表和源）。
- 接口登记簿 – 具有非功能要求和设计模式的接口列表，其中记录实现这些接口的范围和方法。
- 分析数据聚合设计 – 将迁移以用于聚合分析的数据源的图表或登记簿。
- 环境策略 – 用于概述将要设置的环境类型、如何及何时使用这些环境以及代码和配置将如何在其中流动的模块或流程图。
- 系统使用情况配置文件 – 按工作负载类型显示的运营流程计划和高峰交易记录量。
- 法人结构 – 显示将在解决方案中建模的法人及其相互关系的图表或登记簿。
- 部署位置 – 显示将要在其中部署解决方案的物理位置以及语言和本地化要求的图表或登记簿。
- 项目章程 – 提供项目背景、目标、预计关键结果、利益干系人、预算、时间线和里程碑的文档。
- 项目计划/安排 – 描述总体计划、关键项目阶段依赖性及其相关活动的文档或甘特图。
- 职责分配矩阵 – 列有任务及项目角色与这些任务的关系的表。 这些关系通常通过 RACI 分类（负责、批准、咨询、通知）分配
- 测试计划/策略 – 描述在整个实现过程中将要执行的测试类型以及如何定义、实现和衡量测试的文档。
本列表没有详尽列出项目可交付内容，但它是解决方案蓝图审查的良好起点。 每个可交付内容的格式、构成和名称可能因不同的项目而异。 格式不是最重要的组件；团队中可用和同意的信息至关重要。
当您在项目早期进行解决方案蓝图审查时，其中有许多文档未完全成形，在大多数情况下，这是可以接受的。 更重要的是，已确定范围，并且已制定概念计划以确定解决方案将如何支持该范围。 如果计划未成功，则应在协助实现的咨询合作伙伴提供的工作说明书中一定程度地说明这些项目。 如果已确定范围和概念解决方案方法，则在解决方案蓝图审查中可以重点关注概念方法，在后续深入研讨会中可重点关注新出现的详细信息。
如果您的项目使用不同的方式管理或跟踪项目信息（以前列出的信息除外），这是可接受的。 通常，如果这些信息已经准备好提供给项目成员，则格式不重要。 如果前面列出的信息未记录在您的项目中，或者它以不易访问的方式进行记录，您应该优先获取生成的相关项目。
我们建议您使用图表和视觉对象表示形式在实现中尽可能提供高级别摘要。 这些图示、图表和图形提供了团队之间以及与高管就计划和设计进行沟通的便捷方式。
注意
解决方案蓝图审查不是对详细要求或设计文档进行详尽审查。 实现团队将使用较低级别的详细信息来得出和呈现总体体系结构。 如果实现团队显示关键问题，架构师将调查潜在的问题所在。 解决方案架构师将建议开展深入研讨会，以调查需要额外评估的方面。