Platform Engineering for Adaptive Internal Developer Platforms with Golden Paths

1. Introduction

The increasing complexity of modern software development is pushing many organizations to their limits: Development teams need more autonomy and speed, while operations and governance must ensure security, standardization, and compliance. At the same time, technology stacks, project structures, and requirements are becoming increasingly fragmented.

To address these challenges, platform engineering is a discipline within software engineering that focuses on building self-service toolchains, services, and processes to quickly create a reliable and stable internal developer platform (IDP). This shared platform is used by software development teams to accelerate innovation while maintaining reliability for the developed software products as well. For platform engineering, it is essential to understand the platform architecture for building platforms as a product [10].

At adesso, the core of platform engineering is the creation of adaptive Internal Developer Platforms (aIDPs), technical platforms provided by central teams (platform architects and engineers) for efficient, secure and scalable use by application development teams. A central concept for the successful implementation of this approach are the so-called Golden Paths. Originally coined by Spotify, a Golden Path provides an engineering team with predefined, reusable, and proven ways to implement typical development tasks. A Golden Path is more than a template – it bundles (1) best practices, (2) security guidelines, (3) automation and tooling, (4) process descriptions, and (5) conventions into a complete implementation structure for the desired specific application type (e.g., REST API with PostgreSQL, event-driven service with Kafka, etc.). Such a Golden Path can then be reused within and across development projects. At adesso, Golden Paths manifest as YAML file artifacts.

A key goal of platform engineering is thus to enhance developer productivity by providing standardized, well-defined Golden Paths for common development workloads, while still allowing flexibility for exceptional cases. This balance of standardization and adaptability helps normalize workflows across teams and supports a more efficient, scalable software delivery process.

Building on these common platform engineering concepts, at adesso we propose aIDPs that deliberately differ in the following ways:

• The aIDP is not developed generically, but rather on a project-specific basis – based on the respective requirements, domain logic, and technical framework conditions.
• A Golden Path is not defined statically, but is dynamic, rule-based, and extensible, e.g., via declarative configurations and an intelligent mapping system.
• The platform uses a dynamic orchestrator that interprets developer requests, selects the appropriate Golden Paths, adapts them, and automatically makes them available.
• Platform engineering is consistently operationalized: from planning and lifecycle management to the rule-based enforcement of standards.

Our technical target model follows the principles of platform engineering, which views platforms not as static infrastructure, but as product-like, domain-specific artifacts.

We begin by describing the context of this work in sec:adesso and discussing the state of the art and related work in sec:related. sec:Architecture presents our aIDP architecture and system components, which serves as our Platform Bill of Materials. sec:Experience reports on observations and lessons learned with the aIDP at adesso. sec:Conclusions concludes the paper with a look a future work.

2. Context: Adesso

adesso is one of the leading IT service and consulting companies in the German-speaking and European regions. With approximately 12,000 employees at more than 60 locations, adesso supports national and international companies in their digital transformation – from conception and software development to the operation of complex IT landscapes. The focus is on combining specialist process knowledge and technological expertise to implement sustainable and future-proof software solutions.

The adaptive Internal Developer Platform (aIDP) is adesso’s solution to the increasing complexity of modern software development. It bundles central development, build, test, and deployment processes in a standardized, automated environment, which is furthermore easy to install and to adapt. Several project-class specific and precisely defined Golden Paths integrate best practices, security guidelines, and architecture specifications into everyday development. This enables development teams to quickly and consistently create production-ready solutions without having to deal extensively with infrastructure or tool chain issues. A key feature of adesso’s aIDP is the integration of artificial intelligence (AI), which supports developers throughout the entire software lifecycle – e.g., through intelligent code completion, automated quality analyses, or anomaly detection during operation. Thanks to its adaptive design, the platform can be flexibly adapted to different technologies, project sizes, and cloud environments. It thus forms the technological basis for efficient, secure, and scalable software development at adesso.

3. State of the Art and Related Work

