2007-8-29  IBM交流会

今天IBM又来了。这次交流主要是针对我公司新系统上线，有大量的数据需要移植，IBM方为我们提供了两套方案：在线的、采用同步方式的不停机的移植，该方案的优点是对应用来说是透明的，不影响应用，移植速度慢，缺点是时间常，该方案也有两种实现方式，第一种是采用IBM公司专门用于数据移植的工具Piper，第二种是利用公司已经采购的SVC进行在线的同步移植；另一套方案就是采用非在线的移植，使用Piper工具，速度可达到800G/H，该方案的缺点就是需要进行停机操作，针对我公司而言，至少需要8小时以上的时间，如果评估上风险时间，至少在12小时左右。

和以往的交流会一样，参加交流的人员同样包括应用程序开发方。通过几次交流会的总结，我越来越体会到当今软件开发中，软件、硬件环境和其他系统环境（包括其他的软件环境）的不可分割性。记得上次ORACLE来交流，推广其内存数据库Times ten，在此之前，我公司的新BSS系统的开发商，在这个应用中，已经大量使用了其“内存共享”技术，来提高程序性能，但通过这次交流，我方发现，如果我们引进Times ten的话，利用其成熟的技术、和ORACLE数据库的良好的兼容、以及其良好的服务，不但可以大大起高应用的性能，而且，其完全可以取代开发商的“内存共享”技术，并且提高程序的可维护性和可扩展性，对以后系统的集成带来便利，但是，一个艰难的问题就是，如果我们要引进Times ten，那么，我们已经准备上线的系统，将面临一次巨大的修改，甚至涉及到体系结构方面的东西，这将是我们不敢想象的。

要避免这种情况，我认为，在系统的构建中，系统分析师作为一个系统的设计者，一定要有把握行业新动向的能力，及时了解新技术，新方法，因为对于一个大型的应用而言，时间几乎都是以年来记的，在这么长的时间里，我们要保证我们的系统不会被行业的发展而淘汰，这就需要我们的系统分析师，软件构架师花大量的精力好好的研究。

回到前面的数据移植问题，我方在讨论第二套方案，也就是停机的方案的时候，IBM方提到，对于我们的系统，可以只停需要移植的部分（也就是这次上线的子系统Billing系统），这样就可以保证以最小的损失完成移植，但应用开发方说，不能实现部分停机，因为这套系统中，各个子系统是相互关联的，相互影响。

这又使我想起了平时经常提到的模块的独立性，在我们这套BSS系统包括客户关系管理类系统、计费结算类系统、分析型系统和外部门户系统，各个子系统可以看成一个模块，那这么说，出现上面的问题就是因为该系统没有达到模块独立性的要求？？

看来是这样的，就我理解而言，一个系统的各个子系统之间必须保持其模块的独立性。

有人会说，当前我国企业在进行IT建设的过程中，急需解决的一个问题就是数据孤岛问题的存在，在一个公司内部，统一的数据库管理，是解决数据孤岛的有效途径。对，就我们公司而言，也存在这样的问题，所以，我们这套BSS系统，就完全采用了统一的数据库设计，统一的数据，统一的管理，保证数据的一致性。但这并不能通过牺牲程序的独立性来实现，数据的统一，那是数据层的问题，各个子系统应该完全相对其他子系统透明的存在，才能够保证其可维护性和可修改性。