2014年5月12日星期一08:59

数据迁移-千里之旅

撰写者

您举办了讲习班,咨询了利益相关者,提出了书面要求,制作了用例,协同设计了UI,每个人都很高兴。然后似乎无处不在,您发现旧系统中的数据拒绝整齐地放入新系统中。突然间,进展顺利的项目陷入混乱。

到底是怎么发生的?

数据迁移通常是项目中最容易被忽略的部分,涉及从旧系统迁移到新系统。 (注意:我正在使用通用术语系统来涵盖从应用程序到网站的所有内容。)虽然可能有很多人参与发现新的业务需求或设计新的UI,但数据迁移任务本身往往被遗忘了大约或委托给一个人(通常是团队中的下级成员)。从表面上看,数据迁移似乎是较容易完成的任务之一。毕竟,只是将数据从一个系统传输到另一个系统。这种简单性使许多项目经理(有时甚至是业务分析师)认为数据迁移可以与交付系统所需的主要任务分开。甚至BABOK在7.4定义过渡要求中也模糊地谈论了这一领域。没有具体提到数据迁移的任务。它的框架为“在新旧解决方案之间移动信息”,或者在数据本身的情况下,“需要开发用于转换此信息的规则,并且可能需要定义业务规则以确保新解决方案正确解释转换后的数据。”

任务规模较小的印象通常导致将数据迁移安排在项目结束时而不是开始时进行。不幸的是,将迁移分析推迟到以后或者不了解全部含义可能会造成相当严重的后果。该项目可能会延迟运行,并且预算被用光了。更糟糕的是,新系统从旧系统中的坏数据开始,或者根本没有数据。如果决定不移动数据以确保交货日期不变,那么数据最终将在两个系统之间分配。旧系统需要保持比预期更长的时间,并且由于维护两个系统来完成相同的工作,因此成本激增。

数据迁移通常由于对数据收集的含义的误解而出错。如果将计算机系统简化为最基本的组件,则计算机仅是一种收集数据,存储数据,对数据执行操作,从数据中获取结果,然后使用该结果生成结果或更多数据的方式。例如,在一个计费系统中,您收集数据(提供服务的人员的姓名,该人员的联系方式以及该人员正在为其计费的服务),然后对其进行操作(计算该人员是否在结帐期间内欠任何钱),然后生成结果和/或更多数据(将账单发送给该人,然后从该人处收到付款,或者该人仍然负债)。

如何在旧系统中收集和存储数据以及如何在新系统中收集和存储数据,这决定了数据迁移是直接还是困难。在数据仓库中,将数据从源系统移动到目标系统的过程称为ETL(提取,转换,加载)。

理解您在数据迁移中可能遇到的困难的关键是ETL的“转换”部分。您极不可能从旧系统迁移到新系统,而不必以某种方式转换数据。例如,一个典型的问题是旧系统可能将地址详细信息存储在一个字段中。这些值以逗号分隔。这意味着街道号,街道名称,郊区和城市值包含在一个字段中。但是,新系统现在为每个值都有一个单独的字段。现在,您必须弄清楚如何将旧系统中单个字段中的值移动到具有多个字段的新系统中。如果您很幸运,用户会用逗号分隔字段中的每个值。如果您不走运,则没有任何规定。或者,您有几个用户制定了自己的规则-他们不是用逗号分隔每个元素,而是用管道(|)分隔了每个元素。

对于团队中经验不足和非技术性的项目成员而言,这种类型的问题似乎只是一个烦恼,项目经理有时可以在说明其情况时视其为技术人员而忽略。
但是,即使是最小的数据问题也可以开始迅速增加成本,并要求企业做出一些艰难的选择。例如,如果企业要解决地址值问题并将值正确地移动到新系统,那么这将需要有人编写ETL脚本来转换该数据。在运行脚本之前,必须对数据进行分析和清理,以确保ETL可以正常执行。如果有成千上万条记录(或数百万条),则清理数据以使其一致性足以转换并加载到新系统中,可能需要雇用临时人员根据数据状态手动更正记录。例如,如果地址值是以非结构化的方式输入的,并且无法应用任何转换规则,则只能使用人工干预和判断来对其进行校正。

看似很小的技术问题,即传输数据,突然变成了一项昂贵且耗时的任务,需要临时工和开发人员编写ETL脚本。面对成本上升和必须延长交付完成日期的情况,企业可能会开始恐慌,随后的决定可能导致新系统中的数据在投入使用之前结构不良。例如,将有问题的值简单地整体移到新系统的注释字段中,目的是使用户在他们的正常工作时间内纠正问题。

数据的其他问题导致整个过程被认为“太难了”,仅移动了可以一对一传输的数据。例如,只有一个人的名字,中间名,姓氏,性别和出生日期才能进入新系统。其他所有内容均已存档。如果您不必再查看数据,则归档数据就很好。但是,这种情况极不可能发生,并且必须在两个系统之间进行搜索会产生不太理想的用户体验。

