程式語言、軟體設計架構（如微服務）、協議（如 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 模組。雖然從執行時方面來看這是有利的，但這種分散式應用程式的開發和生命週期管理變得更加困難。