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

　　06重构真正实现更新改造所以当然费钱又耗时
　　重构是一种更新改造方法，将过时的应用程序结构转换成成熟可靠的实践，比如规范数据，或将整体式代码的结构换成微服务架构。
　　一些工具声称可以自动处理这种重组的大部分工作。可以试用一下，反正是供应商出钱，直到几个精心选择的产品让你相信这些工具名副其实。
　　还要注意：一些版本的自动化重构原封不动地保留了应用程序的行为。虽然这确实最大限度地减少了业务中断，但它没有将隔夜批处理应用程序转换成近实时处理，架构上的变化最有可能带来竞争优势。
　　重构带来了显著的业务效益，具体表现是提高了适应性和灵活性。但是天下没有免费的午餐。就重构而言，更不会像麦当劳的简易午餐这样实惠。架构更新改造带来了好处，但它费钱又费力。 07COTS转换实际上是最好的更新改造方法
　　更新改造应用程序组合的最佳途径常常是，把当前的应用程序＂生态系统＂换成别人编写的现代应用程序套件。这绝非灵丹妙药--凡是曾经改用COTS/SaaS 套件的人都知道这有多难，但它常常是风险最小、最干净的方法，可以把平台和架构过时的一系列应用程序换成平台和架构大有前景、可以帮助企业实现既定未来的应用程序。 08了解自己有什么应用程序比自动化更费劲
　　前面我们剖析了各种更新改造方法的隐蔽的秘密，还有一些更隐蔽的秘密需要提防。在更新改造应用程序之前，你需要拥有它、知道它是如何构建的，这样才能知道上面讨论的哪些类型的更新改造方法可能适用。
　　遗憾的是，尽管一流自动化发现工具的所有一流供应商做出了种种一流的承诺，但这些工具只对发现服务器有用，没法发现有什么应用程序在服务器上运行。
　　更为隐秘的是，如果你的应用程序清单文档不完整，以至于你需要自动发现工具，说明其实你没有将每个应用程序运行所依赖的平台(开发环境、服务器操作系统、DBMS、内容管理系统以及其他工具)一一记入文档。除非你知道这一点，否则就无法选择上面讨论的哪种更新改造方法会带来最大的好处。 09软件是观点应用程序整合是论点
　　每个业务应用程序都表达了开发团队关于组织的某个方面应如何运行的观点，其观点的语法用代码写下来，其词汇被融入到应用程序的数据设计中。
　　如果两个或多个应用程序的范围出现重叠--举一个简单的例子，当应收账款系统和CRM系统都维护客户数据时，就需要自动化来保持两套记录同步。再算上应用程序组合中的所有应用程序的重叠之处，结果可能是成百上千个自定义的点对点接口程序：每当开发团队添加或更改一个应用程序时，需要修改和回归测试所有这些接口程序。
　　ESB(企业服务总线)或类似的技术有助于减少为每个应用程序定义单一接口的绝对数量。
　　但除了数量庞大的接口外，还有语义不一致问题--也就是说，你的应收账款系统和CRM系统的客户数据模型不一样，协调同一实体的不同定义使整合一开始就很棘手，维护起来更为棘手。
　　ESB无法解决不同语义的问题，因为这个问题首先不是技术问题，而是开发人员意见不一致。 10更新改造IT员工比更新改造他们支持的应用程序更难
　　你的员工队伍可能很擅长维护和改进组成当前应用程序架构的那些应用程序和底层平台，他们可能还很了解如何使用他们的应用程序，让公司按预期运行。
　　他们可能不是非常了解你的更新改造计划和将要实施替换的应用程序和平台。
　　如果你的更新改造计划会实现，你就需要他们像现在一样了解替换系统。
　　除此之外，你还需要他们变得很能干，以便他们发现：只有熟悉可用工具和当前情形的聪明人才能发现改进业务的机会。
　　一个隐蔽的秘密是，让他们卷铺盖走人，改而招聘接班人，这招无济于事。
　　当然，你可以解雇他们，但是找到有能力的接班人并不省钱，也不容易。不管接班人的能力有多强，有一条经验法则是：换员工需要公司支付相当于一年的薪水，这个成本通常过高。 11运作顺畅的IT组织很少需要更新改造
　　运作顺畅的IT组织会实行生命周期管理，他们会一直保持所有系统是最新的。这使得预算易于管理--应用程序改装稳定有序，很少有＂大爆炸式＂的项目，一个附带的好处是你的员工队伍可以与应用程序和平台一样保持与时俱进。
　　好了，今天的文章分享到这就结束了，要是喜欢的朋友，请点个关注哦！--我是简搭(jabdp)，我为自己＂带盐＂，感谢大家关注。