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

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

您所追求的是数据集成架构 - 这并不一定意味着数据仓库。你所描述的模式被称为“hub and spoke”，这很常见 - 我说你肯定是在解决你所描述的集成问题的正确轨道上。

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

所有这一切都是说数据仓库绝对可以用作数据中心 - EDW成为您的“主数据”源，EDW数据上运行所需的任何数据质量流程，ETL流程将更正后的数据恢复为各种来源 - 但通过研究数据集成主题而不是数据仓库主题，你可能会得到更好的服务，即使两者有很多相似之处并且可以重叠。

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