应对企业不断变化的系统

      每个企业都经常会因为战略或市场进行市场调整，也会因为公司规模的不断扩大而对公司内部进行扩张和改造，我一直在思考我如何应对这种变化，有没有软件的银弹可以让我解决这一切的变化呢，事实上我现在还没有发现它的存在。

 

      前段时间接到指示，将原来的系统，一个一对一的销售、库存、采购系统变成多对多的销售采购系统，这个问题实质上是对原有架构的修改，因为最初该系统并不是为多对多销售、库存、采购而设计的，很多地方都是单一的点对点业务流程，若扩展成为多对多的话必有大动作。

 

      如果你的老板一点儿也不懂技术，他用天真的眼神看着你，然后试探性的问你，这个不需要多少时间吧，修改起来应该不是太难吧，这个时候我应该如何回答呢？第一，我清楚这种软件架构性的修改是在应对企业扩张的战略计划，每个公司或软件的每个阶段都存在这种情况，从企业管理的角度来考虑，这种战略计划的扩张所引发的软件的适应，在软件功能本身来说应该是容易按需而变的，应该是方便扩展的，如果不能做到这些，那就是这个软件不够优秀，这是从企业角度出发去思考；第二，从软件或开发者角度去考虑，企业的变化是不定的，软件是否可以在不改动架构的前提下灵活适应企业变化，本身是一个架构师能否深入了解企业，并且对企业接下来的动作具有前瞻性，并且，该架构师还应知道从软件设计的角度，哪些是不需要过度设计，哪些是应该留有扩展的架构，并对软件开发工作量和时间有一个大致预期。

 

      事实上，以上的架构师是理想的情况下所存在的角色，大多数时间里，业务流程是装在一些人的脑代里，软件设计是装在另一些人的脑袋里，而对企业前瞻和重要计划的又装在另一批人的脑袋里，要将这些东西组合起来，是一件相当困难的事情，而且，重要的，重要的是软件在第一次投入巨大成本进行开发后，如果很大的架构问题或是企业的扩张已经超过了该软件所服务的范围了，那么该软件就必须进行重新设计，这个过程就算是强大到微软这种公司，也会在几年之后重新设计一些软件的内核。

 

      但不是每个老板都能理解这些事情的，我遇到的这个老板呢，他在整个软件的生命周期的过程都在开发新的业务逻辑，而且有些业务功能刚刚开发完成，业务流程就改变了，当业务流程改变的时候，有时关联的财务，采购，库存，统计等一流程就全都改变了，可谓系统越到后来，修改起来就越小心翼翼，越是复杂和费解。

 

      我正在花业余的时间写新的架构的产品的文档，我希望我写好后老板可以采纳或提出修改意见，而且可以同意对系统进行重构，另外一个重要的问题是重构的时候，数据迁移的问题，在多在五百多张表的系统里，数据迁移将是另一个很重要的问题。

 

      如果我的计划不能得到实施的话，我必须做出选择。

      软件随企业需求按需而变，我的思索......