In modern software development organizations, Internal Developer Platforms (IDPs) [8] are becoming increasingly important for making developers more productive and promoting standardization to improve developer experience [2]. An IDP enables software developers to build, test, and deploy applications quickly, securely, and independently—without requiring deep knowledge of the underlying infrastructure. The IDP combines standardized tools, automation, and best practices in a central self-service portal in the cloud-native era [9].

Platform engineering forms the methodological and organizational basis for building and operating such IDPs. It ensures that the platform remains modular, maintainable, and adaptable – while also functioning in a user-centric way for development teams. Platform engineers develop and maintain the IDP, design Golden Paths, integrate tools such as CI/CD, monitoring, and secrets management – and thus create a reliable product platform that significantly accelerates development processes. The IDP thus offers not only infrastructure components such as Kubernetes, databases, and observability out-of-the-box, but also templates and pipelines structured by Golden Paths that guide developers through complex tasks. For platform engineering, the integration with DevOps pipelines [4] and the cloud-native ecosystem (microservices [6] and Kubernetes [12]) is essential [11].

At first glance, standardization and flexibility may appear to be opposing forces. Standardization reduces complexity, particularly in operations, but can also limit the autonomy of development teams and constrain innovation. Achieving the right balance between the two is essential. Well-designed standards, however, can include defined adaptation points that preserve flexibility where it is most needed. Reference models such as the RM-ODP can support this balance by providing shared viewpoints, or planes, and a common vocabulary, without imposing overly restrictive constraints on design or implementation choices [9].

