The #1 Platform Engineering Problem You've Never Heard Of: Platform Decay

Do any of these challenges sound familiar:

Multiple platform projects competing across the organisation
The investment in a “portal” isn’t showing the expected (and necessary) ROI and adoption
There are requests from application teams which have been in a queue for months

If any of these resonate with you, your business is likely suffering from “Platform Decay”.

The goal of every platform team is to enable a true “self-service” environment for their application teams.

However, with the explosion of cloud services and an ever-growing set of infrastructure options, portals have been unable to keep pace, ticket queues have grown longer, and breakaway platform initiatives have emerged.

The effectiveness of past initiatives has become stale and isn’t enough for your organisation to hit its goals.

In this 30-minute webinar, we'll help you take the first step towards identifying and reversing this dilemma. Turning ticket queue waits from months to minutes.

Take back control of your innovation and technology vision statement project timeline by reversing platform decay.

Transcript

1. The #1 Platform Engineering Problem You've Never Heard Of: Platform Decay Abby Bangser Principal Engineer Daniel Bryant Head of Product Marketing
2. tl;dr • Everyone is building a platform; do it intentionally • Platform decay is an issue regardless of organisational maturity • We’ll cover the identification, explanation, and fixes for: ◦ Lack of adoption ◦ Poor ROI ◦ Never-ending migrations • Treat your platform as a product ◦ Everything-as-a service ◦ Process automation ◦ Fleet management
3. Setting the scene
4. Gartner: What is platform engineering? "Platform engineering improves developer experience and productivity by providing self-service capabilities with automated infrastructure operations. It is trending because of its promise to optimise the developer experience and accelerate product teams' delivery customer value." https://www.gartner.com/en/articles/what-is-platform-engineering
5. to fall into ruin: the city's decaying neighborhoods to decline from a sound or prosperous condition: a decaying empire
6. How decay presents for internal platforms • Growing maintenance leading to reduced ROI • Slow adoption • Internal competing implementations • Never-ending migrations • Narrow solutions leave tech behind
7. Let’s dive deeper into the signs of platform decay
8. Lack of adoption
9. https://www.linkedin.com/posts/markwoneill_kubecon-activity-7176562437108682753-RgCi
10. Field of (broken) dreams: If you build it, they may not come How to identify this? • Low adoption/usage • High cost to recruit/onboard new users ◦ Unique feature requests ◦ Narrow use cases showing interest • Poor developer/devex survey data https://www.reddit.com/r/devops/comments/stuep4/weve_spent_months_building_this_platform_devs/
11. Field of (broken) dreams: If you build it, they may not come Lack of adoption (or declining adoption) is a common sign of platform decay Why? • Developers’ needs not understood ◦ Lack of product ownership skills and design thinking ◦ Platform not offered “as-a-service” • Ongoing support not a first class concern ◦ Does not scale with application usage ◦ Lacks day 2 management operations Steps you can take to stop it • Apply product mindset including ◦ Survey developers to identify biggest blockers and pain points (and fix them) ◦ Iterate with small releases to meet needs • Assign a dedicated “enabling” team to onboard teams onto the platform • Market the value provided to existing users
12. Low platform ROI
13. https://www.linkedin.com/posts/markwoneill_kubecon-activity-7176562437108682753-RgCi
14. Platform money pit: The dangers of high cost and low impact How to identify this? • Outcomes are unclear ◦ Lack of platform roadmap ◦ No deliverables for 6+ months ◦ Unattached to company OKRs • Developers using “shadow platforms” • Multiple stakeholders seeking funding to create platforms https://www.reddit.com/r/devops/comments/13dbccy/am_i_a_bad_platform_engineer_or_am_i_just_a_bad/
15. Why? • Project rather than a product implementations • Scoping too low level, trying to create an “internal AWS/GCP/Azure” • Big bang releases resulting in a big bang with expensive cleanup • No clear ownership, budget, roadmap alignment with company and user needs Platform money pit: The dangers of high cost and low impact Platform decay can manifest as low ROI, often caused by high platform maintenance costs Steps you can take to stop it • Apply product mindset including ◦ Identify, scope, and deliver a platform-based fix for one problem/team ◦ Focus on common solutions, allow edge cases to be off platform (for now) • Hold a centralized platform group accountable for extensibility and standardization • Leverage 3rd party tools where you can and build only differentiated components
16. Never-ending platform migration
17. https://twitter.com/morgantepell/status/1782517898017390739
18. Avoiding multiple migrations: Delivering value incrementally How to identify this? • Multiple (large-scale) on-going platform migrations • Platform team spends more than 50% of time on migration-related work • Users are impacted by each migration ◦ Unclear which generation of a solution to use ◦ Documentation contains more than two methods of accomplishing any one platform-related task https://www.gartner.com/smarterwithgartner/6-ways-cloud-migration-costs-go-off-the-rails
19. Why? • Project mindset funds only big bang solutions / migrations • Lack of focus on defining a platform API and providing X-as-a-service • Solutions are not built for day 2 or scaling realities which then require a rebuild • New engineering leaders incentivised to “start afresh” when joining org/dept Avoiding multiple migrations: Delivering value incrementally Managing multiple platform migrations is often a trailing indicator of platform decay Steps you can take to stop it • Apply a product mindset including ◦ Continuous evolution over single release ◦ Plan value driven migrations rather than be forced to complete EOL driven migrations • Enable and hold accountable a centralized platform group ◦ Measure and report on user impact ◦ Ensure fleet management during design ◦ Day 2 operations as a first class concern
20. Wrapping up
21. Conclusion • Everyone is building a platform; do it intentionally • Platform decay is an issue regardless of organisational maturity • We have covered the identification, explanation, and fixes for: ◦ Lack of adoption ◦ Poor ROI ◦ Never-ending migrations • Treat your platform as a product ◦ Everything-as-a service ◦ Process automation ◦ Fleet management
22. Thank you: Additional information Platform Engineering: Orchestrating Applications, Platforms, and Infrastructure (bit.ly/3UNxQei ) How to Take the First Step Towards Self Serve Internal Developer Platforms (bit.ly/4bLMzMD ) Platform Orchestrators: The Missing Middle of Internal Developer Platforms? (bit.ly/3URBoML)