共计 1255 个字符，预计需要花费 4 分钟才能阅读完成。
编程语言、软件设计架构（如微服务）、协定（如 OData）的最新趋势和停顿，以及多层和分布式部署平台的多样性，减速了由更多、更小、解耦和多样化的模块构建应用程序的趋势。
在微服务架构下，越来越多的业务应用程序偏向于由应用不同语言和技术开发并部署到各种指标运行时环境的多个局部组成。
这种利用程序模块的多样性带来了许多生命周期挑战。开发、部署和配置简单应用程序的所有独立局部波及许多步骤，通常是指标平台或应用程序服务器特定的。所需的服务必须事后配置和供给，不同的模块必须以严格的特定程序“连贯”在一起、配置和部署在多个平台上，通常应用不同的工具，反复用于测试、登台和生产环境。
零停机降级 (Zero downtime upgrade) 是另一个复杂性的起源。
SAP BTP 发明了多指标应用程序 (MTA) 一词来表白这种生命周期治理要求的多样性，而业界广为流传的其余术语，如“分布式”、“多语言”、“多模块”、“多层”或“multi-headed”的应用程序，都不足以表述这种架构的多样性。但实质上，MTA 只是现有 multi-part 应用程序的天然演变。
例如，由 UI 和数据库模块甚至利用程序代码组成的 SAP HANA XS Advanced (XSA) 应用程序就是 MTA 的示例。开发人员和管理员心愿将开发、版本、部署和操作这样的结构化应用程序作为一个逻辑单元进行治理。
另一个典型的 MTA 示例是 Java EE 应用程序，它由 bean、Web 和利用程序模块、资源适配器等组成，所有这些都受制于雷同的开发生命周期并跨多个计算层部署。
SAP Business Technology Platform 为协调的跨平台部署引入了新的散发要求。当充当 SaaS 扩大平台并采纳 Fiori 即服务 (FaaS) 概念时，应用程序开发人员须要跨异构指标（Java VM、前端服务器、SaaS 后端）散发他们的应用程序，每个指标都有本人的部署 API，同时提供，精心治理的繁多应用程序生命周期。
对微服务设计准则、API 治理的日益关注以及 OData 协定作为丰盛的服务 UI 边缘的呈现，进一步激励了应用不同语言、IDE 和构建办法开发的利用程序模块的激增。
然而所有这些局部，UI、服务和数据模型，依然必须作为一个连贯的利用程序运行。在部署方面简直没有统一性。每个运行时、应用程序服务器或云框架都以本人独特的形式治理多指标方面，通过引入各种编排解决方案（大量清单文件和格局、我的项目 JSON 文件、应用程序描述符、存储库、SAP 的 CTS+ 等）.
Cloud Foundry 等 PaaS 以灵便的形式改良了传统的应用程序服务器，它们通过容器化反对各种利用程序运行时技术。这为抉择实现技术（Java、Node.js、Python 等）带来了更多的自在。应用程序能够合成为多个模块，这些模块能够独立扩大，并且能够抉择最适宜每个模块关注的技术。例如，在 Node.js 中实现的可扩大申请预处理代理可能会笼罩实现业务逻辑的 Java 模块。尽管从运行时方面来看这是无利的，但这种分布式应用程序的开发和生命周期治理变得更加艰难。
