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. 就不必频繁地最小化窗口或移动窗口而且在使用白板演示和讲话时可以始终看到客户