本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 数据策略框架
本指南中展示的数据策略框架基于现代数据和分析架构的以下原则：
1. 使用**集成式、经济实惠且可扩展的存储层**，以使每个数据生产者和使用者都具备与数据交互的技术能力。
1. **安全性是强制性要求**。应用数据隐私规则，通过加密提供数据保护，启用审计，并提供自动化合规性。
1. **治理数据**以在整个公司内共享。提供独有的数据目录和业务词汇表，以使用户可以查找和使用其所需的数据。
1. 选择**适合作业的合适服务**。在选择组件时，请考虑功能、可扩展性、数据延迟、运行服务所需的工作量、韧性、集成和自动化。
1. 使用**人工智能（AI）和机器学习（ML）**。
1. 为业务人员提供**数据素养**和**抽象化**工具。
1. **检验数据计划的假设**并**衡量其结果**。
数据框架采用[从客户需求倒推工作](https://docs.aws.amazon.com/whitepapers/latest/building-cloud-operating-model/step-1.-work-backwards-from-the-customer.html)的方法。此方法可在 Amazon 和 AWS 上使用，分为五个步骤：
1. 访谈公司各业务领域的用户。选择可通过数据举措解决的业务问题和机会。
1. 定义业务领域内的预期业务成果。
1. 优先考虑对业务影响最大的举措。
1. 确定数据共享和技术能力以实现业务成果，并将其分组为赋能项目。
1. 确定角色和职责，以实现数据驱动型举措，并探讨多学科团队组建。
以下各节将讨论此过程的主要阶段：
+ [业务探索](business-discovery.md)
+ [评测数据可用性](data-availability.md)
+ [技术评测](technical-assessment.md)
+ [将故事与业务目标保持一致](align-stories-goals.md)
# 业务探索
为了有效地进行业务访谈，务必从宏观层面了解****公司依赖数据的目标。例如，这些目标可能包括：
+ 提高业务灵活性
+ 推动前沿创新
+ 以客户为中心
+ 扩大市场份额
+ 进军全球市场
+ 推出全新客户平台
与公司目标达成共识之后，您应该与各业务领域的团队成员进行沟通。至少要关注影响公司主要目标的领域，但如果有机会，可以与每个业务领域的团队成员进行沟通。
在本次探索对话中，您想要了解每个业务领域或业务部门（BU）的目标、他们用来衡量其领域的指标以及数据使用如何影响其目标。以下是一些可能提出的问题示例：
+ 您的业务部门的主要目标是什么？
+ 您的业务部门将如何助力实现公司的目标？
+ 您的业务部门有哪些关键项目？
+ 每个项目如何依赖数据？
务必了解关键项目、其时间线、其如何依赖数据，以及其如何与公司目标保持一致或支持该目标。项目示例包括：
+ 通过持续的全渠道互动提升客户体验，并建立对客户最新行为和问题的认知
+ 根据客户行为创建推荐引擎，以提高转化率和参与度
+ 对于在线金融产品，加快审批客户信贷的风险计算，避免审批时间过长导致客户流失到其他金融机构
+ 提高销售预测准确性以减少供应损失
+ 通过实时优化欺诈检测减少欺诈损失
# 评测业务的数据可用性
使用如下后续问题，了解数据可用性的当前状态与业务部门想要实现的目标之间的差距：
+ 数据如何支持您的项目和当前的业务目标？
+ 获取正确的数据以供使用和作出决策是否存在困难？
+ 获取数据的过程自动化程度如何？ 涉及哪些手动步骤（如果有）？
+ 数据可用时，您的团队是理解并使用这些数据，还是必须将其转换为您的业务领域？
+ 您是否及时收到用于支持业务决策的数据？
+ 更快地获取数据将如何改进您的业务？ 为推动改进，应以何种速度提供数据？
+ 决策者是否缺少任何数据？
+ 如果是，缺少哪些数据？
+ 拥有这些数据将带来哪些优势？
+ 缺少的数据将对您的主要项目有何影响？
+ 是否面临任何与通用数据保护条例（GDPR）或其他标准等合规性法规相关的挑战？
+ 您的业务部门是否拥有可供应用程序采取行动的数据产品？
+ 您的领域能否提供机器学习模型来改进业务？ 如果不能，是否有其他业务部门在这一领域为您的业务提供支持？
+ 您是否了解公司内部有哪些数据目前无法供您的业务部门使用，但可以支持您的项目或推动您所在领域的改进？
+ 具体是哪些数据？
+ 您是否依赖您所在领域可用数据的质量？
+ 在您使用数据之前，您的团队是否会执行自己的数据清洗流程？
+ 在您使用数据之前，您的团队是否会执行自己的质量流程？
+ 您的团队研究数据可用性并生成用于分析、丰富和汇总愿景的新数据产品时，他们能否与公司的其他业务部门共享这些产品？
# 技术评测
技术评测之所以重要，是因为它为您提供公司已具备的现有技术能力图。评测涵盖数据治理、数据摄取、数据转换、数据共享、机器学习（ML）平台、流程和自动化。
以下是您在技术评测期间可以提出的问题示例（按团队）。您可以根据具体情况添加问题。
## 数据工程团队
+ 团队当前面临哪些与摄取数据相关的挑战？
+ 团队是否需要任何无法摄取的外部或内部数据来源？ 为什么无法使用？
+ 您从哪些类型的数据来源摄取数据（例如，MySQL 数据库、Salesforce API、收到的文件、网站导航数据）？
+ 从新的数据来源摄取数据需要多长时间？
+ 从新来源摄取数据的过程是否已实现自动化？
+ 开发团队从其应用程序中发布用于分析的事务数据有多容易？
+ 您是否拥有用于从数据来源进行完全加载或增量加载（批量或微批量）的工具？
+ 您是否拥有从数据库进行持续加载的更改数据捕获（CDC）工具？
+ 您是否拥有用于数据摄取的数据流选项？
+ 您如何对批量数据和实时数据进行数据转换？
+ 您如何管理数据转换工作流程的编排？
+ 您最常执行哪些活动：数据发现和编目、数据摄取、数据转换、帮助业务分析师、帮助数据科学家、数据治理、培训团队和用户？
+ 创建数据集时，如何对其进行数据隐私分类？ 如何清理数据，使其对内部使用者有意义？
+ 数据治理和数据管理是集中式还是分散式？
+ 如何强制执行数据治理？ 是否有自动化流程？
+ 管线各分阶段（数据摄取、数据处理、数据共享、数据使用）的数据所有者和管理者是谁？ 是否存在用于确定所有者和管理者的数据域概念？
+ 通过访问控制在组织内共享数据集时面临的主要挑战是什么？
+ 是否使用基础设施即代码（IaC）部署和管理数据管线？
+ 是否有数据湖策略？
+ 数据湖在整个组织内是分布式还是集中式？
+ 如何组织您的数据目录？ 是全公司范围还是按领域划分？
+ 是否已落实数据湖仓方法？
+ 是否使用或计划使用数据网格概念？
您可以通过 [AWS Well-Architected Framework Data Analytics Lens](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/analytics-lens.html) 来补充这些问题。
## 业务分析团队
+ 您将如何描述可用于工作的数据的以下特征：
+ 清洁度
+ Quality
+ 分类
+ 元数据
+ 业务意义
+ 您的团队是否参与了所在领域中数据集的业务术语表定义？
+ 如果在需要时没有完成工作所需的数据会有什么影响？
+ 是否能举例说明无法访问数据或者需要很长时间才能获得数据的场景？ 获取所需数据需要多长时间？
+ 由于技术问题或处理时间，使用小于实际所需数据集的频率如何？
+ 您是否拥有具备所需规模和工具的沙盒环境？
+ 您是否能进行 A/B 测试来验证假设？
+ 您是否缺少完成工作所需的任何工具？
+ 哪些类型的工具？
+ 为什么无法使用？
+ 是否有您没有时间执行的重要活动？
+ 哪些活动最耗时？
+ 业务视图如何刷新？
+ 其是否自动安排和管理？
+ 在哪些场景中，您需要比所获得数据更新的数据？
+ 如何共享分析？ 使用哪些工具和流程进行共享？
+ 您是否经常创建新的数据产品并将其提供给其他团队？
+ 您与其他业务领域或整个公司共享数据产品的流程是什么？
## 数据科学团队（用于确定模型部署）
+ 您将如何描述可用于工作的数据的以下特征：
+ 清洁度
+ Quality
+ 分类
+ 元数据
+ 意义
+ 您是否拥有用于训练、测试和部署机器学习（ML）模型的自动化工具？
+ 您是否拥有用于执行 ML 模型创建和部署过程中每个步骤的计算机大小选项？
+ ML 模型如何投入生产？
+ 部署新模型的步骤有哪些？ 这些步骤的自动化程度如何？
+ 您是否拥有用于训练、测试和部署批处理和实时数据 ML 模型的组件？
+ 您是否能使用和处理足够大的数据集，代表创建模型所需的数据？
+ 如何监控模型并采取措施进行重新训练？
+ 如何衡量模型对业务的影响？
+ 您是否能进行 A/B 测试来验证业务团队的假设？
有关其他问题，请参阅 [AWS Well-Architected Framework Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html)。
# 将故事与业务目标保持一致
在您进行业务和技术评测后，我们建议您创建一个图表，其中包含每个数据使用成熟度级别的一系列故事。这种可视化使您的数据使用可以轻松地与公司的业务目标保持一致。例如，近实时欺诈检测业务成果需要近实时行动能力故事支持。
这些故事包括实现业务目标所需的技术能力、数据共享机制、人员和流程。您可以根据业务探索访谈在图表的右侧写下业务成果，并根据技术评测填写每个故事的状态。然后，您可以选择公司应处理的故事，并制定路线图。
下图根据业务成果显示每个故事是否必需，同时根据技术评测时收集的信息显示每个故事的当前状态。图表通常后面附有一份报告，详细说明每种状态。
![\[可视化每个数据完善分阶段的赋能故事\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-aws-data/images/enablement-stories.png)
您可以从右侧（*业务成果*）向左侧反推，以启用故事。例如，要在第三阶段（*洞察和报告*）启用故事，您必须在第二阶段（*数据湖*）和第一阶段（*数据基础*）启用其依赖关系。
根据评测和对业务结果的要求，每个故事分类为绿色、黄色、灰色或红色。
+ 绿色表示故事已经准备就绪，可以扩展以实现业务成果。例如，在图中，第一阶段（*数据基础*）的 CDC 摄取故事是绿色的，这表示公司具备完成其所拥有数据来源故事的工具和流程。*更好的客户体验*业务成果需要摄取相关的客户数据，并利用公司内部的其他数据对其进行补充，以更好地了解客户并提供个性化服务。
+ 黄色表示能力或流程存在，但尚未完全发挥作用或无法支持业务成果所需的规模。例如，在图中，第二阶段（*数据湖*）的*集中式数据目录*故事是黄色的。这表明公司有一个中央数据目录，但该目录尚未完整收录其他阶段所需的元数据，或者只有少数业务领域使用该目录。此分类会影响下一阶段（*洞察和报告*）的数据共享能力。
+ 灰色表示该故事非必需。
+ 红色表示故事是业务结果所必需，但尚未实施。例如，在图中，*洞察和报告*阶段的*数据共享*故事是红色的。要创建全面的客户推荐机器学习模型，需要对数据集进行分组，而这需要数据共享能力。但该故事尚未实施。在此示例中，数据共享还需要*数据湖*阶段的能力才能完全发挥作用（至少对于作为模型一部分的数据集来说是如此），但您可以看到*数据管理*尚未实施。
*数据隐私、保护和合规性*故事（*数据湖*阶段）始终是必需的，并且随着新的数据保护要求推动数据隐私法规的加强，其重要性也随之提升。例如，[通用数据保护条例（GDPR）](https://gdpr.eu/what-is-gdpr/)始于美国的[《弗吉尼亚消费者数据保护法》（CDPA）](https://law.lis.virginia.gov/vacodefull/title59.1/chapter53/)和[《加州消费者隐私法》（CCPA）](https://oag.ca.gov/privacy/ccpa)，并且已经在一些拉丁美洲国家落实，例如巴西的 [Lei Geral de Proteção a Dados Pessoais（LGPD）](https://www.serpro.gov.br/privacidade-protecao-dados)、墨西哥的 [Mexican data protection](https://www.dataguidance.com/notes/mexico-data-protection-overview)、Data Protection in Colombia、秘鲁的 [Law 29733](https://www.leyes.congreso.gob.pe/Documentos/Leyes/29733.pdf) 和 [Argentina Personal Data Protection laws](http://servicios.infoleg.gob.ar/infolegInternet/anexos/320000-324999/323901/norma.htm)。