数据迁移通常具有五个一致的因素,这些因素在项目交付过程中会引起问题。

  1. 负责执行差距分析的人员可能没有数据背景,或者已经在数据收集和存储方面忽略了重新设计业务流程的重要性。
  2. 数据迁移本身留到最后一分钟,并分配给其他业务分析师或测试人员。它们通常与业务隔离,因为迁移被视为独立的技术任务。任务也可能分配给团队中经验最少的成员,例如初级业务分析师。
  3. 企业已决定不再收集某些类型的数据,或者他们不确定为什么首先收集数据。初始分析无法识别组织中仍可用于数据的其他部门或部门。
  4. 迁移所需的时间比预期的要长得多。数据迁移可能会变成一项重大的智力挑战,需要进行数月的分析。对于必须迁移组织的整个员工历史记录(包括请假,一段时间,津贴和薪资水平)的薪资项目尤其如此。
  5. 没有人考虑迁移的缺陷率。即使成功的迁移也可能具有很小的缺陷率,一旦移动记录,就需要解决该缺陷率。知道是必须重新开始迁移还是可以手动纠正缺陷,可以在几天,几周或几个月的延迟之间有所不同。将数据从一个系统迁移到另一个系统时,数据迁移很难达到100%完美。如果需要,您应该始终留出更多时间检查和清理新系统中的数据。

考虑到上述所有方面,数据迁移问题是否可以解决?关键是尽早开始,并确保您咨询开发团队。

您的第一步是与您的数据仓库团队联系,或者找到一个了解ETL的开发人员。

根据数据迁移的复杂程度,您将需要帮助。您需要从了解ETL的人那里获得帮助。

您还应该对提取,转换和加载的含义有清楚的了解。

您的第二步是为两个系统构建一个数据模型。

您当前的系统做什么?运气好的话,已经有一个现有的模型。您的新系统做什么?运气好的人已经在您的团队中完成了数据模型。

如果您没有一个系统的模型(或者两个系统都没有),则需要构建一个模型。这是您可以比较两个系统中数据状态并检查差距的唯一方法。

第三步是确定奇数字段或数据存储方式的问题。

当您查看模型时,两个系统之间是否存在一对一的匹配?还是有标记不明的字段似乎毫无意义?是否按照本文开头的示例进行操作–您将值串联到一个字段中,而该字段必须在新系统中拆分为单独的字段?

取决于您的开发人员或供应商在开发旧系统时的仓促程度,他们可能在字段命名方式方面走了一些弯路。我最近查看了一个系统,该系统的日期字段标记为“ Date1”,“ Date2”,“ Date3”和“ Date4”。 UI在不同页面上的日期字段含义稍有不同(一个是创建日期,一个是修改日期,一个是删除日期,一个是单独记录的创建日期)。但是,当这些日期存储到数据库中的字段中时,它们没有任何上下文。例如,“ Date1”是记录的更新日期还是记录的创建日期?

您需要充分了解每个字段的含义,然后才能决定如何(或是否)可以将数据移至新系统。

您的第四步是查看新系统的规格。

如果由于仍在设计中而无法获得新系统的数据模型,请查看是否可以从规范中发现任何明显的问题(如果项目中存在)。

寻找所有人都会想到的东西,但事实并非如此。数据丢失了吗?基数(数据之间的关系)是否不正确?

这些情况中的任何一项或全部都可能表明您需要重新进行差距分析或开始新的差距分析。

您的第五步是找到数据的所有使用者。

您组织中的其他部门或业务领域可能会使用这些数据。您需要找到此数据的所有使用者,因为即使企业不再希望收集数据,数据对于其他领域也可能非常重要。

无论好坏,有人要求提供数据。完全有可能只是在当时为某个人的报告需求添加了它。但是,您需要挖掘出这些事实,并确保如果决定忽略以后的数据,以后也不会导致问题。

这似乎是又一个显而易见的步骤,但是如果新系统复杂或项目涉及很多人,则可能会意外丢失。

您的第六步是检查与企业的发现。

研究完成后,您应该能够解释企业的任何异常情况,但更重要的是,您应该确定任何迁移问题的可能结果。通常,新系统中缺少数据可能会干扰用户完成任务的能力。指定新系统的要求时,企业可能尚未意识到此问题。

结论

您应该为数据迁移做好准备,使其比最初评估的更加困难,并被迫做出结果并不总是理想的决定。您应该为企业做好准备,以使其误解他们所要求的含义,或者当他们理解时会被需要做出的决定所淹没。

项目压力可能会导致解决方案不仅不理想,而且还会从BAU(照常营业)的角度产生问题。

在项目中进行数据迁移的时间太晚可能意味着您的旅​​程甚至还没有开始。

一个成功的项目将意识到他们必须尽快开始其数据迁移分析,并请有经验的分析师为自己提供完成向新系统成功过渡的任何机会。

不要忘记在下面留下您的评论。

伊冯·哈里森(Yvonne Harrison)

伊冯·哈里森(Yvonne Harrison)CBAP曾担任系统程序员,技术作家,高级业务分析师,项目经理和企业解决方案架构师。伊冯曾经从事过一个糟糕的混合项目,该项目使一家公司破产。

©BA Times.com 2020

麦格雷戈徽标白色网站