Adobe Ethos: product leadership for an internal developer platform

Situation: fragmented development and operating workflows

Cloud infrastructure supplies compute and storage. An internal developer platform must also answer organisational questions: how a team starts a service, which delivery path it uses, who supports it and who fixes a security finding. Fragmented answers create dependencies between product teams, infrastructure, security and operations.

Ethos connected those concerns for Adobe. The publicly documented model supported both direct platform access and a more standardised delivery path. It served teams across Creative Cloud, Document Cloud and Experience Cloud. The Adobe Tech Blog overview explains that model.

Task: treat the developer workflow as a product

I was Lead PM / Group Product Manager for this developer platform. The case describes the platform and team’s work.

The product question is where standardisation removes repeated work and where teams need control. A useful platform must make routine delivery coherent while retaining service ownership. Adoption, support effort and a developer’s ability to diagnose a failed deployment belong in the same discussion as the infrastructure.

Approach: connect delivery, controls and responsibility

• A complete service workflow: The architecture connects the developer entry point, source control, delivery automation and runtime. Each transition is a product boundary: a team needs to know what happens next, what failed and who can resolve it.
• Security within delivery: Adobe documented hardened base images, build permissions, vulnerability checks, secrets integration and network policies. These controls sit in the delivery process; service teams still own remediation. Adobe’s security walkthrough describes the implementation.
• Ownership below the cloud account: Shared infrastructure can hide the team responsible for a workload. Adobe’s OpSec account describes how service attribution and onboarding validation were added with the Ethos and registry teams, so findings could reach service owners. The Adobe Tech Blog OpSec account explains the problem and response.
• A coherent interface with distributed contributions: An Adobe presentation at PlatformCon describes consolidating internal interfaces and enabling engineers from different teams to contribute. This makes interface consistency and contribution practices part of platform delivery. The PlatformCon presentation documents the work.

Results: shared delivery and identifiable ownership

• Operational platform: The PlatformCon abstract describes the existing multiregion Ethos fleet and the next step toward a broader developer platform. Running infrastructure and expanding its developer experience are distinct stages.
• Consolidated developer experience: The PlatformCon presentation reports moving from six internal web applications to one interface that accepts contributions from across Adobe.
• Actionable security findings: The OpSec case records the attribution work needed to direct findings to the responsible product or service team instead of only the platform provider.

These are published platform and team outcomes. The architecture below reconstructs the documented model; it is not a current inventory of Adobe’s systems. These sources do not provide comparable before-and-after measurements of cost, delivery time or availability.

Lessons for platform investment

• Evaluate the complete journey: A portal is useful only when the route from service creation to incident diagnosis works across the underlying systems.
• Make responsibility explicit: Central execution does not remove application ownership. The service definition needs enough context for support, access and remediation.
• Choose abstractions deliberately: A supported default can reduce decisions, but teams need a clear route for requirements outside it.
• Measure the intended outcome: Onboarding time, delivery friction, support demand and remediation ownership are useful evaluation questions. They are not interchangeable with the number of clusters or portal visits.

These are my conclusions from the operating model. The Adobe Tech Blog IDP workshop report provides further discussion of developer workflows, discoverability and success measures.

Sources and credit

The main source is How Ethos Powers a Cloud-Native Transformation at Adobe, published in the Adobe Tech Blog. The architecture illustration is a new synthesis of public descriptions, not a reproduction of the article’s image.

Additional sources are linked beside the relevant claims. They describe different aspects of the platform; community proposals are not presented as delivered Ethos capabilities.