软件工程的进一步发展——特别是面向对象的建模和适当的编程语言——使得将整体划分为组件成为可能。此步骤不需要对架构进行彻底的重新思考，因为即使在组件化整体中，以数据为中心的设计也很流行。虽然组件之间的协调意味着接口设计需要付出更多的努力，但总体成本却降低了。原因很简单：
现在可以使用更广泛的面向对象语言，例如 Java，而不是大型计算机常见的编程语言 - COBOL 和 PL/I。
这个概念的逻辑演变导致了一个系统，其中由可重用组件构建的一些单体相互通信。每个整体都承担特定的职责领域 - 例如，通过控制支付交易，包括预订控制和账户管理。
这当然不会令您感到惊讶：只有基于面向服务的架构的新设计 药房数据库 模式才能远离纯粹的数据视图。其中最突出的形式是微服务。在这个系统设计中，设计重点是服务之间的接口，这些接口比组件化的单体小得多。然而，微服务架构的引入需要对核心银行系统进行彻底的重组。虽然划分的整体架构仍然可以大致基于功能架构，但微服务必须以这样的方式进行切割，以创建高水平的技术凝聚力，同时最大程度地解耦。这需要对专业领域有深入的了解。与此同时，早期开发阶段的数据模型作为实现细节逐渐淡出背景。举个例子：虽然订单管理以前只是账户管理的功能，但微服务只会接管 SEPA 转账的接收、技术验证和转发。
如果技术削减能够更好地体现该领域，那么技术削减通常可能会超出核心银行系统的经典系统边界。构建这种形式的架构的先决条件是具有网络功能的基础设施。这可以使用 Java 或相关语言来完成。最初引入该架构的相对较高的成本被显着降低的维护和运营成本所抵消。
与旧的设计相比，微服务可以在小型标准化环境中运行。它们也是使用标准化框架开发的。这降低了硬件、专有软件和操作的成本。由于标准化，微服务更容易扩展，并且可以通过虚拟化操作平台进一步降低硬件成本。从这个级别开始，环境称为云。
随着基于微服务的核心银行系统的发展，服务数量将急剧增加。因此，必须在每项服务中提供能够实现服务之间的通信和管理的功能。在服务网格中，这些功能被外包给直接集成到服务中并基于标准库的基础设施层。这使得自动化管理成为可能。顺便说一句，这样的层被称为“sidecar”，承担控制功能，有助于提高服务请求的效率和可靠性以及整个系统的可靠性。