数据仓库是跨技术共享客户数据的良好解决方案吗？

Question

我希望能够以降低基础架构整体复杂性的方式在我们业务的所有领域共享数据。

问题

我们的问题是我们目前有 4 个主要应用程序都连接到我们的 CRM 应用程序 (Microsoft Dynamics 2011)：

我们公司的决策者目前希望将我们的 CRM 升级到最新版本，然后随着新升级的发布（每 2-3 年）保持最新状态。我们几乎所有的应用程序都与 Microsoft Dynamics 严格集成，因此每次升级都非常昂贵且风险很大。我想设计另一种方法来降低这种费用和风险。

研究

2006 年，Roger Sessions 写了一篇名为通往企业架构的更好途径 (here) 的文章，其中概述了改进业务 IT 系统的方法。他讨论的中心主题之一是降低复杂性，通过以不同的方式安排芯片，他表明您可以通过将技术划分为多个部分而不是让任何技术连接到任何其他技术来以指数方式降低系统的复杂性。 Jeanne Ross 也有关于这个主题的精彩演讲 (here)，她谈到了在业务领域之间共享核心数据和服务的数字化平台，以降低整个系统的复杂性并提高响应的敏捷性满足当前和未来的业务需求。

结论

当我回顾 Sessions 和 Ross 的经验教训时，我相信如果我们希望每 2-3 年对这项技术进行一次大修，就需要将 Microsoft Dynamics 排除在我们架构的中心之外。我们只需要用允许我们的核心数据（主要是客户数据）跨应用程序共享的东西来替换它。我知道数据仓库通常用于在整个组织中聚合数据。这行得通吗？

我了解数据仓库主要用于报告，所以我不知道直接连接到数据仓库是否理想。但是，每个应用程序都不需要更新数据仓库中的任何数据的能力。他们只需要能够获取他们的 ID 就可以在每个应用程序的数据库中建立全局、数据仓库实体（客户）和各种特定于单位的实体之间的关系。

问题

这三个选项中的哪一个可以满足我的需求：(1) 所有应用程序直接连接到的数据仓库，(2) 通过夜间更新将数据提供给每个特定于应用程序的数据库的数据仓库，或 (3) 其他?

谢谢

Answer 1

您所追求的是数据集成架构 - 这并不一定意味着数据仓库。您所描述的模式称为“中心辐射”，它很常见 - 我会说您在解决您所描述的集成问题方面绝对走在正确的轨道上。

This page 更深入地探讨了这个问题和模式，它还有一节介绍了数据仓库和数据集成之间的区别。您已经注意到，您知道数据仓库通常用于报告 - 这是真的，并且它们也大量用于分析，正如链接所讨论的那样。它们传统上是商业智能工作的数据源。这可能意味着他们并不总是专注于您感兴趣的数据类型 - 即您的系统需要运行但可能对报告或分析目的不感兴趣的操作数据。或者，它们的运行方式可能无法满足您的需求 - 例如，如果您需要更快地更新应用程序，传统的夜间 ETL 加载可能不是最佳解决方案。

所有这一切都是说数据仓库绝对可以用作数据中心 - EDW 成为您的“主数据”源，所需的任何数据质量流程都在 EDW 数据上运行，ETL 流程将更正的数据发送回各种来源 - 但研究数据集成主题可能比研究数据仓库主题更适合您，即使两者有很多相似之处并且可能重叠。

如果您在没有任何商业智能要求的情况下创建数据仓库，则它可能无法很好地用作数据仓库。一个非常合适的数据集成/主数据解决方案可能无法解决您对数据仓库的所有未来需求。同样，如果您在研究数据仓库最佳实践后创建传统数据仓库，它可能无法满足您的数据集成要求，或以最佳方式满足它们。正如链接所示，将这两个想法分开：解决您的数据集成问题，如果您将来想要一个数据仓库，您可以使用您的数据集成解决方案来帮助填充它。