北达软陶涛：云计算的应用迁移策略

下面我们看一下业务一致性和技术一致性，这里左边业务一致性，从6个方面，每一个指标上面我们可以提出一个问题，问卷里可能有两到五个问题，来跟客户进行交流，来评估这个应用到底从指标上满足是什么。右边是从技术一致性来看，后面也有两到五个问题，来看客户目前的应用环境。这是相当于一个蜘蛛网的图，我们看这里是典型应用，左边来看一下，这个绿色是应用映射，从安全方面和监督方面，实际上往云迁移的有一定风险，尤其公有云方面，蓝色的公有云方面差距很大。这是需要考虑的问题才能在业务上进行调整或者改造，去满足这种迁移，来降低迁移风险和提高一致性。看右边一致性方面，实际应用映射基本是覆盖的。6个指标一致性比较好，刚刚提到背后可能有两到五个问题，可以和客户进行交流。我们得出每个应用打分。

这边是一个象限图，右边横向指标是一个技术一致性的分数，纵向是一个业务一致性分数。我们看一下左下象限实际上业务一致性和技术一致性都不好，都比较低。这种情况下侯选应用不太好。这种情况下要做一些相当大的应用改造和基础设施技术改造，才有可能做一个侯选，这里首先要做基础设备改造部门，他会考虑到底往不往前走，有没有这个可能去做改造。左上象限技术一致性比较低，业务一致性比较高情况下，这是一个比较好的一个侯选，我们通过技术改造，通过应用改造提高技术适应性，有可能做一个比较好的云计算的迁移侯选。看右上象限，这块都是在技术一致性和业务一致性都比较好，相当于比较好的云迁移一个侯选，可以说不用再太大改造，或者不做改造，直接迁移到云上。右下象限就是一个业务一致性比较差，技术一致性比较好。业务一致性比较差，我们回想前面指标，包括安全性，监督性，还有几个指标都不好，这种情况我们可能考虑是否外包，也可以由服务商帮助建立私有云应用。

我们前面提到一个第一步进行评估。每一个技术一致性和业务一致性，每个都有6个指标，每个指标后面都可以提出两到五个问题。每个应用可以打分，对于适应性做一个比较好的判断。得到云迁移应用侯选的话，我们用EA方法论，就是企业架构方法论，对改造的应用做出目标架构，它的架构各个方面，首先业务架构，还有信息架构、应用架构、基础架构、安全架构，以及企业信息管理这些方面架构，我们要对当前业务线和业务目标规划，与目标架构做差异化分析。在这个基础上最后可以做一些转型业务场景。

刚才谈到应用改造，在前面评估非常好的准备情况下，这是一个信息准备，以及用EA方法论的指导，可以用现有的一些软件工程方法应用改造，可以用以下几种接口方式：包括代码重构、平台迁移、接口改造、重新架构、系统替换、系统废弃。大家做软件工程比较了解，代码重构，一般针对 z/OS遗留大型主机系统的应用，采用COBOL, PL/I 和汇编语言，平台迁移就是遗留系统到低成本新操作系统的迁移，而不对业务特征和功能进行大的改变。平台迁移解决方案可以是在进行周期较长的重新架构的应用改造同时，对大型主机系统环境的快速的转变方案平台迁移和接口改造之间共有的工具可以使得平台迁移的项目方便地包含接口改造方案， 以便客户可以升级应用界面。如果环境是COBOL/CICS/VSAM/DB2/IMS, 那么就是一个平台迁移的甜蜜点，平台迁移是应用改造的最小风险方案。接口改造这个大家比较熟悉，接口改造和平台迁移的共有的工具可以使得平台迁移的项目方便地包含接口改造方案，另外Web服务方法，可以支持一些大型主机应用，使的大型主机应用它们功能得到延伸。重新架构是一个比较重量级的方法，就是说我们从遗留系统提取业务对象。重新开发新应用，目标状态架构假定已存在。否则，目标状态架构的问卷可以帮助获得足够的信息来进行重新架构。

最后我看一下，这几种应用改革方法，它的偏重点、效益和风险问题，对于系统替换或者系统废弃目前应用情况，如果商业软件或者EPR套装软件风险比较低，可以流程重新梳理做改变。可以集成几个应用代替原来替换或者废弃应用，集成可能带来高风险。如果从客户应用组合中一定要某应用替换掉，我们可以检查一下其他应用是否可以有替代功能。我提到几个典型根据应用特性的改造，包括平台迁移，最后重量级重新架构。我们可以很明显的看到，前面的重构、改造、迁移是比较低成本的比较稳定的，功能优良，目标可以达到的短期投入等这几方面的优势。对于重新架构我们知道周期比较长，成本比较高，一般在一些特殊考虑情况下，应用必须进行重新架构，用其他方法不能达到我们的需求，这时候需要重新架构。虽然周期比较长，而且人力成本比较高。

由于时间关系，我的汇报就到这里。希望跟大家进一步分享和讨论。谢谢!

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友