引言

前言

改造它之前得先了解它，我们不可能改造一个我们不了解的事物。所以了解是改造的前提，是必要条件。

一个旧系统改造必然经历如下4个阶段。从不需要改造，到开始改造，到改造完一小部分、到改造完绝大部分直至完成改造，每个阶段可能时间不一，但是绝对不会缺失任何一个阶段。

旧系统

首先，一个系统之所以被称为老系统，那么其必然是运行很多年的系统，例如5年或者更长的时间，系统在运行期的期间承载相关方各种各样的诉求；并且在此期间相关方一直在发生变化或者调整著，由于这些相关方的变化导致对于系统诉求的重点或者要求也同样发生著变化。如果把一个系统比做一件棉袄的话，那么经过这些年的使用已经变成各个位置厚度不一样的棉袄，例如左胳膊位置厚一点，右胳膊的薄一点。

其次既然旧系统的改造，那么说明这个系统还是正在运行的，至少某种程度是满足相关方诉求的，否则那我们谈论的话题就会变成旧系统下线了。那么一个正在运行的且一定程度上能够满足相关方诉求的系统为什么要去谈改造呢？这是我们谈改造的过程无法回避的问题，因为回避这个问题就会陷入一个局部的陷阱中，变成一种一叶障目的改造，得不到更多相关方的支持。

既然回避不了这个问题，那么怎么理解这个问题？

旧系统的改造这个话题的提及就是因为这个旧这个字。对于系统相关方来说（外部矛盾），我们可以分别从正向以及反向去论证旧带来的潜在问题。从正向来看，就旧系统由于运行较长，存在很多已经不需要但是却依然存在的功能，这些功能的迭代导致系统的冗余，那么可能会影响系统的整体性能以及新功能的扩展（例如新的投资场景）的实效性，前者浪费相关方的时间后者带来潜在收益的减少；从反向来看，系统冗余程度的提高，导致修改任何地方潜在犯错的概率提升同时也会导致解决问题的效率，前者导致易出现问题，后者导致出现问题难度加大，扩大潜在的影响，造成更大的损失。

对于旧系统的开发人员来说（内部矛盾），由于旧系统采用旧的架构对于维护系统的技术人员吸引力较少，潜在的人员流动风险势必也增加，那么冗余的旧系统的维系随着人员交接的频繁会导致外部矛盾的进一步加深。

就算这些矛盾的存在，是否旧系统也是就要立马改造的么？我看不一定的。因为上面的内外部矛盾是一直存在的，这并不能推动着旧系统改造的开始。因为系统的改造从朴素的认知来看，是一个相对中长期的事情，这个过程中可能会带来潜在的好处并不能抵消潜在的风险（例如出现更多的错误，系统变得更不稳定等），所以需要一些新的出现的外部矛盾推进这些矛盾激化，进而推动旧系统从不需要改造到开始改造这个阶段，这些外部矛盾可能是新的政策、新的复杂的需求、新的业务场景等。

（二）

一旦系统开始改造，从改造开始到改造结束，大概可以拆分这3个阶段，旧系统的旧模块占主导、旧系统的新模块占主导以及旧系统变成升级改造之后的新系统（这个时候旧系统旧模块已经被新模块替换，那么旧系统已经变成新的系统），这个新系统替换旧系统支撑著企业业务的运行。

旧系统旧模块

凡事预则立不预则废，旧系统一旦进入改造阶段的那一刻开始，所有的规划或者行动都是为了实现成功改造系统这一战略目的所服务的，但是在每一个阶段具体的情况从现象来看可能并不一样

旧系统是一个正在运行的系统，其是满足日常的运营需求的。这也是旧系统之所以成为旧系统的根本原因。但是旧系统因为其经年久月的运行，从内部看，内部模块之前的关系必然错综复杂，这种问题出现的原因可能是不同时期不同的设计思路、不同的资源情况等不同的内外部环境导致的；从外部看，旧系统在运行的过程中必然与相关的外部系统产生交互，这种交互体现在以不同的方式不同的频率从其他系统接收某些数据、以不同的方式不同的频率向下游传输某些数据或者两者皆有。这些内外部的情况导致旧系统改造的复杂度。

