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.7. 是否会使用数据看板和/或临时查询？
3.5.1.7.1. 了解数据的使用方式不仅会影响推荐的产物范例，还会影响系统的性能需求
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.1. 主数据管理(MDM)涉及为企业中的每个人、地点或事物创建单一的主记载，这些记载是从内部和外部数据源及应用程序中收集的
- 3.5.1.14. 在云中存储数据是否有任何安全限制（例如客户合同中的规定）？
- 3.5.1.15. 该解决方案是否需要全天候的客户访问？
- 3.5.1.16. 高峰时段，将有多少并发用户访问该解决方案？
3.5.1.16.1. 均匀有多少？
- 3.5.1.21. 每天需要向解决方案导入多少数据？
- 3.5.1.22. 目前在性能方面的痛点或停滞是什么？规模？存储？并发性？查询时间？
- 3.5.1.24. 是否可以使用处于公开或私人预览阶段的产物？
- 3.5.1.25. 有哪些安全要求？需要*数据主权吗？
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.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.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. 就不必频繁地最小化窗口或移动窗口，而且在使用白板演示和讲话时，可以始终看到客户
免责声明：如果侵犯了您的权益，请联系站长及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金. |
发表于 