如果组织具备应用集成，就必须及时更新吗？组织如何避免应用集成维护中常见的陷阱？在我们最新的博客中，Forrester分析师 Randy Heffner提出了一些解决该问题的好方法和软件集成管理预测。

　　我是SearchSOA的Maxine Giza。我们今天有幸请到了Forrester的Randy Heffner。Randy，欢迎您参加我们的节目。

　　Randy Heffner：好的，谢谢，Maxine。

　　非常感谢您！那么今天，我们从应用生命周期管理的角度谈一点关于集成管理的问题。Randy在节目的开始，你是否可以告诉我们一些关于软件集成或者应用生命周期管理领域内的软件集成管理的相关问题？如果可以的话，你是否也可以谈谈它们之间的不同之处？

　　Heffner：恩，这取决于你所说的应用生命周期管理是从产品的角度考虑还是从学科的范畴考虑。从产品领域的角度上讲，我不敢肯定它是否全面，而且要使其变得全面会非常困难，这是因为集成技术是一个多元化的领域。如果其中包含了应用程序集成、数据集成、流程集成及相关领域，就可以实现集成的功能，或许也不可以，例如复杂事件处理和业务规则。

　　如果你愿意，你也可以从流程集成协作的角度来设计，因为，你要将人组织到软环境中，这是流程中要考虑的一部分。这具有一种很强的协作关系，要将一些协作或社交工具投入到环境中，并希望人们愿意使用该技术，而且最好是随意的。
　
　　但是，如果从学科的角度来看，我不会使用当今的“应用生命周期管理”，我将其称之为“解决方案生命周期管理”，因为集成技术跨越了个人应用程序的界限。过去，所谓的集成就是将所有孤立的应用集中起来，使各个孤立的应用丣轻松地相互依存。再往前，Forrester认为集成技术不是一个好方法。有时候，它需要考虑你需要做的事情。但是，其实我们所要达到的集成技术就是实现业务及核心业务成果的一致性操作。所以，应该从业务设计角度出发，在研究中得到使用“数据业务设计”这一观点。

　　然后，从这个角度考虑可以认为，它是“生命周期管理解决方案”的另一个理由。作为其中的一部分，作为确保你已经具备一致的业务能力的一部分，你最好能够将集成管理好。但这是一个新的观点，我没有看到业内人士认为集成是为了实现一致业务功能，这是从连接孤立应用的业务和技术两个方面进行考虑的。

　　那么Randy，如果一个组织已经集成了一系列的应用，如何对其更新？

　　Heffner：我们从两个不同的角度来谈谈。一个方面是，我们已经经历过许多数字业务设计战略流程，我们正在探讨并已经确定了一些应用集成。也许有时，我们要基于用户工作环境进行考虑，用户界面要呈现出用户所需的工具，或者，需要对用户角色使用强制的方法使其融入到多个应用程序，或者，对一些流程或基于SOA的东西做一些事情来统一业务和实现多个孤立应用以外的一致业务。

　　恩，孤立应用会时刻改变，如果以企业内部方式传递成品或已打包应用程序，那么，对生命周期的升级和集成技术就会有所控制。公司不愿意企业内部自有的应用程序经常更新。但是如果是基于软件即服务的（SaaS）你就不必对应用程序升级和功能的变化进行控制。因此，无论从预防问题的角度还是利用机遇的角度都必须具备认知能力。什么时候使用集成策略来把应用聚集到一起？什么时候以及以什么方式他们会改变？在使用企业SOA策略来更改集成时的时候和方式又意味着什么，稍稍考虑一些本地的，内部的基础东西？

　　如果企业只需要考虑降低运营成本，减少维护和管理的一些麻烦的话，也许其他项目可以建立你使用的新型服务，但最终你还是想要使用最新版本的服务。因此，这些都是良好监测策略的充分理由，可以了解到应用程序何时及如何在集成流程中变化，确保遇到何时及如何升级、更新问题时做出理智的决定。这些问题所反映的事实是业务随时在变化，同时也促进采用一些新的方法。

　　Randy刚才您提到了集成维护，你能说说你所见过的出现在应用集成维护、管理中的常见误区吗？

　　Heffner：好的。也许最常见的误区就是我前面所提到的，就是如果它没有坏，就不要去破坏它。如果正在运行，就不要想着做任何改变。但问题是,这会远远落后于企业现在使用的打包应用，例如，现在，突然之间,升级到当前的最新版本被列为首要任务。因此，被我们忽略的应用程序维护是我们所要考虑的主要因素。

