问理解TOGAF伪影应用/数据矩阵的用法

EN

如何呈现？

您提供的TOGAF链路告诉它所有的信息：

应用程序/数据矩阵是一个二维表，其中一个轴上有逻辑应用组件，另一个轴上有数据实体。

你的第一个例子就是这样。然而，企业架构的问题是复杂的。对于一个主要建立在有十几个模块的ERP上的体系结构来说，这样的矩阵是很好的。然而，工业体系结构通常有数百个组件。在这种情况下，列数使得这样的表示完全不合适。

您的第二个例子就是要解决这个问题。它不是二维矩阵，而是一维列表.它太短，无法注意到，但是您可以为几行不同的应用程序填充相同的数据实体。把它想象成一个基表，Excel可以用它做一个枢轴表来显示一个大型的无法管理的矩阵。

就我个人而言，我使用了第二种形式，这对于大型系统来说要实用得多。您只需筛选每个应用程序或每个数据实体，就可以快速获得特定主题的横切概述。

分类呢？

您希望在矩阵中对数据类型进行分类，这更具有挑战性，因为TOGAF似乎使这种分类依赖于组件：

包/打包服务环境中的数据实体可以分为主数据、引用数据、事务数据、内容数据和历史数据。

我倾向于将数据实体的分类视为企业级别上实体的属性，并将其显示在矩阵的数据实体轴上。

然而，上下文化可能更准确:虽然一个供应商一般会成为整个领域的主数据，并且良好的移动或发票交易数据，但分类并不总是明确的。例如，框架合同可以被视为MRP订购系统中的主数据(因为它作为参考存在很长时间)，而旨在缔结合同的采购应用程序可能将其视为事务性数据。项目也是一个类似的例子。项目管理软件可能将其视为主数据，而一些财务软件可能会认为这只是事务性数据。所有的数据迟早都是历史数据。因此，更谨慎的方法是在矩阵单元中显示分类。在列表中，这绝对不是一个问题。

的承诺

对于TOGAF所作的大部分承诺，我有些怀疑：

• “将数据访问分配给特定的应用程序”：在大多数情况下，数据访问是由业务分析人员确定的需求驱动的。通过提供管理地点的清单，矩阵可以方便新的分析人员的工作。
• “了解数据重复的程度”：在我的经验中，这个矩阵在这个承诺方面常常是误导的。通常，不同的系统管理相同的数据，但具有不同的细节级别(例如，产品对营销应用程序的信息可能不同于对生产管理系统的信息)，因为它们针对的是不同的现实情况。有时，应用程序甚至使用不同的实体名称(参见DDD术语中的有界上下文)，从而避免了重叠(例如，对客户或供应商与承包商的重叠)。有时不相关的实体具有相同的名称(例如，项目管理系统中的任务，生产计划系统中的任务，以及管理待办应用程序中的任务).没有一个数据架构是不容易的;-)
• “确定是否有任何应用程序丢失，并因此需要创建”：我从未见过任何作为这种矩阵的结果创建的应用程序。诚实地说:如果一个实体被更新并且从未创建，或者相反，它在其中一个应用程序中丢失了特性:用户不是在开发过程中，在创建或更新矩阵之前就已经报告了这个问题吗？

但从积极的方面看，矩阵是非常有用和值得采取的：

• 该矩阵可以帮助特定的企业项目，如企业主数据管理i。
• 该矩阵还可以通过显示处理相同数据并可能需要调整的所有其他应用程序(及其接口)，大大简化对更改或演化的影响评估。
• “支持差距分析”：实际上，当引入新应用程序(i.e.missing接口？)或替换一个或多个应用程序时，所有可用实体的清单有助于分析空白。
• “了解更新相同数据的位置”：矩阵无疑有助于这项任务。但是，这假定重叠和命名冲突是很好理解的(见前一项)。