1. 架构设计会议
1.1. 架构设计会议是由技术专家主导，业务和技术利益相关者共同参与的结构化讨论
- 1.1.1. 其核心目的在于为特定的商业机会定义并规划收集数据解决方案的高层设计
1.2. 第一次架构设计会议是架构过程的开始，并将引发更多的讨论（很可能包括其他ADS），以支持数据解决方案项目
1.3. 可交付成果
1.3.1. 可作为数据解决方案起点的架构（或“蓝图”）
1.3.2. 高级行动计划，可能包括后续演示、概念验证和产品讨论
1.4. 架构设计会议不是技术研讨会、技术培训、技术演示，也不是低层次的需求会议
1.5. “大处着眼，小处着手”的结构化框架
1.6. ADS是构建数据架构的重要组成部分
- 1.6.1. 有助于使设计决策与业务目标保持一致，解决潜在的风险和挑战，优化成本和资源，并促进利益相关者之间的协作
1.7. ADS的最终目标是构建一个优秀的数据架构，甚至是一个卓越的数据架构
1.7.1. 一个优秀的数据架构应该具有稳健性和可扩展性，能够有效地支持数据驱动的举措
1.7.2. 将数据架构从优秀提升至卓越，意味着要满足所有通过数据价值链中获取的用户反馈信息，从而使整体数据战略能够实现组织的目标
1.7.3. 构建数据解决方案是一个以用户为中心的设计与反馈之旅，它需要一种只有ADS才能提供的策略和规划
2. 准备工作
2.1. 准备
2.1.1. 至少留出一天时间准备ADS研讨会
2.1.2. 对于远程ADS，*两个四小时的课程通常比一整天的课程要好
2.1.3. 作者尽量把两个四小时的会议安排在连续的几天，或者至少在一周内举行
2.1.4. 确保了解项目预算和时间表，并确定决策者
2.1.5. 成果
2.1.5.1. 向客户团队发送一封电子邮件，概述电话会议内容
2.1.5.2. 客户团队发送一份议程草案
2.1.5.3. 座位表（如果ADS将实体举行）
2.1.5.4. 提醒客户团队与客户进行电话会议前的沟通
2.1.6. 事先预留一些时间，了解白板工具的使用方法，这样就不会在ADS中使用时摸不着头脑了
2.2. 邀请与会者
2.2.1. 参与ADS的人员会因客户是内部（公司内部团体）还是外部（有业务往来的外部公司）而略有不同
2.2.2. 从客户方面（或如果是内部ADS，则从要为其进行ADS的小组）来看
2.2.2.1. 发起人（至少一名来自业务部门，一名来自IT部门）
2.2.2.2. 技术代表
2.2.2.3. 项目经理
2.2.2.4. 企业代表
2.2.2.5. 必要时，顾问、架构师、开发人员以及基础设施或运营人员
2.2.2.6. 团队成员
2.2.2.6.1. 一位架构师，负责为会议提供便利，确保ADS达到目标
2.2.2.6.2. 来自客户团队的客户经理、客户专家、云解决方案架构师
2.2.2.6.3. 主题专家(SME)就特定主题提供深入的知识
2.2.2.6.3.1. 在大多数情况下，最好找一个行业专家，而不是自己学习这个主题，尤其在你的时间有限的情况下
2.2.2.6.4. 至少有一人做记录（可以是客户团队的成员）
- 2.2.3. 如果主持人是一位新手，可能还需要请一位导师参与，在ADS期间提供支持（回答主持人无法回答的问题），并在会后就做得好的地方和可以做得更好的地方给予反馈
3. 进行架构设计会议
3.1. 记住会议负责人的责任是确定基调，让会议按部就班地进行
3.2. 如果有人提出了一个偏离主题的问题，可以让他们线下讨论，然后把问题写在白板上，以便跟进
3.3. 介绍
3.3.1. 在ADS开始时，让每个人进行自我介绍，说明自己的姓名、角色以及对将要讨论的技术的了解
3.3.2. 可以告诉他们会把白板的最终副本发给他们，这样他们就不需要拍照了
3.4. 探索
3.4.1. 探索是指在ADS开始时，用一两个小时的时间询问一些问题
3.4.1.1. 客户当前的痛点
3.4.1.2. 他们当前使用的技术和架构
3.4.1.3. 他们未来的架构
3.4.1.4. 他们已经就使用或计划使用的技术、产品或工具做出的任何决定
3.4.1.5. 当前和未来的使用案例
3.4.1.6. 业务详情
3.4.2. 应该让客户说得最多，尤其是在ADS的初期
3.4.3. 好的架构师会问很多问题
- 3.4.3.1. 经验丰富的架构师了解所有可用的架构、技术和工具，并紧跟不断变化的技术和产品
3.4.4. 探索是将产品选择范围缩小到可以考虑的可行数量的最佳方法
3.4.5. 架构师也是这样做的，ADS的探索阶段是一个很好的机会，可以在客户面前提出问题
3.5. ADS问卷
3.5.1. 问题清单
- 3.5.1.1. 客户企业正在使用云计算吗？
3.5.1.2. 企业正在考虑的数据架构是新的解决方案还是迁移？
3.5.1.3. 工程师有什么技能？
3.5.1.4. 会使用非关系数据吗？
3.5.1.5. 需要存储多少数据？
3.5.1.6. 有流媒体数据吗？
3.5.1.7. 是否会使用数据看板和/或临时查询？
3.5.1.7.1. 了解数据的使用方式不仅会影响推荐的产品类型，还会影响系统的性能需求
3.5.1.8. 是否要使用批处理或交互式查询？
3.5.1.9. 报告的运行速度需要多快？
3.5.1.9.1. 报告需要在毫秒级还是分钟级运行？
3.5.1.10. 是否有包含具体要求的服务水平协议(SLA)？
3.5.1.11. 在预测分析或机器学习中会使用这些数据吗？
3.5.1.12. 有哪些高可用性或灾难恢复要求（如恢复时间目标和恢复点目标）？
3.5.1.12.1. 大多数云提供商都内置了普通客户所需的所有高可用性，但要支持任何特定的高级要求，都可能需要更改架构
- 3.5.1.13. 需要掌握数据吗？
3.5.1.13.1. 主数据管理(MDM)涉及为企业中的每个人、地点或事物创建单一的主记录，这些记录是从内部和外部数据源及应用程序中收集的
3.5.1.14. 在云中存储数据是否有任何安全限制（例如客户合同中的规定）？
3.5.1.15. 该解决方案是否需要全天候的客户访问？
3.5.1.16. 高峰时段，将有多少并发用户访问该解决方案？
3.5.1.16.1. 平均有多少？
3.5.1.17. 终端用户的技能水平如何？
3.5.1.18. 预算是多少？
3.5.1.19. 计划的时间表是什么？
3.5.1.20. 源数据是在云端还是本地？
3.5.1.21. 每天需要向解决方案导入多少数据？
3.5.1.22. 目前在性能方面的痛点或障碍是什么？规模？存储？并发性？查询时间？
3.5.1.23. 想使用第三方或开源工具吗？
3.5.1.24. 是否可以使用处于公开或私人预览阶段的产品？
3.5.1.25. 有哪些安全要求？需要*数据主权吗？
3.5.1.26. 数据移动是一项挑战吗？
3.5.1.26.1. 数据移动是从源系统中提取数据并将其带入数据仓库或数据湖的过程
- 3.5.1.27. 需要多少自助式商业智能(BI)？
3.6. 白板讨论
3.6.1. 使用白板，而不是幻灯片
3.6.2. ADS的核心是探索，*有大量的交谈就可以使用白板
3.6.3. 幻灯片太多，ADS就会变成了普通的演示
3.6.4. 白板内容应该包括架构的粗略示意图，以及目标、痛点和后续项目的位置
3.6.5. 白板上不仅展示了项目的架构，还清晰列出了项目的优先目标、当前面临的痛点，以及待处理事项
4. 架构设计会议之后
4.1. 摘要文件
- 4.1.1. 要总结ADS期间讨论的要点
4.2. 物理架构
- 4.2.1. 如果使用的是电子白板，可以将最终结果导出为文件，发送给包括客户在内的利益相关方
4.3. 行动项目
4.3.1. 包括已经商定的任何后续步骤
4.3.2. 如“下周二开会讨论概念验证”或“客户将通过电子邮件发送其当前架构图”
4.4. 遗留项目以及跟进
4.4.1. 当时在白板上列出了这些事项
4.4.2. 现在，可以在电子邮件中更详细地列出每个项目的跟进责任人
4.4.3. 客户就有机会澄清你们没有完全弄清楚的任何事项
4.5. 调查问卷
- 4.5.1. 在现场ADS上，最好在结束时给每位与会者发放一份调查问卷
5. 技巧
5.1. 运用幽默
5.2. 保持谦逊，即不要给人一种无所不知的印象
5.3. 让事情出错的人不仅仅是客户
5.4. 读懂会场氛围
5.5. 学会随时调整
5.6. 增强体力
- 5.6.1. 要保持6到8个小时的精力
5.7. 额外建议
5.7.1. 在通信软件中打开实时字幕
- 5.7.1.1. 不仅能让每个人都能更方便地参与会议，还能帮助大家跟上对话，避免要求别人重复
5.7.2. 使用两个不同的设备登录通话
5.7.2.1. 一个用于屏幕共享和白板演示
5.7.2.2. 另一个用于通信（大多数通信软件都支持此功能）
5.7.2.3. 建议在使用的任何通信软件的聊天工具中，与客户团队（仅限客户团队）建立一个后台沟通渠道
5.7.3. 通信设备是一台配有两到三个大显示器的计算机
- 5.7.3.1. 就不必频繁地最小化窗口或移动窗口，而且在使用白板演示和讲话时，可以始终看到客户
