目前，ISA-M 主要以 Microsoft PowerPoint 演示文稿的形式提供。可以在 SAP Community 博客文章（https://blogs.sap.com/）以及关于ISA-M 的 SAP Jam 社区中找到补充性的文档和信息。
尽管 ISA-M 是由 SAP 开发和维护的，但该方法论对所有 SAP 和非 SAP 集成解决方案都是开放的。因此，即使不使用 SAP 集成解决方案、或者只在某些领域使用，也可以应用这种ISA-M。然而，请记住，PowerPoint 模板中的大部分内容都是以 SAP 集成解决方案为重点开发的，所有的例子都与 SAP 产品有关。因此，如果使用了许多非 SAP 集成解决方案，需要进行更多的定制。
ISA-M 是由 SAP 和 SAP 用户社区开发的。通过客户参与计划，所有的客户和合作伙伴都有机会帮助塑造 ISA-M 的进一步发展，并贡献他们自己的经验。此外，你可以访问 SAP Jam 的 SAP 集成架构社区组，该组有超过 1,900 名成员。这个组的目标也是进一步发展 ISA – M。
2020年5月， ISA-M 3.3 版发布，这是自 2018年10月以来的首个新版本。这个版本包括了在 Microsoft PowerPoint 模板中描述的一些变化。Katrin von Ahsen 在她的博客文章中详细描述了这些变化，链接如下：New version of the SAP Integration Solution Advisory Methodology Template released
本文链接：https://www.cnblogs.com/hhelibeb/p/17851913.html
内容摘录自《SAP Interface Management Guide》。
ISA-M 循环
SAP 提供的 ISA-M 的应用程序可以被描述为一个循环。图1 展示了 ISA-M 循环的概述。
图1 ISA-M 循环(来源：SAP)
让我们来看一下 SAP 提供的循环的四个阶段，
- 评估集成策略：旨在记录和评估集成架构。ISA-M 描述了多种方法来达到这个目的。使用集成领域和集成风格，你可以描述当前的集成景观和未来的集成景观。这两种方法可以互补，评估集成策略的另一种方法是使用成熟模型。许多项目中使用成熟模型来对集成架构进行评估。后文将详细介绍成熟模型。
- 设计混合集成平台：第二阶段，根据 IISA-M，设计混合集成平台的最重要任务是技术的分配和接口的评估。
- 定义集成最佳实践：第三阶段定义集成最佳实践。这个阶段的目标是使用描述的最佳实践来监控新的集成需求的实施，并提高接口设计的透明度。SAP 提出了定义架构蓝图作为定义集成最佳实践的一种手段。
- 实现赋权实践：第四阶段，实现赋权实践，是关于在组织内部扩展集成知识。这个阶段的目标是在组织内部将集成建立为一个公认的学科和战略功能。这个阶段伴随着通过知识共享文化进一步传播集成知识。在这个阶段，SAP 更加集中地关注集成中的角色和职责可以使用我们在后文中描述的一个名为集成能力中心的（ICC）的方法来扩展它。
集成领域
SAP 提出的集成领域非常适合对接口和需求进行粗略的分类。图2 显示了 SAP 定义的集成领域。
图2 ISA-M 集成领域 (来源：SAP)
通过 SAP 建议的集成领域，可以确定集成架构服务的接口或接口需求的类型，或者集成架构应该服务的类型。通过它，可以同时描述两个问题：
- 想要集成的应用程序或系统在哪里？
- 在集成中，哪种类型的应用程序、系统、组织或事物应该相互通信？
你可以使用集成领域作为分类接口和接口需求的初始指导。使用集成领域，可以轻松地在集成领域级别确定某些属性。
例如，可能在云-至-云集成领域有安全需求。安全通信（至少通过 HTTPS 的 SSL 加密）是云-至-云集成的最低标准。基于证书的身份验证方法也经常被用来替代通过用户名和密码的经典身份验证。然而，根据我们的经验，基于证书的身份验证程序和 SSL 加密的安全通信经常不被使用，特别是在本地-至-本地集成中。
集成风格和用例
一旦确定了系统应该如何相互集成，下一步就是所谓的技术映射，决定你将使用什么来实施所需的集成。这个逻辑在图2 中展示。可以通过集成风格派生用例和用例模式。
SAP 并未明确你如何进行可能的技术选择。建议在分配它们之前进行技术选择。可以使用两种方法进行此步骤：要么基于现有的集成解决方案和能力（例如，员工的能力）进行评估，要么基于先前定义的用例对可能的集成技术进行软件评估。
在技术选择过程中，特别注意商业环境。建议你考虑以下影响因素：
- 你的行业在消息交换中是否需要特殊的格式或程序？
- 对IT 部门有哪些特殊的要求（例如，必须满足的法律要求）？
- IT 部门内的策略是什么（例如，集中化还是分散化）？
- 已经实施了哪些集成解决方案或技术？
- 当前公司有哪些可用的知识？
当将技术分配给用例时，SAP 建议使用推荐程度来区分，如表1 所示。
| 推荐程度 | 描述 |
|---|---|
| 通用推荐 | 通用推荐应选择将通常用于特定用例的技术。注意，对于一个用例，可以有多个解决方案作为通用推荐。 |
| 合理的替代 | 作为合理的替代，某些条件下推荐的技术。应用到应用（A2A）集成用例的一个典型示例是在两个 SAP 系统之间使用 ALE 作为直接集成。如果你的通用推荐是使用中间件平台，那么 SAP 系统之间的直接集成仍然可以是一个合理的替代，因为它通常很容易实现。 |
| 可能的例外 | 对于不再想使用，但在特殊情况下仍然允许的所有技术，应该定义一个可能的例外。我们已经避免使用基于文件的接口很多年了。然而，经验显示，某些行业的某些特殊解决方案仍然完全依赖于基于文件的通信。 |
| 应避免 | 将不再想使用的技术分类为应避免。这些产品和技术是你公司长期内要替换的，可能包括例如因历史原因构建的数据库集成，或者在 SAP 环境中，过期的 SAP Business Connector。 |
表1 ISA – M 技术映射的推荐程度
SAP 建议使用这些推荐程度为每种集成风格构建决策矩阵。你可以很容易地将集成领域集成到决策矩阵中，如表2 所示。
| 技术 | SAP Cloud Integration | SAP Process Orchestration | |
|---|---|---|---|
| 推荐程度 | 通用推荐 | 通用推荐 | |
| 描述 | 如果可能，通过使用预定义的集成内容，满足所有混合集成的需求 | 在所有本地到本地的情况中使用，包括 B2B 集成 | |
| 集成领域 | 本地到本地 | X | |
| 本地到云 | X | ||
| 云到云 | X |
表2 ISA – M 技术映射的决策矩阵示例
接口评估
作为接口评估的一部分，需要通过遵循上述描述的步骤，将业务需求带入到技术决策中。
原则上，可以对现有或新的接口进行接口评估。通常，我们在设计新接口时使用接口评估，以便根据定义的集成架构进行实现。当然，也可以对现有的接口进行接口评估，以检查接口景观与集成架构匹配的程度如何。然而，我们很少在实践中看到这种做法。
图3 显示了接口评估的概述。你可以根据你的业务需求定义一个业务场景。在业务场景的范围内，至少有两个应用程序需要相互集成。基于这个要求，你可以推导出单个接口，然后将它们分配给集成风格。
图3 ISA – M 中的接口评估概述（来源：SAP）
SAP 描述了如图4 所示的接口评估过程，其中包括以下步骤：
- 确定业务场景所属的集成领域。
- 描述业务场景并确定要集成的应用程序。
- 描述业务场景的接口。
- 为每个定义的接口选择集成风格和用例模式。
- 为接口选择集成技术。
图4 ISA-M中接口评估示意图（来源：SAP）
实践中经常颠倒步骤 1 和 2。在此情况下，定义集成领域之前，必须先谈论业务场景和应用程序，而集成领域主要取决于集成的应用程序。
接口评估过程的第一步通常也包括进行采访或研讨会来提出需求。然后，可以使用步骤 1 和 2 作为设置这样一个约会的方向。
在实践中，接口评估常常中包括其他方面。例如，某些技术可能带来限制。例如，使用 SAP Cloud Integration，不能在没有（安全）文件传输协议 (FTP/SFTP)的情况下使用基于文件的通信，而使用 SAP Process Orchestration，可以实现本地文件存储。强烈建议在接口评估过程中考虑这些方面。
架构蓝图
通过前面几节描述的步骤，你已经为集成架构做出了基本决策。通过定义集成最佳实践，可以进一步标准化你的集成活动，并增加关于接口设计和实现的透明度。
根据 ISA-M，可以根据用例构建架构蓝图。在 ISA-M 模板中，SAP 提供了架构蓝图。架构蓝图的一个例子如图5所示。
图5 ISA-M 架构蓝图示例（来源：SAP）
在左侧，可以看到蓝图所属的用例和相关集成领域的一般描述。在此描述下方，可以找到属性和选择标准的列表。在右侧，可以看到蓝图的架构概述，显示了蓝图中使用的各个组件以及如何在技术上通信。
此外，ISA-M 建议为每个架构蓝图构建一个信息表。信息表描述蓝图的目标、涉及的组件以及蓝图的应用。表3 显示了云对云集成领域的 A2A 集成用例模式的一个信息表示例。
| 细节 | 描述 |
|---|---|
| 集成 | 使用基于云的集成解决方案将基于云的应用程序与其他基于云的应用程序集成。应用程序与集成解决方案之间的通信需要特定的安全方面（例如，加密）。基于云的集成解决方案由供应商运营。 |
| 使用的 SAP 产品 | 使用以下来自 SAP 集成套件的组件： • SAP Cloud Integration • 如果需要，使用 Open Connectors • 如果需要，使用 SAP API 管理 • 如果需要，使用 Integration Advisor |
| 何时应用 | 当需要在不同的基于云的应用程序之间交换事务和主数据，几乎实时，需要如映射或路由的功能或出现技术中断时。 |
| 如何应用 | • 使用预定义的集成内容或自定义界面，将 SAP Cloud Integration 作为基于云的流程集成解决方案。 • 连接非 SAP 云应用，使用 Open Connectors。 • 使用 SAP API 管理来管理、保护和控制API的调用。 • 使用 Integration Advisor 加速接口实现。 |
表3 ISA-M 的一个示例架构蓝图的信息表
这个例子首先显示了架构蓝图的粗略描述，然后是使用的技术产品的列表。这个例子中只列出了 SAP 产品；然而，当然也可以在这个信息表中包含非 SAP 产品。接下来是描述相应架构蓝图用于哪些情况（何时应用），然后是描述如何实现架构蓝图（如何应用）。建议在信息表中也引用命名规则和开发规范。
此外，ISA-M 描述了一些应做和不应做的事情，通常将这些考虑因素称为集成原则，它们对于团队协作和不同利益相关者群体之间的沟通特别有用。
另一方面描述集成技术选择。在 SAP 环境中，有各种技术可用于开发接口，包括远程函数调用（RFCs）、中间文档（IDocs）、Web 服务和 OData 服务。必须决定哪种技术用于这些应用系统。然而，根据组织结构，可能需要由其他团队做出实施和最终决策。尽管如此，集成团队应参与定义要遵循的路径：如果想指定要使用的技术，决策树可以帮助解决方案架构师和后端开发人员为接口构建正确的设计。
角色和责任
在 ISA-M 中，SAP 描述了集成环境中的八个角色。对于每个角色，ISA-M 提供了该角色在集成环境中的任务的示例描述。在 ISA-M 中定义了以下角色：
- 企业架构师
- 集成架构师
- 集成开发人员
- 集成管理员
- 业务领域专家
- 业务用户
- 公民集成员
- 应用程序/API 开发人员
企业架构师负责定义、通信和进一步开发集成架构。他们通过 ISA-M 一起进行密集的工作，并与集成架构师一起定义公司的混合集成平台。应该在选择和评估新的集成技术和解决方案时，让企业架构师和集成架构师参与其中。
集成架构师与企业架构师一起定义集成架构。他们通过 ISA-M 一起进行密集的工作，并定义和传达模式、模板和架构蓝图。此外，他们在定义技术接口需求时，是业务单位和客户的重要联系人。
集成开发人员主要负责实现接口需求。他们从集成架构师那里接收任务，作为接口的技术规格。应该始终鼓励集成开发人员向企业架构师和集成架构师提供关于模板、最佳实践和集成架构的一般性和特定的反馈。
集成管理员负责设置和操作集成解决方案。他们还从技术角度监控集成解决方案，并确保它们按预期运行。
业务领域专家与集成架构师一起定义接口需求。他们积极参与消息映射的处理，并在整体接口设计中代表业务领域的需求。
业务用户设定接口的需求，并将这些需求传达给业务领域专家，由他指导集成开发人员实施需求。业务用户通常只在后端系统中工作。
公民集成员是来自业务领域的特殊用户。与业务领域专家类似，公民集成员在接口的概念设计中参与更深。然而，与业务领域专家不同的是，公民集成员也参与接口的实施。使用特殊的工具或向导，公民集成员可以独立实现自助服务形式的简单集成。
应用程序/API 开发人员在特定的后端系统中工作。在他们的系统景观中，他们通常只知道他们支持的系统。这些开发人员负责在所需的后端系统中实现接口需求，并为这些系统定义统一的编程接口。
这部分 ISA-M 的内容也许还不够全面。另外，明确定义角色和任务是重要的；同时，集成团队的一般组织对齐至少同样重要。
使用集成领域、风格和用例特别有用和有帮助。特别是在与员工、部门或经理进行讨论时，使用前面提到的三个分类标准进行结构化的方法很有帮助。表4 展示了根据集成领域为一家公司分配技术的例子。
| 集成领域 | 相关性 | 当前技术 | 未来 |
|---|---|---|---|
| OP-到-OP | X | 各种 (例如，直连，数据库，文件等) | SAP Cloud Integration content in SAP PO |
| OP-到-云 | X | 各种 (例如，直连，数据库，文件等) | SAP Cloud Integration |
| 云-到-云 | X | 各种 (例如，直连，数据库，文件等) | SAP Cloud Integration |
| B2B | X | 区域 A: 通过外部服务提供商; 区域 B: 通过 SAP PO | 区域 A: 通过外部服务提供商; 区域 B: 通过 SAP Cloud Integration with Integration Advisor |
| B2G | X | SAP Cloud Integration/杂项 | SAP Cloud Integration |
| 用户-到-OP | X | 网络团队 | SAP API Management |
| 用户-到-云 | X | 网络团队 | SAP API Management |
| 物-到-OP | 不清楚 | 未提供 | 正在评估 Streaming hub 和 Internet of Things solutions |
| 物-到-云 | 不清楚 | 未提供 | 正在评估 Streaming hub 和 Internet of Things solutions |
表4 评估集成领域与高级技术映射
ISA – M 描述了构建技术映射的高度结构化方法。我们主要在构建集成策略时使用这种方法。你可以在表5 中看到集成风格过程集成的一个例子。
| 技术 | SAP Cloud Integration | SAP Cloud Integration Content in SAP PO | SAP PO | SAP Business Connector |
|---|---|---|---|---|
| 推荐程度 | 一般推荐 | 一般推荐 | 可能的例外 | 避免使用 |
| 描述 | 如果可能，用于大多数集成领域，使用预定义的集成内容。 | 用于合规相关的集成需求和OP到OP的通信。 | 用于所有现有的 SAP PO 实现和进一步开发。 | 维护到期；无新的开发。现有的正在连续迁移。 |
| OP-到-OP | X | X | ||
| OP-到-云 | X | X | X | |
| 云-到-云 | X | |||
| B2B/B2G | X | X |
表5 过程集成风格的技术映射示例
对于在集成策略框架内的工作，这种技术映射是有用的。然而，这种技术映射可能对于日常工作过于复杂和广泛。此外，外部利益相关者有时难以理解这种形式。因此，建议使用更简单的概述，如表4 中所示。
在 ISA-M 版本 3.3 中，SAP 引入了架构蓝图。这种增强特别有用。建议进一步扩展它，加入后端集成的选择推荐。图6 显示了在 SAP 后端系统中创建接口的技术决策树的一个例子。
图6 发送消息的技术选择的决策树示例
尽管 ISA-M 提出了集成环境中的典型角色，并提供了经典的角色描述，但是缺乏评估自己的组织结构成熟度和从集成的角度进一步发展自己的组织的方法。因此，建议也使用额外的资源和方法，如集成能力中心（ICC）。