# Developer Experience and Platform Architecture
**Renato Losio**: Today we’re going to discuss the architecture of the developer experience — where **product**, **platform**, and **operations** intersect. Our focus will be on **platform architecture**.
Platform architecture doesn’t exist in isolation. It must support collaboration between:
- Product teams
- Operations
- Platform engineering teams
Our challenge as practitioners:
> How do we design systems, platforms, and processes that **reduce cognitive load**, **enable automation**, and **accelerate delivery** across distributed environments?
---
## Meet the Panel
### Renato Losio
Cloud architect and InfoQ editor.
### Martin Reynolds
Field CTO at Harness with 30+ years of experience across industries, programming languages, and cloud providers. Provides a **broad, well-rounded perspective**.
### Ran Isenberg
Principal Software Architect at CyberArk (Platform Engineering division) and AWS Serverless Hero.
- Started platform engineering at CyberArk 6 years ago with 15 people
- Now over 100 engineers serving 1,000+ developers
- Specializes in **serverless architectures**.
### Stephane Di Cesare
Platform Engineer at DKB (German online bank).
Acts as the **interface** between the platform and its users — developers, finance, security, auditors. Previous roles at Accenture and VMware.
### Garima Bajpai
Founder of **DevOps Community of Practice Canada**, Chair of the Continuous Delivery Foundation Ambassador Community.
- Author of *CI/CD Design Patterns* and *Strategizing Continuous Delivery in the Cloud*
- Brings 22 years of R&D experience
- Focused on **community and leadership practices**.
---
## Developer Experience — Definitions & Key Elements
**Renato Losio**: What does *developer experience* mean to you?
**Ran Isenberg**:
- My customers are **internal developers**.
- Engage them early for feedback in **design** and **implementation** stages.
- Prioritize **usability**, **documentation**, **maintainability**, and clear **release notes**.
**Martin Reynolds**:
- Remove friction from building, testing, shipping.
- “Remember the human” — optimize tooling without forgetting the broader human experience.
**Garima Bajpai**:
- Originates from complexity in development ecosystems.
- Stay **people-centric** — your customers are your developers.
- Always remember the **problem you’re solving**.
**Stephane Di Cesare**:
- Developer experience should also consider **non-developer users** (finance, security, auditors).
- Platforms must bring **value** to all user types.
---
## Friction Between Product, Platform, and Operations
**Common Causes:**
- **Siloed tools** per team
- **Manual approval stages** slowing releases
- Multiple tech stacks creating **bottlenecks**
- Lack of shared priorities
- Poor **communication**
**Martin Reynolds**:
- Inconsistencies in delivery processes compound friction.
- The push for speed meets the reality of regulated deployment processes.
**Ran Isenberg**:
- Multiple “golden paths” make straying easy.
- Different stacks make universal solutions harder.
- Platform team becomes a **bottleneck**.
**Stephane Di Cesare**:
- Friction often stems from unclear agreements or capabilities.
- Platforms must **communicate capabilities**, use cases, and limitations clearly.
**Garima Bajpai**:
- Focus on **user inefficiencies** first.
- Automate workflows that **boost productivity**.
---
## Factors Affecting Team Velocity
**Ran Isenberg**:
- Team growth slows onboarding due to needed **best practice training**.
- Supporting additional stacks (e.g., Kubernetes, Java) adds complexity.
- Platform adoption grows slowly; requirements evolve continuously.
---
## Balancing Core Operations vs Innovation
**Martin Reynolds**:
- Automate core operations wherever possible.
- Treat developer experience & platform as **products**:
- Understand user needs.
- Continuously improve tooling.
- Maintain usability & scalability.
**Key Practices**:
- Maintain **roadmaps** and validate with users.
- Balance **golden pipelines** and new features based on capacity.
- Align innovations with business priorities.
---
## Success Metrics for Platform Engineering
**Strong Metrics Include**:
- **Lead Time for Changes**
- **Deployment Frequency**
- **Mean Time to Recovery (MTTR)**
- **Platform Adoption Rates**
- **Operational Cost Efficiency**
- **Developer Satisfaction**
**Ran Isenberg**:
- Automated “Hello World” enterprise-grade service:
- Reduced creation time from 25 weeks to **3 hours**.
- Measure **time** and **success rate**.
**Martin Reynolds**:
- Pair **lead time for change** with **developer satisfaction**.
- Present metrics in **management’s language** (e.g., cost reduction).
**Stephane Di Cesare**:
- Highlight **cost avoidance** — what expenses you prevented.
---
## Self-Service & Internal Developer Portals (IDPs)
**Garima Bajpai**:
- Self-service centralizes tool access, reducing cognitive load.
- Integrate logging, performance monitoring, alerting.
- **Ideal for multi-product teams** with specialized needs.
**Martin Reynolds**:
- IDPs enable self-service, but implement only when they’ll deliver real value.
- Building & maintaining IDPs requires dedicated capacity.
**Best Practice**:
1. Start with high-impact process improvements.
2. Add an IDP as platform maturity grows.
---
## Tailoring Platforms to Business Units
**Stephane Di Cesare**:
- Focus on **shared solutions** that benefit all units.
- Tailoring per unit can work, but maturity matters more than scale.
**Garima Bajpai**:
- Distribute autonomy close to the end user **once governance and standardization are mature**.
**Martin Reynolds**:
- Govern flexible templates for business unit-specific adjustments.
---
## Safe Deviation from Golden Paths
**Ran Isenberg**:
- Require strong justification and align with governance.
- Adapt best practices from existing tech stacks.
**Martin Reynolds**:
- Create flexible templates with open areas for customization.
- Encourage proposals for new architectures/features.
**Garima Bajpai**:
- Balance autonomy with guardrails; watch out for **technical debt**.
**Stephane Di Cesare**:
- Track frequent exceptions and reintegrate them into the platform over time.
- Use a **contribution model** for innovation.
---
## Incrementally Increasing Velocity
**Martin Reynolds**:
- Identify the biggest friction point and **remove it**.
- Even small fixes (saving 30 min/day) compound into major gains.
- Apply **Kaizen**: continuous, incremental changes.
---
## Role of Platform Architects in DevOps
**Garima Bajpai**:
- 70% of issues are people/culture, 20% technology, 10% other.
- Architects bridge platform engineering and DevOps.
- Use platform data to inform DevOps improvements.
---
## Recommended Resources
- **Team Topologies** — Matthew Skelton & Manuel Pais
- **DORA State of DevOps Report**
- *CI/CD Design Patterns* — Garima Bajpai
- AWS re:Invent session CNS361 — Scaling Serverless with Platform Engineering
- FastFlowConf presentation by Toli Apostolidis
---
## Collaboration Best Practices
**Key Actions**:
- **Break down silos** — across dev, sec, ops, prod, finance.
- **Form cross-functional virtual teams** for shared projects.
- **Ongoing dialogue** — constant communication.
- Make **purpose, value, and challenges visible** to other teams.
- Identify **waste**, create blueprints/templates, and share across org.
---
**See more [presentations with transcripts](https://www.infoq.com/transcripts/presentations/)**