旧系统新模块

旧系统的旧模块占主导，这意味着此阶段的旧系统已经存在新的模块并且已经融合到旧系统中。但是这个新的模块是先从哪一部分开始，这是需要我们严肃对待的。一般来说新的模块之所以称之为新的模块，那么其必然至少包含如下一种特性，新的交互方式、新的逻辑或者新的功能组件等。如果将这种特点用IT的语言大体就是，新的UI设计以及页面交互、新的数据模型以及封装逻辑或者新的功能模块或者系统服务等。

其次这个阶段的新模块是为进入下个阶段进行奠定基础的核心模块。如果这个阶段并没有走上正确的道路那么势必会导致后续产生较多的弯路。那么到底从哪里开始呢？引用中国革命胜利前夕毛泽东提出的三条基本外交方针之一：打扫干净屋子再请客。那么对应到系统来说先从内部开始再到外部交互。为什么这样说呢？因为系统与上游的交互会影响系统内部的流转，系统与下游的交互会影响下游系统内部的流转。上游之于自身就好比自身之于下游系统。这种影响特别在业务系统关系极其复杂的系统群更是常见。

所以新模块的选择往往从系统的内部开始，并且与上游交互或者下游交互的都无关的模块开始。那么这种情况往往是技术型的且与业务无直接关系的模块。但是是否有从外部开始的系统呢？当然是有的，正如之前的所说的，上游之于自身就好比自身之于下游系统，当上游系统或者下游系统因为不可抗拒的力量发生修改，导致必须从外部开始，但是这种的思路往往是先建立一个屏障模块隔离，之后又回到刚才讨论的优先级，即是技术型的且与业务无直接关系的模块。

这样做的战略意义在于，在改造的初期，避免直接对上下游产生影响，避免直接对系统的使用方产生影响，并且在内部可以形成一种改变的风气进而带动整个进程。

新系统新模块

当旧系统的新模块按照上述的方式逐步迭代之后，那么旧系统中就会产生若干个新的模块。新的模块之间按照新的功能组件与其他模块，包括旧模块在内产生交互。那么这个时候旧的系统往往会剩下如下若干个核心的模块，但是无论怎么看其主要是由这三类构成：与上游交互的模块、与下游交互的模块以及含有核心业务的旧模块。那么针对这几个模块的优先级如何进行排序呢？从潜在的风险以及影响面来看，上游交互模块以及含有核心业务的旧模块优先级应该是高于下游系统的模块的。其原因在于对于下游的影响相对是未知的，并且改动相对较大的。但是具体到实际情况还是要看，上游对比下游特别多又特别复杂，那么这个优先级也是需要改动的。

那对于上游（下游）对比核心的业务旧模块来说，优先级又是如何呢？

这个阶段从整体进程来看，已经处于改造或者升级的中后期，那么对于改造后的系统的核心使用方是需要感受到新系统的进程的。那么从形式上分析来看，需要旧的业务模块作为核心的切入点，那如果恰巧这个时候上游的数据又是核心的业务模块，这种场景必然是需要抓住的。但是系统的使用方更多的是交互方式的层面的修改，这种就好比房屋装修中的软装，那么这个阶段系统的交互是需要进行某种程度的优化或者改变的。

这种改变就相当于在系统的外部营造一种新系统的感觉，总结下来就是系统改造的中后期是对于业务团队系统改造的前中期。这种情况的出现是因为旧系统固有的特点所导致的。

结语

系统改造是否有可能失败的可能呢，这是必然存在的，如果不认识到有失败的可能，那就是陷入违心主义的陷阱中，但是在这个过程中只有找出来那些会导致失败的原因，并解决它才有可能完成这个改造的过程，这一篇会在接下来的一章讨论。