

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 資料策略架構
<a name="framework"></a>

本指南中介紹的資料策略架構是以下列現代資料和分析架構的原則為基礎：

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)

# 業務探索
<a name="business-discovery"></a>

為了有效執行業務面試，請務必了解** **您公司高度依賴資料的目標。例如，這些目標可能包括：
+ 改善業務敏捷性
+ 啟用進階創新
+ 成為以客戶為中心
+ 增加市佔率
+ 觸及全球市場
+ 啟動新的客戶平台  

在您符合公司的目標之後，您應該與業務領域的團隊成員交談。至少，專注於影響公司主要目標的領域，但如果有機會，請和每個業務領域的團隊成員討論。

在此探索對話中，您想要了解每個業務領域或業務單位 (BU) 的目標、用於衡量其區域的指標，以及資料使用如何影響其目標。以下是您可能會提出的一些問題範例：
+ 您 BU 的主要目標是什麼？
+ 您的 BU 如何為實現公司目標做出貢獻？
+ 您的 BU 中有哪些關鍵專案？
+ 每個專案如何依賴資料？

請務必了解關鍵專案、其時間表、它們如何依賴資料，以及它們如何符合或支援公司的目標。專案的範例包括：
+ 透過一致的全管道互動改善客戶體驗，並建立最新客戶動作和問題的意識
+ 根據客戶行為建立建議引擎，以提高轉換率和參與度
+ 對於線上金融產品，更快的風險計算以核准客戶信用，以避免花費太長的時間，並將客戶遺失給其他金融機構
+ 更好的銷售預測準確性，以減少供應損失
+ 透過即時最佳化詐騙偵測來減少詐騙損失

# 評估業務的資料可用性
<a name="data-availability"></a>

使用下列後續問題，以了解資料可用性目前狀態與 BU 想要達成的目標之間的差距：
+ 資料如何支援您的專案和您目前的業務目標？
+ 取得正確的資料來使用和做出決策是否具有挑戰性？
+ 取得資料的程序自動化程度如何？ 如果有的話，涉及哪些手動步驟？
+ 當資料可用時，您的團隊可以了解和使用資料，或者您必須將資料翻譯為您的業務網域嗎？
+ 您是否及時收到資料以支援您的業務決策？
  + 如何更快地取得資料以改善您的業務？ 為了推動改善，資料應該多快可用？
+ 決策者是否遺漏任何資料？
  + 如果是，缺少哪些資料？
  + 擁有此資料會有什麼優勢？
  + 缺少的資料如何影響您的主要專案？
+ 您是否有任何與合規法規相關的挑戰，例如一般資料保護法規 (GDPR) 或其他標準？
+ 您的 BU 是否有資料產品可供應用程式採取動作？
+ 您的區域是否可以提供機器學習模型來改善您的業務？ 如果沒有，其他 BUs 是否支援您在此領域的業務？
+ 您是否知道公司內部的任何資料目前不適用於您的 BU，但會支援您的專案或推動您區域中的改善？
  + 它們是什麼？
+ 您是否倚賴您區域可用的資料品質？
  + 在您使用資料之前，您的團隊是否會執行自己的資料清理程序？
  + 在您使用資料之前，您的團隊是否會執行自己的品質程序？
  + 當您的團隊處理資料可用性並產生用於分析、擴充和彙總願景的新資料產品時，他們可以與公司中的其他 BUs共用這些產品嗎？

# 技術評估
<a name="technical-assessment"></a>

技術評估很重要，因為它為您提供公司現有的目前技術功能的映射。此評估涵蓋資料控管、資料擷取、資料轉換、資料共用、機器學習 (ML) 平台、程序和自動化。 

以下是您可以由團隊在技術評估期間提出的問題範例。您可以根據您的內容新增問題。

## 資料工程團隊
<a name="data-engineering"></a>
+ 目前與為您的團隊擷取資料相關的挑戰是什麼？ 
+ 您的團隊是否需要任何無法擷取的外部或內部資料來源？ 為什麼無法使用它們？
+ 您從中擷取哪些類型的資料來源 （例如 MySQL 資料庫、Salesforce API、收到的檔案、網站導覽資料）？
+ 從新資料來源擷取資料需要多長時間？
+ 從新來源擷取資料的程序是否自動化？
+ 開發團隊從其應用程式發佈交易資料進行分析有多容易？
+ 您是否有從資料來源進行完全載入或增量載入 （批次或微批次） 的工具？
+ 您是否有用於從資料庫持續載入的變更資料擷取 (CDC) 工具？
+ 您是否有資料擷取的資料串流選項？
+ 如何執行批次和即時資料的資料轉換？
+ 如何管理資料轉換工作流程的協調？
+ 您最常執行哪些活動：資料探索和分類、資料擷取、資料轉換、協助業務分析師、協助資料科學家、資料管理、訓練團隊和使用者？
+ 建立資料集時，如何分類資料隱私權？ 如何清理它，讓它對內部消費者很有意義？
+ 資料管控和資料管理是集中還是分散式？
+ 如何強制執行資料控管？ 您有自動化程序嗎？
+ 管道每個階段的資料擁有者和管理者是誰：資料擷取、資料處理、資料共用和資料使用？ 是否有決定擁有者和管理員的資料網域概念？
+ 使用存取控制在組織內共用資料集的主要挑戰是什麼？
+ 您是否使用基礎設施做為程式碼 (IaC) 來部署和管理資料管道？
+ 您是否有資料湖策略？ 
  + 您的資料湖是在整個組織中分佈還是集中？ 
