费钱耗时回报少？CIO更新改造应用程序前须知的潜规则之一

　　超过95%的《财富》1000强公司仍在使用IM--IBM的古老的层次DBMS(数据库管理系统)。这是TwoBitHistory.org得出的数据。
　　相比之下，我自己做的非正式调查显示，在优秀的IT开发人员中，几乎没有一个人对在该环境下工作有丝毫的兴趣。
　　能够吸引顶尖人才是CIO们更新改造应用程序的一个原因。这不是唯一的原因，却是最重要的原因之一。其他原因包括减少许可费和支持费，以及提高灵活性和适应性。
　　只不过＂更新改造＂不像看起来那么简单直观，还有几个隐蔽的秘密，精明的CIO在制定决策时必须考虑到这些秘密。 01应用程序更新改造 是个复合问题
　　应用程序更新改造(酷孩子俱乐部的成员称之为＂应用程序改装＂)涉及使用一系列全然不同的方法来解决一系列全然不同的问题。
　　应用程序改装可能意味着版本更新、平台重建、平台更换、语言更新改造、重构或COTS转换，这取决于具体应用程序和你交谈的对象。虽然它们统一叫＂更新改造＂，但几乎没有什么共同之处。各自有陷阱，需要留意。一些陷阱众所周知，另一些陷阱则较为隐蔽。
　　此外，更新改造有许多不同的含义本身就特别令人烦恼：在对特定的应用程序更新改造之前，你不仅要先决定是否对其更新改造，还要决定它需要哪种类型的更新改造，然后乘以整个IT环境中应用程序的数量。 02版本更新本身是一种债 (越晚做越糟糕)
　　一些IT团队领导认为，只要做到以下这点，就表明自己有业务头脑：＂不纯粹为了技术而购买技术＂，再加上一句陈词滥调：采取＂如果它没坏，就不要修理它＂的做法来管理应用程序及它们运行所依赖的堆栈。
　　他们把这套逻辑搬到商业应用程序以及每个应用程序运行所依赖的每个平台上：服务器操作系统、DBMS、CMS(内容管理系统)、开发环境、桌面操作系统和浏览器等等，只有当特定的新功能带来新的ROI(投资回报)时才更新。
　　可遗憾的是，＂不是现在付费，就是以后付费＂，这个定律仍然是正确的：与及时更新相比，＂以后付费＂需要的成本难免更高、带来的破坏更大。 03平台重建只解决一个变量
　　另一种流行的更新改造方法是，将遗留应用程序迁移到有相应平台的开放环境(将整套堆栈都迁移过去)，有一个不那么隐秘的地方要注意。比如说，平台重建意味着从大型机托管的z/OS+COBOL+CICS+DB2 迁移到x85托管的Linux + COBOL + CICS + DB2。在云迁移中，这个叫＂lift-and-shift＂(平移)。
　　你得到的是降低的许可费和供应商支持费。隐蔽的秘密是，这是你得到的全部好处。 04平台更换成本更高
　　平台更换是更新改造方法之一，它只改变了应用程序运行所依赖的一个平台，理由是平台已过时，或丢失了市场份额和消费者心智占有率。比如说，你可能将应用程序的DBMS由Sybase换成SQL Server。虽然这有时也叫＂平台重建＂，但它与上述的平台重建没有任何共同之处。
　　你得到的是减少了使用过时技术带来的风险和漏洞，此外还能享用更好的人才库。但你无法得到降低的成本或任何改进的功能。事实上，成本反而增加，因为你不得不为更换平台购买许可证。 05语言更新改造常常使 糟糕的情况更糟糕
　　诱人的销售宣传号称：自动化工具可以从你的遗留COBOL代码中提取业务逻辑，并用一种现代化语言重写。这常常通过将有100000行代码的COBOL应用程序换成有100000行代码的Java应用程序来完成。
　　这是语言更新改造方面最隐蔽的秘密：语言不仅仅涉及词汇和语法，还涉及应用程序设计理念。
　　第二个隐蔽的秘密是：语言通常还带来整批的预开发逻辑库。编写新应用程序的开发团队得充分利用这些库。很少有代码转换器可以做到这一点，这意味着它们生成的转换后代码维护起来更困难。
　　好了，今天的文章分享到这就结束了，要是喜欢的朋友，请点个关注哦！--我是简搭(jabdp)，我为自己＂带盐＂，感谢大家关注。