主数据管理经验谈

申请免费试用、咨询电话：400-8352-114

文章来源：泛普软件 在刚刚过去的一年中，Builder.com公司一直没有很好的解决带有多个客户端的主数据的管理问题，为此，根据我的经验，针对这个问题我为他们写了一篇文章，告诉他们如何才能实现主数据的最佳管理。针对这个目标，在本文中，我将检查分析所有的实现进程，得到的经验教训、所走过的弯路以及对目标所做的修正。 在一个公司中，主数据管理系统（MDMS）的主要作用在于可以有一个单一的系统作为所有公有数据项的一个参考点。然后，在组织内的每个"客户"系统就可以参考这个系统来管理它的关键数据，从而可以确保在整个应用程序套件内数据的共通性以及正确性。 通过其他应用程序来了解MDMS 我在以前的文章中指出，在公司内，实现这个目标的进程来的很慢，但是确实在向前推进。这主要是因为公司中存在着这样的三类应用程序： 新创建的应用程序，包括内部和外部创建的应用程序以及一些不需要定制的应用程序。 升级的应用程序，在一个已经存在的系统中可能存在一个这样的窗口，通过这个窗口可以实现升级工作。 遗留下来的应用程序，系统中没有升级窗口，也没有该系统的替代产品。 在第一种情况中，如果在系统分析的过程中就已经认识到这一点，那么作为这种类型项目的研发或者安装和配置进程的一部分，就可以将其作为一个到MDMS系统的连接引入到MDMS系统中。如果没有做这方面的连接，那么其主要原因或者部分原因通常可以归结为没有预算、没有可用的资源或者没有时间等方面。然而，如果已经考虑到了这个连接问题并且有预算的话，那么就没有理由不让这些新的应用程序充分利用MDMS。 在第二种情况中，作为该系统升级规程的一部分，是可以规划和预算相应连接的。当然，增加这些系统到MDMS系统的连接的话，需要对这种连接的影响做大量的分析工作；例如，如果对存储在MDMS中的一个数据项进行升级的话，那么对系统的影响是什么？ 另外，在这种类型的项目中，资金一般是用于新的功能而不是用于改善基础设施，因此在一个特定的升级过程中，可能不会执行一些低优先级的连接。 最后一种情况是遗留下来的应用程序，从连接到MDMS系统的角度来说，在一些大的公司中，遗留系统是最常见的系统也是处理起来最复杂的系统。如今，很多公司都有一个用所谓的"遗留"语言如COBOL所做的重要程序，根据DevX的一份声明： "世界上70％的数据都是用COBOL语言处理的，并且90％的ATM事务处理用的都是COBOL语言。如今每天在线处理的COBOL事务有300亿次。500强中有492家使用了COBOL语言，包括全部的100强，而且目前在COBOL方面的投资已经超过3万亿美元。" 尽管情况如此，但是很少有程序员具有这种必要的COBOL语言的技能。这是因为很多有这种技能的程序员正处于退休的年龄。因为无论是在公司中还是在大学中，具有COBOL技能的程序员看起来远远没有具有如Java或者.NET技能的程序员那样有诱人的前景，如今具有这种技能的程序员的数量在急剧下降，如果公司没有明智的考虑到这些问题的话，这个问题将类似于当年的Y2K问题，可能成为一件令人头痛的事情，并且可能导致具有这种技能的程序员的大量加薪。 在有些公司中，存在着这样的谚语"如果没有出现问题就不需要修理。"并且他们将其作为另外一种常见的理由，只要这些系统能够工作就不对其进行任何改进，有限的资金、资源和时间最好用在其他地方。从而使得这种类型的系统很难集成到新的MDMS系统中，但是面对这种趋势，我的建议是：虽然这些资源仍然可以使用，但是至少应该尽量考虑到他们，当然是相对便宜的应该优先考虑。 并行研发的问题 我们所需要解决的一个主要问题是：在一个组织内研发MDMS系统的同时常常会并行的有其他的研发工作。因此在规划MDMS系统或者其他系统的行为时常常会引起一些问题。这些问题可能包含以下情景： 直到MDMS已经开始"运转"时，MDMS系统也没有得到最初规划所需要的数据。 作为一种共有的并且是系统需要的数据，可当时并没有打算将其包含在MDMS系统中。 在现存的应用程序中新识别出来的共有数据并没有从MDMS中提取出来。 对研发团队和MDMS团队来说，还有其他的限制因素如预算、时间或者资源等。 在一个组织内部署MDMS系统将可能带来大量增加修改工作，因为管理者总是试图要求研发路径和升级路径尽可能与MDMS系统自身的研发路径相符合。虽然这确实可能导致大量的令人头痛的问题以及一些其他问题，但是总体来说还是值得的。 在我曾经合作过的几个团队中，他们解决这些可能潜在问题的一种方法是：一开始将他们的数据存储在本地的一个数据库内，然后，在一个合适的时候，或者从MDMS系统中将这些数据导入到这个数据库中，或者更改连接这样就可以直接从MDMS中加载数据。通过这种方式就可以让本地应用程序按照自己的节奏、一条一条的将它的管理数据转换到MDMS系统中，而且它们就不会受到其他活动的影响也不会受到这些活动的约束。这是因为相对而言，更改一个数据库的连接器或者将另一个数据库增加到数据活动脚本如EAI或者ETL或者甚至是一个SQL Server DTS包中是一件相当容易的任务。 案例研究 在我的客户中，有一个客户很特别，任何修改MDMS系统对企业运作所造成的影响他都很清楚，并且他对在最近一次内部分类继承的更新过程中数据流过其他系统的速率也非常清楚。虽然只有一部分数据发生了改变，但是在真的发生了改变以后，IT部门就会开始接到需要技术支持的传票--它们声称系统A中的数据和系统B并不匹配，因为在当时的情况下，只有其中的一个系统发生了改变，而另一个系统还没有来得及改变。 然后，他们会发现另一个系统--系统C已经崩溃，因为系统C的数据库中包含了分类继承表和公司销售的产品之间的关系。这些改变已经破坏了原有的连接，因而导致了系统出错，并且导致系统C中有些数据丢失。幸运的是，系统在将这些已经被破坏的数据传向其他系统之前就已经发现了问题，否则的话终端用户有可能使用这些被破坏的数据来做任何他们想做的事情。 通过MDMS系统将各个系统连接在一起确实存在着一定的风险，这些风险又让你怀疑是否真的值得去冒这种风险。IT团队为此不得不投入大量的时间和资源来对系统C进行备份，更不用说他们让那些终端用户对他们失去了信心，并且终端用户完全有可能将此作为他们工作中的一段插曲。