+ 您的資料目錄如何組織？ 是全公司還是每個區域？
+ 您是否有適當的資料湖方案？
+ 您是否使用或計劃使用資料網格概念？

您可以使用 [AWS Well-Architected Framework Data Analytics Lens](https://docs.aws.amazon.com/wellarchitected/latest/analytics-lens/analytics-lens.html) 補充這些問題。

## 業務分析團隊
<a name="business-analysis"></a>
+ 您會如何描述可用於您工作之資料的下列特性：
  + 乾淨度
  + 品質
  + 分類
  + 中繼資料
  + 業務意義
+ 您的團隊是否參與您網域中資料集的業務詞彙表定義？
+ 沒有在您需要時執行任務所需的資料，會產生什麼影響？
+ 您是否有任何無法存取資料或取得資料所需時間過長的案例範例？ 取得您需要的資料需要多長時間？
+ 由於技術問題或處理時間，您使用比所需更小資料集的頻率為何？
+ 您是否有具有所需規模和工具的沙盒環境？
+ 您可以執行 A/B 測試來驗證假設嗎？
+ 您是否缺少執行任務所需的任何工具？
  + 哪些類型的工具？
  + 為什麼無法使用它們？
+ 是否有任何重要的活動您沒有時間執行？
+ 哪些活動最多耗用您的時間？
+ 如何重新整理您的業務檢視？
  + 它們是否會自動排程和管理？
+ 在哪些情況下，您需要比您取得的資料更新的資料？
+ 如何共用分析？ 您使用哪些工具和程序進行共用？
+ 您是否經常建立新的資料產品，並將其提供給其他團隊？
  + 您與其他業務領域或整個公司共用資料產品的程序為何？

## 資料科學團隊 （判斷模型部署）
<a name="data-science"></a>
+ 您會如何描述可用於您工作之資料的下列特性：
  + 乾淨度
  + 品質
  + 分類
  + 中繼資料
  + 意義
+ 您是否有任何自動化工具可用於訓練、測試和部署機器學習 (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)。

# 使故事與業務目標保持一致
<a name="align-stories-goals"></a>

執行業務和技術評估之後，建議您建立圖表，其中包含每個資料用量成熟度層級的一組案例。此視覺化可讓您輕鬆地將資料用量與公司的業務目標保持一致。例如，近乎即時的詐騙偵測業務成果需要近乎即時的動作能力案例。  

這些案例是實現業務目標所需的技術功能、資料共用機制、人員和程序。您會根據業務探索訪談在圖表右側撰寫業務成果，並根據技術評估填入每個案例的狀態。然後，您可以選取貴公司應該處理的故事，並建立藍圖。 

下圖顯示根據業務成果，是否需要每個案例。它也會根據您在技術評估中收集的資訊，顯示每個案例的目前狀態。圖表後面通常會有一個報告，詳細說明每個狀態。

![\[視覺化每個資料成熟階段的啟用案例\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-aws-data/images/enablement-stories.png)


您從右側 (*業務成果*) 回到左側以啟用案例。例如，若要在第三階段 (*洞見和報告） *中啟用案例，您必須在第二階段 (*資料湖*) 和第一階段 (*資料基礎*) 中啟用其相依性。

根據評估和業務成果的要求，每個案例都分類為綠色、黃色、灰色或紅色。
+ 綠色表示故事已到位，並且可以擴展以交付業務成果。例如，在圖表中，第一個 (*資料基礎*) 階段的 CDC 擷取案例是綠色的，這表示公司擁有完成資料來源案例的工具和程序。*更好的客戶體驗*業務成果需要擷取相關的客戶資料，並充實公司內部的其他資料，以更好地了解客戶並提供個人化服務。
+ 黃色表示功能或程序存在，但它無法完全運作，或不支援業務成果所需的擴展。例如，在圖表中，第二個 (*資料湖） *階段的*集中式資料目錄*案例為黃色。這表示公司有中央資料目錄，但目錄並未完全填入其他階段所需的中繼資料，或僅供幾個業務領域使用。此分類會影響下一個 (*洞見和報告） *階段的資料共用功能。
+ 灰色表示不需要該案例。
+ 紅色表示故事是業務成果的必要項目，但尚未實作。例如，在圖表中， *Insights 和報告*階段中的*資料共用*案例為紅色。為客戶建議建立全面的機器學習模型需要分組資料集，這需要資料共用功能。不過，此案例尚未實作。在此範例中，資料共用還需要*資料湖*階段中的功能才能完全運作，至少對於屬於模型的資料集而言，但您可以看到尚未實作*資料管理*。

案例 *資料隱私權、保護和合規* （在 *Data lake *階段） 始終是必要的，而且隨著新的資料保護需求推展資料隱私權法規，它變得更加相關。例如，[一般資料保護法規 (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)、墨西哥[資料保護](https://www.dataguidance.com/notes/mexico-data-protection-overview)、哥倫比亞資料保護、秘魯 [29733 法律](https://www.leyes.congreso.gob.pe/Documentos/Leyes/29733.pdf)和[阿根廷個人資料保護法律](http://servicios.infoleg.gob.ar/infolegInternet/anexos/320000-324999/323901/norma.htm)。