面向服务架构的其中一个目标是拥有一个可以重用的集成服务目录。这始终是实施后强制执行的手动工作。通常基于每个集成模式，因此保持分散并且对特定集成团队的设计者/开发人员以外的任何人来说都是隐藏的。当您使用一个工具为所有解决方案架构师标准化整个组织内的集成建模时，您可以获得：
图 11 – 集成商店窗口的工资单部分
仍强制执行并手动维护。但是现在至少在实施之前，集中化、标准化、可发现性 巴西号码数据 以及使用近乎完美的 Archimate 元素。我们称之为“de etalage”，可以翻译为“集成服务橱窗”。
重复使用
最大的好处之一是可以重用（面向服务架构的另一个圣杯）。
图 12 – 重复使用 – 优点
图 13 – 重用 – 丑陋之处
实现
在描述“The Good”时，您通过其数据对象管理功能存档实现集成服务。但这只是故事的一部分。每个集成也 通过至少一种集成来提供。因此，在 Archimate 中它应该通过我所说的核心集成功能来实现。
这种 archimate 实现是五种集成模式之一的特定专业化（请参阅我之前的帖子）：
有一个集成员工应用（集成）服务，它与员工排班应用程序共享员工管理应用程序的员工数据对象
该集成员工应用（集成）服务由管理员工功能（未在此图中 - 参见图 2）实现。
.. 还可以通过（特定的）File-Integrate-Employee 功能
此文件集成员工功能本身是文件集成功能的专业化，是核心集成功能 (CIC)
并且此 CIC 已分配集成架构构建块 (i-ABB) 管理文件集成。
现在这个循环已经完整了。如果我们在所有集成建模中都实现这一点，我们就可以向我们的档案库提出这样的问题：“哪些集成服务是由文件集成功能实现的？”或“这个数据对象是通过哪种集成模式实现的？”。
有一种更广泛的方法来建模集成服务，以便能够提出这样的问题：如果我改变这项服务会发生什么？哪些应用程序正在使用此服务以及它们对 XYZ 数据对象执行什么操作？更多相关内容请参阅我的下一篇博文“如何使用 Archimate 进行集成建模”。
与以前一样，您可以通过 architool 存储库获取这些图表及更多内容。请给我写封信。