Although there are already some tools available on the market that are marketed as Internal Developer Platforms, e.g., Backstage [13] and Humanitec [7], these approaches are often static in their provision (once configured templates, inflexible in terms of project-specific requirements, without adaptive components or AI-supported assistance, and separate from organizational development processes. Compared to these platforms or automation systems, our presented concept of adaptive IDPs offers the relevant innovative features, as summarized in Table 1.

4. Our Adaptive Internal Developer Platform Approach

An adaptive Internal Developer Platform (aIDP) is a context-sensitive technical system that adaptively selects, configures, and provides suitable deployment and development paths (Golden Paths) based on environmental parameters, project characteristics, or user interactions. Adaptivity encompasses both rule-based and AI-supported mechanisms and aims to dynamically optimize developer productivity, consistency of the development tool infrastructure, and governance.

Unlike state-of-the-art IDPs, which offer statically configured deployment paths, an aIDP provides a dynamically controllable platform architecture in which project context, or organizational requirements are automatically taken into account. It acts not only as a toolset, but also as an intelligent, adaptive mediation mechanism between infrastructure, governance, and developers.

Our reference architecture shown in Figure 1 illustrates the different layers of our platform – from developer access to infrastructure provisioning. This architecture enables complete separation between development and operational logic while delivering automation, security, and developer productivity. It is the foundation for the use of Golden Paths, which are standardized, pre-tested paths for common use cases. On the top aggregation level, we additionally associate some roles. As usual, one person may fulfill several of the shown roles, and one role may be fulfilled by several people.

Figure 2 shows a typical example adesso aIDP tool architecture, as an instance of the reference architecture in Figure 1. The variability and adaptability of the reference architecture are evident in the selection and modification of specific tools for its various elements. Our aIDP is structurally structured into six planes as detailed below.

Developer Control Plane

The Developer Control Plane forms the primary interaction layer between development teams and the platform. Its central goal is to relieve developers of detailed infrastructure decisions while simultaneously providing a precise entry point for platform rules, governance, and automation. At this layer, developer intentions are captured, structured, and validated, but deliberately not yet implemented technically. User interaction typically occurs via a developer portal (e.g., Backstage [13]), IDE integrations, and APIs. A key design element is workload-centric specification using score [3]. Instead of infrastructure-specific configuration files (e.g., Kubernetes manifests), developers declaratively describe the business and technical requirements of a workload, such as required containers, ports, external resources, or dependencies, as well as contextual parameters like the target environment or compliance level. Score acts as a semantic contract between application development and the platform. The Score specification itself is part of the platform ecosystem and is maintained centrally, while specific score.yaml files are versioned in their respective application repositories. This clear mapping supports traceability, repeatability, and evolutionary development of the platform without destabilizing existing applications. Score acts as input for Golden Path generation in the Integration and Delivery Plane, i.e., for the automatic generation of manifests, pipelines, and Infrastructure-as-Code artifacts.

Integration and Delivery Plane

The integration and deployment plane represents the architectural core of the aIDP. It handles the rule-based transformation of developer intent into a consistent set of executable artifacts and orchestrates their delivery to target environments. This layer determines which golden path to apply in a given context, how it is parameterized, and which additional platform patterns need to be automatically added. The core component is the platform orchestrator. It evaluates workload metadata, project and organizational contexts, and versioned platform rules, and applies a deterministic read-match-create-deploy pattern. This ensures that identical inputs under identical conditions always lead to identical results – an essential prerequisite for auditability and governance.

Resource Plane

The resource plane encompasses the actual infrastructure resources required at application runtime, including compute, storage, database, messaging, and network resources. In the aIDP, this layer is intentionally designed as a deterministic execution layer: It reacts solely to decisions made by upstream layers. This decoupling allows the platform to encapsulate and make interchangeable infrastructure variants, such as different cloud providers or cluster types, while maintaining a stable semantic workload interface. The resource layer thus becomes a controlled execution space that systematically enforces governance requirements, security standards, and operational norms without restricting the autonomy of teams at the intent layer. The resource layer is therefore the only layer at which actual infrastructure states are created or modified. All other layers operate exclusively on logical artifacts.

Observability Plane

The observability plane provides metrics, logging, and tracing as integral components of the platform. Instead of treating observability as a project-specific add-on, the aIDP directly integrates the corresponding mechanisms into the Golden Paths. This ensures that monitoring and analysis functions are configured consistently and varied contextually, for example, through stricter telemetry requirements in production or regulated environments. This layer not only provides operational transparency but also serves as an evidence layer for downstream optimization and learning processes. Thus, observability is not understood as an optional operational tool, but as a structural element of the platform architecture that enables both governance evidence and learning-based system optimization. Uniform metrics and structured logs enable comparable analyses across teams and projects, and form an essential basis for the AI-supported evaluation. This layer provides a central, standardized observability system. Typical components are the three pillars of observability: metrics, logging, and tracing [5,14].

Security Plane

The security plane implements security and compliance requirements as explicit platform rules, thereby operationalizing governance by design. Identity and access management, secret management, policy enforcement, and automated security analytics are not understood as a loose toolchain, but rather as integral components of the golden paths and CI/CD pipelines. This approach makes security requirements reproducible, verifiable, and versionable. Deviations from defined standards can be systematically identified and addressed without having to remake security decisions in every project. The security layer thus acts as an institutionalized decision-making body, enabling technical freedom within clearly defined guidelines. While security and governance rules are enforced deterministically in the aIDP, their application continuously generates new evidence about usage, deviations, and operational experience. This evidence forms the basis for the next layer of the architecture: the AI Plane, which systematically evaluates this information to further enhance the platform’s decision quality, consistency, and learning capability.

AI Plane

The AI/intelligence plane extends the adaptive Internal Developer Platform (aIDP) with mechanisms for context-sensitive interpretation, decision support, and continuous optimization. It specifically addresses those aspects of platform control that cannot be fully represented by static rules or deterministic transformation processes.

Specifically, the AI plane is closely coupled with two central artifacts of the aIDP: (1) the declarative workload specification (e.g., score) as the entry point of the developer intent and (2) the golden path catalog as a structured representation of architectural decision options. The AI plane does not operate in isolation, but rather as part of a closed decision flow:

Developer intent → (AI-supported interpretation & evaluation) → Golden Path selection → deterministic transformation → infrastructure

Within this decision-making process, the AI performs the following functions:

• Semantic interpretation of the intent level The AI transforms natural language inputs into consistent, structured specifications that are compatible with the aIDP metamodel.
• Contextualized selection of Golden Paths By comparing intent, context parameters and historical platform knowledge, the AI supports the selection of suitable decision artifacts from the Golden Path catalog.
• Evaluation and comparison of alternatives The AI can compare several possible golden paths or variants and evaluate them based on defined criteria.
• Feedback into platform development Insights gained from usage and operation are used to systematically develop golden paths, default configurations, and decision rules.

In the area of decision support, AI analyzes declarative specifications (e.g., score files), project and context metadata, and historical usage data. Based on this, it generates suggestions for selecting suitable golden paths, parameterizing configurations, or evaluating alternative architectural variants. Technically, different model classes can be used for this purpose, for example large language models (LLMs) for interpreting natural language and generating structured specifications, classification models for assigning workloads to golden path categories, or regression or ranking models to prioritize suitable variants. Interaction with AI takes place via clearly defined interfaces, such as API-based services (e.g., REST or gRPC), integration into developer portals (e.g., Backstage plugins), or direct IDE integrations to provide support during development.

An important aspect is the potential use of agent-based (agentic) AI approaches. In this context, AI can be understood as a coordinating system that combines several specialized sub-functions, such as analysis of developer intent, comparison with existing Golden Paths, evaluation of alternatives, and the generation of concrete proposals. Such agent-based approaches enable the step-by-step processing of complex requirements without giving the AI direct control over system execution. Instead, it generates structured intermediate results that are integrated into the platform’s deterministic decision flow.

5. Observations and Lessons Learned

The following observations are based on initial applications of the described approach in selected development contexts at adesso. They are qualitative and serve to illustrate possible effects and implications of using Golden Paths, without claiming to be a quantitative evaluation. One initial observed effect is the reduction of decision-making effort in early development phases. By using Golden Paths, the selection and combination of individual technologies is replaced by the use of predefined decision structures. This allows developers to formulate their intentions at a higher level of abstraction, while the platform handles the concrete implementation. The complexity thus shifts from individual decision-making to the definition and maintenance of the underlying decision artifacts.

Another effect is the more consistent consideration of cross-cutting requirements, particularly regarding security, observability, and operational aspects. Since these requirements are an integral part of the Golden Paths, they are no longer interpreted on a project-by-project basis but are systematically incorporated into the resulting implementations. This does not mean that all systems are designed identically, but rather that the underlying decisions are made within a defined framework.

Furthermore, the explicit modeling of architectural decisions enables improved reusability and further development. Adjustments to golden paths—for example, changes to standard configurations or integration patterns—can be made centrally and used in subsequent projects without requiring immediate modifications to existing systems. This supports an incremental evolution of the decision space, where new insights are gradually integrated into the platform.

Another relevant aspect concerns the separation between decision definition and technical implementation. By using golden paths as upstream decision artifacts and their deterministic transformation into concrete infrastructure artifacts, it becomes transparent how specific system configurations come about. This separation makes it possible to analyze, discuss, and, if necessary, adjust decisions independently of their technical realization.

These observations have several implications for the design of Internal Developer Platforms. First, the introduction of Golden Paths as decision artifacts leads to an additional layer of abstraction that does not replace, but rather complements, classic Infrastructure-as-Code approaches. Infrastructure-as-Code remains the means of concrete implementation, but is embedded in a higher-level decision-making process. The observed effects are summarized in Table 2. The effects presented should be understood as initial qualitative observations and require further empirical validation in future work.

6. Conclusions

The increasing heterogeneity of technical requirements in software-based systems is leading to a significant need for platform-side adaptability and structuring logic. In particular, in the context of distributed system architectures, domain-specific development, and regulatory-differentiated environments, configuration spaces are emerging that can no longer be adequately addressed with static platform approaches.

A platform approach is therefore needed that (1) interprets requirements in a context-sensitive manner, (2) varies the implementation based on rules, (3) automatically derives configuration decisions, and (4) guarantees the reusability of proven structures (Golden Paths). The presented adesso aIDP architecture meets these requirements through a novel interaction of declarative interfaces, orchestrated rule processing, and machine-supported configuration logic.

In summary, the combination of declarative intent description, rule-based orchestration, and AI-powered decision support creates a platform architecture that enables both deterministic system execution and machine learning-based development. The clear separation between semantic decision support and deterministic execution ensures that traceability, governance, and technical sovereignty are maintained at all times.