SAP集成技术（三）接口管理的挑战

接口管理不是一个新概念，在云应用出现之前，就有接口管理问题，和混合场景相比，不同应用间的集成更为常见。经典的问题包括：哪个工具是我的使用场景中的正确选择？如何操作我的集成平台？如何设计组织？以及如何保护、监控和控制集成？

本文链接：https://www.cnblogs.com/hhelibeb/p/17844094.html

集成工具的选择

不同的集成需求使得必须使用不同的集成工具。在大多数情况下，特定的工具适用于特定的使用场景。当选择一个用于跨系统流程集成的平台，或者在需要实时传输大量数据的场景中，你需要考虑各个方面。毕竟，市场上有许多集成平台。但是，哪些集成平台最适合你的需求呢？平台本身应该在你自己的数据中心内部运行，还是在云上运行？包含哪些连接器，以及需要哪些连接器来满足你特定的集成场景？应用使用什么数据格式？

集成架构师，负责定义企业环境的集成策略，通常试图找到最佳的方式来满足各个开发团队和项目的集成需求。对这些人来说，找到最适合当前和未来集成需求的集成技术非常关键。基于混合IT环境的转型项目正在将数据集成和跨系统访问变得越来越重要。无论是在本地系统还是云系统中，应用程序环境的碎片化以及集成工具数量的碎片化都在增加。集成平台的选择是个复杂问题，因为多个不同的集成平台可能为开发人员提供类似的功能，即使各个工具的主要目的并不同。例如，多种不同的集成工具中都支持模拟process flow。客户的场景和需求决定了进行单纯的系统集成还是更复杂的系统编排。集成的质量和效果取决于它如何满足需求。

集成治理

集成治理决定了集成的规则，为了在开发和运营接口中实现高质量标准化的程序，集成治理涉及集成相关的规则和方法。相关过程可能涉及到各种各样的团队和资源。

遗憾的是，需求可能没有被清晰地定义或集中管理。在许多公司中，正在并行运行的各个项目的集成需求只在需要时传递给开发中的同事。各部门可能缺少专门的联系人，因此，需求被分散控制，没有在集中治理体系下进行管理。由此产生的最坏结果是，需求被重复实施，并且不遵循清晰的开发指南。开发人员各自有自己喜欢的集成方法。有些人更喜欢OData服务；有的人更喜欢基于文件的消息传递。在IT中，通常缺乏与接口和技术以及如何和何时使用它们相关的行为规则。最后需求实现了，但信息孤岛也随之形成。关于单个集成场景及其实施的特定知识可能只存在于被委托实施的开发者的头脑中。许多公司轻视知识反馈和文档记载，导致它们难以实现。

集成治理的核心目标是建立需求管理，引入指导实施需求的集成原则和模式，并确保对场景进行持久和清晰的文档记载。

运维集成平台

集成平台的选择确定后，下一步就是运维（Operations）。运维包括集成团队在每个项目和日常业务中必须考虑的主题。集成平台的日常业务运维涉及到确保和监控当前正在运行的运维（即，生产集成场景）以及未来的运维。除了确保有序的管理上线，包括对新集成场景的广泛测试，运维也意味着适当的变更管理和运输过程。当一个新项目开始时，必须持续进行接口测试。测试从第一次系统的技术连接开始，结束于从实施阶段过渡到常规运维。

在测试管理中，必须将测试作为实施的一部分记录。测试包括以下内容：

• 开发者测试
• 进程和模块测试
• 负载和性能测试
• 回归测试

根据接口的上下文和开发阶段，这些测试会检查集成的不同方面：
开发者测试通常发生在接口开发结束时或之前，并且只在较小的集成框架内进行测试。
进程和模块测试通常在关键里程碑处进行。在这里，整个（集成）进程也相应地进行了测试。
此外，也可以进行负载和性能测试，以检查是否可以传输预期的消息量，或者是否会发生性能下降。

在进行了所有这些措施并且集成场景在生产中运行后，这些测试可能需要随着时间的推移进行调整，无论是通过修复错误还是新的需求。在这个上下文中，常见的流行词是回归测试。请注意，回归测试不是功能测试；它们只确保代码库的更改不会对现有功能产生负面影响。

所有接口经过成功测试后，必须将它们传输到生产。这种传输很少是一次性活动，因为传输需要灵活地应对新的需求和更改。在业务需求、法律法规发生变化的情境下，能够快速应对变更请求并考虑这些变更对现有系统和流程稳定性的影响非常重要。详细的流程文档和它们的依赖关系，以及相关支持IT系统的使用，可以在这个领域提供帮助。相关系统之一是SAP Solution Manager + SAP Change Request Management。它们允许你从头到尾集中控制变更过程，使你能够在SAP环境中管理变更和传输。需要注意的是，除了SAP Solution Manager覆盖的SAP系统外，其他非SAP应用通常也会受到变更的影响，并且在传输和调整过程中也必须考虑。

在所有测试和传输完成后，必须监控定期的操作：需要澄清谁将分析正在运行的接口，是否可能委托服务提供商进行监控，或者是否可以由内部员工进行24/7的监控概念。除了谁负责监控的问题，还必须澄清必须通知哪些人群，以及通知的及时性。那么，接口依赖的响应时间是多少？监控的成本与收益的平衡也很重要，比如可能有些人认为接口对公司至关重要，需要有持续的监控，但设备和系统并不一定是全天候运行的，有时甚至可以考虑人工监控。因此要综合各种条件来考虑决策。

组织架构

除了以上描述的方面外，还有一个关键因素对集成质量的影响巨大：组织架构，它影响接口的实现和集成工具的使用。每个员工和团队每天都面临许多挑战，这影响了各个团队甚至各个部门之间的工作方式。挑战包括：

• 技术和系统的进一步发展
  例如，销售过程通常只在形式上进行修改，而在集成领域，无论是技术还是架构方面的进一步发展都必须不断审查。如果需要，应将新的发展纳入自己的工作方法中，同时也要考虑到核心系统的持续演变。
• 专业部门的不同速度
  如何支持敏捷的部门，同时还服务于经典的瀑布模型？并非每个组织都完全按照敏捷方法进行工作。例如，可能缺少的是敏捷方法在项目流程中的锚定，或者员工适应这种工作方式的适当心态。
• 在集成各方面之间的平衡行为
  集成是咨询、开发、技术和架构问题以及掌握技术细节的混合体。当涉及到两个不同的部门时，可能需要增加调解员和中间人。集成开发人员通常远不止是纯粹的实施者，在许多项目中，他们也充当业务和IT之间的链接。

那么，如何克服这些挑战呢？

从这些挑战中可以识别出三个培训领域：

1. 经典的专业培训。
2. 不同项目管理方法（敏捷与瀑布）的知识。
3. 以及与角色模型、方法和框架的经验。

为了掌握这一广泛的范围，集成团队基本上应就以下问题达成一致：

• 团队是否有专业角色互相补充，或者说，团队更多的是一群通才？
• 当团队成员参与长期瀑布项目时，如何在团队中满足敏捷需求？
• 是否已经定义了从项目模式转移到运营模式的知识转移流程，并考虑到外部服务提供商？
• 集成团队是否只提供服务，还是因为主题而更深入地参与这些过程，扮演一个控制角色？

关于组织相关的内容，可能会在后文中进一步讨论。