如何为IT资产创建“依赖关系图”

Question

我的一位客户正试图为他们公司中使用的各种应用程序创建一个相互依赖的交互“矩阵”(它是一家拥有2500名员工的旅游休闲公司)。

其想法(仍处于原型阶段)是创建一种基于Visio或类似工具的Map，该工具跟踪公司中所有IT资产之间的通信和相互依赖关系，这样当有人要求更改时，他们就可以得到影响的概述。

这是在一个偶然的环境中提到的，直接做这件事并不是我的责任，但是我已经在模糊相关的方法(Zachman框架)方面贡献了我所知道的很少的东西。

我想听听这里的人，如果他们知道方法或工具，可能有助于这种努力，如果他们有任何具体的经验可以作出贡献。我将消化这些答案，并将结果发回给我的客户，希望这可能对他们的任务有所帮助(我认为这有点有远见，而且容易遇到任何文档项目的所有缺陷，但仍然很值得追求)。

N.B.：我的问题不是“我收集了所有关于IT资产的数据，我买不起Visio或Graphviz，也无法将其转换为MindMapping工具，也无法使用jGraphetc.etc创建自定义导航器”。问题是“如何收集相关/有用的信息，以及如何组织这些信息，考虑到由于界面、版本和包的更改，我可能不得不定期更新数据？”

这不是什么可视化问题，或者还不是。我们必须首先从数据收集和组织方面取得良好的开端。如果您想建议一个工具，它还必须包括数据收集和管理部分(例如：)。但在这种情况下，如果你有一些实际的经验，或者你很确定它是相当利基和不太清楚的情况下，请建议它(我可以谷歌，谢谢)。如果您想建议一些书籍/方法，这也是有帮助的(我只知道Zachman框架，并且不确定它是否真的适合)。

“只需创建一个Excel文件”或“您可以使用SmartDraw！”恐怕帮不上什么忙。

​

找到了 艾特拉计划 ，它看起来很适合！

​

Answer 1

如果我错了就纠正我..。您希望使用图表作为工具来跟踪系统的依赖关系。

如果是这样的话，您将使用的图形映射布局可能是部署图中的一个。

您可以将系统/服务器/物理资产映射为盒对象，然后在其中映射各种应用程序、数据库、组件以及它们之间的相互关系。

使用UML的问题是，程序员主要关注类图(因为它们与软件中的数据建模直接相关)，因此很难在非类UML图上找到“好的”资源和示例。

我曾经使用过一次这种方法来映射一个相对复杂的跨系统跨应用程序实现，并以一种可以在设计系统时与其他开发人员共享的方式来理解我的想法。简而言之，它很简单，而且做得很好。

为了创建图表，我使用了迪娅。如果我不得不再次使用Visio，我肯定会使用Visio，因为它更容易找到预先制作的模板/模板包与联机关系图，而且如果它们没有您所需要的，那么在Visio中使用自己的模板是非常容易的。

注意:我在Visio做电气设计方面有很多(几百个小时)的经验，所以我认为自己对这些工具足够熟悉，可以给出一个客观的比较。

采用明确规定的格式的缺点是：

• 它们通常过于复杂
• 它们通常有严格的格式或规则。
• 很容易发现自己试图将系统建模到图表中，应该是相反的。
• 图表很容易变得过于复杂，除了作者之外，任何人都无法理解/理解。

我的建议是：

• 使图表尽可能简单
• 不要害怕违反规则
• 使图表尽可能简单
• 尽你所能，使图表尽可能简单。
• ..。你说对了。

如果一个从未见过该图表的开发人员无法在查看它的头几分钟内就开始解释它的布局和含义，那么它可能弊大于利。

我认为Zachman框架是一个糟糕的选择，因为：

• 很难理解图表想要理解的“要点”
• 图表格式太复杂了。
• 这些规则的格式不灵活，限制了系统的设计，而不是补充系统的设计。

当你在研究选项的时候，问问你自己。你明白这张图的意思吗？

图形化设计的问题是，如果做错了，会使产生更多的麻烦，而没有人会使用它。无设计文档通常比糟糕的设计文档好。

我希望这能帮上忙。

Answer 2

如果您的客户想了解影响，您需要建模工件是什么，它们之间的信息流是什么，以及公司的各个部分如何与工件交互。

您可以考虑构建一个SADT模型。SADT模型中的框表示过程。标记数据输入弧显示可能将什么复合信息/资源输入到进程中；标记输出弧显示由它产生的数据/资源。控制弧表示控制处理的“大”信号。资源/机制弧显示执行该过程所需的资源(例如，硬件系统、网络、.)。

对于您的任务，您将将应用程序和公司活动视为SADT流程(框)。数据进出和控制弧将应用程序(SADT框)连接到其他SADT框，或连接到外部数据源和接收器(内部部门、员工、销售、运输，例如公司利益相关者)。因此，您可以通过各种应用程序对通过公司的信息流进行建模，以及它们使用/处理/生产/使用什么信息，以及哪些代理生成/使用数据。(所有这些都被称为“结构化分析”)。

对于复杂的SADT模型，每个进程框都可以递归地分解为子SADT图。我认为您不需要这样来建模应用程序依赖关系；您不需要知道应用程序内部是如何工作的，除非它们是真正复杂和分离的数据流。

对信息输入/输出的任何更改，删除一个应用程序，都将在SADT图中有明显的对应关系，从而使人们更好地了解后果。

这是一个很大的任务，这是正确的，你将不得不工作，以保持它的最新，这很可能是一个地方，它将失败，除非每个人都签署了长期。

对于那些没有尝试使用SADT的人来说，它是一个非常简单的系统(这与其他答案的建议相匹配--保持简单)，并且非常有效地将复杂的处理任务分解成块，在这些块中您可以看到(实际上是交流)本质上的所有东西，甚至是经理！使SADT工作的关键是避免草率；仔细定义弧和节点，不要跳过信息源或接收器。如果你这样做的话，SADT就会得到丰厚的回报。大多数白板框和箭头图都很糟糕:您无法分辨什么是真正的操作，什么是真正的数据，或者是否所有的信息都是实际显示的，以及谁使用它。

值得注意的是，SADT模型捕捉到了着色Petri网背后的直觉，它是任意复杂的异步计算模型，是Petri网的一个推广，它是有限状态自动机的推广。

Answer 3

我知道至少有两家客户，两家大型金融机构，他们实施了一个定制的webapp，允许实现相同的目标(找到依赖项来进行影响分析)，我谦逊地认为，你不需要一张地图来“可视化”事物。

基本上，存储机器、服务(app服务器、数据库等)、应用程序(语言、功能域等)以及应用程序之间的依赖关系，并实现查询模块，允许查找(可选传递的)给定应用程序的依赖项(依赖/依赖于)并打印报表。

我将使用一个快速的CRUD应用程序开发框架来实现这一点，比如RoR、Grails等等，这就是他们(上面的金融机构)所做的。