　　我认为另一个大误区是我所提到的连接这些孤立应用所面临的思维定式，那么你就会错过了达到更好效果的机会，通过引入新类型的集成模型和采用新方法做集成会取得较好的业务成果。也许你可以以数据集成、应用集成之类的方式，把数据放在后端。但是，也许真正的问题是，业务流程会被破坏，你需要通过高水平的集成来进行维修，通过建立数据和SOA集成来实现目前所做的面向流程的集成。当我提到SOA，顺便说一下，我们应该注意到，我是以“应用程序编程接口”为例。无论是内部API还是外部开放网络集成都经常被称为“API管理”。

　　如果让在该问题上推荐一些最佳方法，您觉得什么方法比较好？

　　Heffner：我会推荐这两种方法。你已经准备好并看到了使用业务为中心的方法的价值，但我们向此方法说不。如果你准备做数字业务设计并看到了业务，那么我认为你正在对基于业务成果分析的集成做决定，从一致性分析和商务人士的角度分析业务流程，就会知道该业务领域、成本和运营成果的重要性，那么你就会在做集成时考虑到这些因素。

　　但如果你不这样做,那么,你的关注点就会变为，建立良好的监测系统，了解应用程序如何及何时变化，无论这些SaaS是企业内部的还是定制的应用程序，都是为了了解这些程序是如何变化，如果在适当的时机进行集成更新的话，，就会做出一系列的评估。除此之外，我认为最好的实践是，你可以借鉴一些成功应用SOA公司的经验，就会了解到不存在所谓的没有下一个版本的应用程序，因为，如果考虑将集成作为应用程序的方法，也许就需要适用于每个程序。因为，即使如果你不需要提供新业务功能，你也需要以不同的方式、不同版本的SOA、相同的应用程序来避免积累技术债务。

　　因此，从学科的角度，我会拿汽车养护打一个比方。每个拥有爱车的人都应该知道定期更换机油是十分重要的，特别是车比较旧时就更加重要，使车继续跑和对车进行维护最重要的是更换机油。如果能做到这样的养护，汽车就会变得更便捷。我意思是，通过更换机油，不可能立即看到效果，但是你还必须这样做。

　　所以，在做其他养护工作时，也许仅更换机油就会使车变得更便捷，就像一台安装了音响的新车。如果召回或者发生一次碰撞，那么就必须进行一次大修理。但是这样也行不通。有时候你就得咬紧牙关,花费一些时间更换机油让爱车跑得好。对待集成本身也应该保持这种观点，这样企业的应用程序才能继续运行。因此，我们需要明白持续维护是一项日常开销，并且有时你想要对其加以控制，但是，为了业务流程进展顺利，就必须做出一些贡献。

　　Randy这是一个很好的比喻。我想问最后一个问题就是想让您谈谈有关预测的事情。从应用程序生命周期管理软件集成的角度，你是通过什么样的工具、更改和流程预测到现在或者近期所发生的事情？

　　Heffner：我一直听到大家对多种元数据管理和类似工具的争议，无论是面向XML的模型还是纯数据和元数据管理，都需要结合数据集成或报告等其他方法。我认为这会对未来集成维护的顺利进行起到一定的作用，但是，对其是如何发生，还没有一个清楚的认知。该行业还有许多没有被发开发的创意，无论是从供应商还是用户的角度，都可以发现做好元数据管理工作的有效方法。

　　举一个例子，对于数据结构和SOA是我听过两个名字，但是，你也可以称其为“公共信息建模策略”或“规范信息建模策略”。我比较倾向于“公共信息建模”。但是，我们要知道存储在数据库中的数据是如何建模的，或者与在SOA信息或者REST API结构中的数据是转化成模型的方式有何不同。但尽管如此,我们也应该对两者之间的一致性有一定的比较。如果“用户”在数据库中规定了一种方式，那么就不应该在SOA信息中规定另一种方式。常见的信息建模策略试图在二者之间找到共同点，这对元数据管理也有很大的帮助。

　　我认为另外一个主要问题就是“治理”，关于敏捷治理我们在Forrester已经讨论了很多。我认为正确治理存在很多方法，因此，就不会听起来像“我们是来自于架构团队的，是来帮助你们的，”而是像“我们是来自政府的，是来帮助你们的”一样。但是，治理又是其中很重要的一部分。我前面所提到的“没有所谓的没有下一个版本的应用”，这就需要治理确保其按照计划发展，并在其远离中间点之前，应用程序要与最新的集成接口，和对不同集成点所做改变一起成长。因此，我认为治理和元数据将会是也这个领域的未来相关的两大关键词。

　　好极了Randy，这就是我今天所要问题所有问题，非常感谢您参加我们的节目。

　　Heffner：Maxine谢谢，非常感谢您的邀请。