Transcript
Kennedy: I’ll be talking about platform engineering, evolution, trends, and future impact on software delivery. My focus is going to be on the paradigm shifts that we are currently seeing, and where we think platform engineering will be growing in the future.
This GIF features Michael Caine from the ’90s classic film, A Muppet Christmas Carol. The film is based on the original book, A Christmas Carol, by Charles Dickens, that was first published in London in 1843. Obviously, at 180 years old, it’s not the most recent book. Although it is still being studied today, my son’s studying this in English right now. You might wonder why I’m mentioning a book that’s from so long ago and how it could possibly be relevant to what I’m talking about.
For those who haven’t read the book or seen any of the film adaptations, the book tells the story of Ebenezer Scrooge, who’s the main character. Scrooge is a grumpy, miserable old man. Some of you might relate to those feelings. I know I do. In the story, he is visited by the ghosts of Christmas: past, present, and future. By the end, he learns some lessons about how he has behaved in the past and his current behavior. He sees a glimpse of how his current behavior might impact his future, which he doesn’t like the look of. He changes his current behavior and ends up becoming someone who is much kinder, much happier, with a much brighter future ahead of him.
I didn’t choose to reference, a Muppet Christmas Carol, just because I love the Muppets. The reason I chose this theme is because the plan for my talk is to talk about the past of platform engineering. How did we get to where we are today? I’m going to look at some present-day patterns and trends that we’re seeing. I’m going to try and make some future predictions of where things might end up in the next decade. My goal is to see if we can learn some lessons from the past and the present and apply them so that we don’t end up with a future that we don’t like the look of, which very nicely echoes the story arc of a Christmas Carol.
Hopefully, that all makes sense now. As well as sharing those thoughts, I’ll be finishing with some key takeaways and calls to action. I’ll be looking at some of the conclusions from the latest State of DevOps Report from the Google DORA Accelerate team, and discussing how using a platform maturity model to assess the current state of your internal platform could help drive your organizational performance. I’ll be describing how building a practice around platform as a product can increase your developer productivity. I’ll be suggesting some steps for how to get started with that. I’ll be highlighting the core principles of platform engineering that are critical to ensure your internal platform is actually delivering value.
Background
My name is Paula Kennedy. I’m the Co-Founder and Chief Operating Officer of a company called Syntasso. We are the makers of Kratix, which is an open-source framework for building internal developer platforms. I’m also a CNCF ambassador, a team topologies advocate, and I organize a bunch of stuff. I’ve been in the field of platform engineering, it feels like forever, but it’s actually been around 12 years.
Why Am I Talking About Platform Engineering?
Let me take you back to London in 2012, which is where a few things happened for me. Firstly, there was the Summer Olympics. You might remember the fantastic opening ceremony where the Queen and James Bond jumped out of a helicopter. More relevant to my story, two things happened to me that focused my career wholly around platform engineering. I spent the first part of 2012 on maternity leave with my daughter, but instead of going back to my previous role at a SaaS company, I chose instead to found a startup called CloudCredo, along with two other co-founders. CloudCredo was focused on providing services and products based on the open-source project, Cloud Foundry. For me, this was the first time I came across the idea of a platform as a service, and it was a huge, steep learning curve for me.
The other thing that happened in 2012 was one of my co-founders, Colin Humphreys, launched the London Platform User Group, also known as LOPUG. I took over organizing that in 2013, but for me, despite having been in technology in London for 10 years before that, this was my first introduction to the London meetup scene and to the open-source community. It’s the first time I really understood the power that exists when enthusiasts and experts come together and share ideas and share knowledge.
The Ghost of Platform Engineering, Past
Now you know a bit about me and my recent past, let’s move on to talking about the past of platform engineering. Here’s our first ghost, the ghost of platform engineering past. I want to start by explaining what I mean when I say platform, because it’s certainly an overloaded term, but it’s not a new word or a new concept. The Oxford English Dictionary defines the word platform as a raised level surface on which people or things can stand. The word’s been around in the English language since the 1500s. In his “Platform Strategy” book, Gregor Hohpe, who’s one of my favorite leaders in this field, he elaborates on this basic definition by describing that a raised platform elevates you. Building on top of a platform means you don’t need to start from scratch, you can build on top of what others have created. Gregor provides a great example of this in his book from a different industry, he looks at the automotive industry.
The example he uses is from Volkswagen in the 1970s, where Volkswagen used a base chassis, which then had multiple different models of car built on top. This allowed Volkswagen to spread the engineering investment costs of the base across multiple models, giving customers a wider range of choice of cars, but without significantly increasing the cost per car as they were able to spread those engineering costs for the base. On top of that, they were then able to innovate on the chassis and on the different models, the different hats independently. It’s clear that the concept of using platforms to increase productivity and innovation is not new.
Let’s explore how this has evolved within the technology sector. I’m going to focus on the evolution that I’ve personally seen in my career over the last 20 years. I joined my first startup in 2002 at a company called Acturis. We were a SaaS provider back in the days when they were called application service providers, the .ASP. We had a very traditional engineering setup with a three-tier architecture for our application. This translated loosely into three engineering teams. We had the developers working on the application code. We had the ops team and sysadmins focused on keeping everything running. We had our DBAs managing our Oracle database. You can imagine, we had a very waterfall-based approach. This was 2002, fairly standard. As anyone knows who’s worked in this type of setup, there were a lot of issues.
All the horror stories people talk about when you’ve got dev and ops being siloed and code being thrown over the wall was exactly as described. Every time we had an outage or an issue, the teams would point fingers at each other. There was a lot of blame to go around, and there was not much empathy. Our releases were batched into huge rollouts that really slowed down our ability to release features to customers. When an issue or an outage happened, everybody would blame each other. Our ops team would then become even more reluctant to roll out a batch. That meant our releases became further spaced out and bigger batches of code. That was my experience for quite a long time.
Luckily, something magical happened in 2008. Patrick Debois met Andrew Clay Shafer at a conference in Canada. Andrew had proposed an open space session called Agile Infrastructure, which he himself then didn’t show up to. Patrick tracked him down and they had a good chat. Patrick had been feeling the same issues that I just described with dev and ops being siloed, and he knew there had to be a better way. He and Andrew had a good chat at this conference. Then Patrick went back to Belgium, and in 2009, he set up the first DevOps Days event in Ghent. That led to this huge community springing up around the term DevOps. There’s a great talk from Damon Edwards where he covers the history of DevOps in more detail. The main points to understand are that DevOps emerged from the community and from practitioners. It was never supposed to be a product, a specification, a job title. It was a grassroots movement.
More recently in 2021, Patrick posted on LinkedIn that his current definition of DevOps is basically everything that happens to overcome the friction created by those silos between dev and ops. What we’ve seen over the last 16 years or so is that this has manifested itself in DevOps teams being formed. We’ve basically just smushed dev and ops together to reduce the silos, and created these DevOps teams that are using that, you build it, you run it mantra, and trying to do everything themselves. One interesting observation is that even to this day, at least according to Wikipedia, there is still no agreed definition for what DevOps is. There are certainly lots of organizations that will sell you some DevOps. Arguments continue about whether DevOps is just automation tools and fast feedback loops, or whether it is a more organizational and cultural shift. Hopefully one thing that we can all agree on is that DevOps has itself been a paradigm shift that has been broadly adopted across our industry and has impacted software delivery.
How has that led to platform engineering? The next step on my career journey has been to experience the rise and some might say fall of PaaS’s, or Platform as a Service. According to Wikipedia, the first ever PaaS was called Zimki, and it was launched by a London-based company in 2005. We saw PaaS emerge around the same time as some other major paradigm shifts such as cloud computing and infrastructure as code. The original intent of PaaS’s was to simplify the writing of code with all infrastructure and operations being handled by the PaaS provider. As I mentioned at the beginning, my personal experience was with Cloud Foundry. Cloud Foundry is a platform as a service that was originally developed by a small team at VMware, led by Derek Collison.
Then it was donated to the Cloud Foundry Foundation in 2014 under the umbrella of the Linux Foundation. After co-founding CloudCredo in 2012, we were actually acquired by Pivotal in 2015. Pivotal was the company that spun out of VMware to very much focus on the distribution that Pivotal had of Cloud Foundry, that was called Pivotal Cloud Foundry. During my time at Pivotal, our head of R&D, the amazing Onsi Fakhouri, came up with the Cloud Foundry Haiku, which was, here is my source code, run it on the cloud for me, I do not care how. This really encapsulated the promise of PaaS and was contradictory to that DevOps mantra of, you build it, you run it.
At this time, I was fully bought in to the value that PaaS could bring to make developers’ lives simpler. Another of my ex-Pivotal colleagues, James Watters, used to talk a lot about the value line framework, where developers should be focusing their efforts above the value line. Really, the point is that developers should focus above the value line. This is where they should be innovating, and they should not be bogged down with the undifferentiated context work, which is the work that has to happen when you’re running a business, but it’s not where you need to innovate. The idea of a PaaS was to help developers stay above the value line, focus on innovating, focus on delivering customer features, and not worry about that context work underneath.
At this time, we weren’t talking about the term cognitive load. It wasn’t in our everyday parlance. Actually, the promise of the PaaS was, developers could reduce their cognitive load by focusing above the value line, and that would actually help that impact that they had when trying to build and run everything themselves, particularly at scale.
This is not quite where we’ve ended up today. The final shift I’ve experienced in my career has been the domination of Kubernetes. It was announced by Google in June 2014, so we’ve been celebrating 10 years of Kubernetes this year. Version 1 was released in July 2015, and it was open-sourced by Google and donated to the Linux Foundation under the stewardship of a new foundation, the Cloud Native Computing Foundation. Kubernetes has become hugely popular as it simplified container orchestration. Over the last 10 years, we’ve seen it everywhere. It’s pretty much ubiquitous. According to the last CNCF survey in 2023, 84% of organizations are using or exploring Kubernetes. One reason for its popularity is just how flexible and extensible it is. There has grown up this huge community and huge ecosystem and landscape of tools and projects all in and around Kubernetes.
Another thing that’s been interesting to observe is that a lot of organizations have taken that technology and have ended up building their own internal PaaS. Kubernetes is powerful, but it’s also complex. We’ve seen many organizations using it, but ending up building their own platform to enable their software developers. We’ve seen companies spend incredible amounts of time and money building their own PaaS. We seem to have lost sight of that value line discussion that I mentioned earlier.
That brings us roughly up to today. To summarize some of the lessons we can learn from the ghost of platform engineering past. Platforms are definitely a force multiplier for an organization. They can increase productivity by allowing teams using platforms to be able to focus more on innovation at the right level. Over the last 20 years, we have seen many paradigm shifts from dev and ops to DevOps to PaaS to Kubernetes. Are these really helping us to deliver software faster and safer, or are we just spinning our wheels? Even when it’s clear that something like a PaaS can provide that great base layer and push developers to work above the value line, we see that individuals and teams still have a strong desire to build things for themselves.
The Ghost of Platform Engineering, Present
Let’s move on to the ghost of platform engineering present. As I’ve mentioned, platforms are not new, and even platforms in our technology sector are not new, but platform engineering as a practice has certainly seen a huge rise in popularity over the last three to four years, as you can see from this extensive research from a Google Search trends graph. Gartner predicts that by 2026, 80% of large software engineering organizations will establish platform engineering teams.
In Gartner’s most recent hype cycle from June of this year, they have put platform engineering at the top of the peak, like the inflated expectations peak, that red circle at the top there, which might give us a warning sign of what’s going to come in the future. What do we understand platforms and platform engineering to mean today? I’ll start with what I consider to be the best definition of a modern platform. This is from Evan Bottcher from 2018. A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support, which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace with reduced coordination. That’s quite a lot of words. Let me try and unpack what some of those things are focused on.
Evan mentions that a platform should be self-service, which means that teams using the platform can be autonomous. They don’t need to rely on other teams to provide tooling or capabilities. They can get what they need when they need it. A platform should include APIs, useful endpoints that are discoverable, and make it easy for tools and services to be connected and work together. My favorite part of the definition is where Evan suggests that a platform should be a compelling internal product. This is the core premise of what we mean when we say platform as a product, which I will dive into further shortly.
In his keynote speech at KubeCon in Salt Lake City, Kasper Borg Nissen talked about the principles of platform engineering. You can see that the concepts highlighted by Evan Bottcher are all listed here, along with a few additions of golden paths, modularity, and core requirements. These principles might seem very familiar to many of you as they are very similar to good software engineering principles. This is where we can see the commonality between platform engineering and software engineering. Each of these principles is basically a paradigm by itself. I’m going to explore a little deeper into what I perceive each of these to mean.
Starting with self-service experience. We see the greatest example of this in the huge explosion in popularity we’ve seen with developer portals. We see tools like Backstage from Spotify, or OpsLevel, or Port, being adopted within organizations to provide a simple user interface to the platform. Developer portals can help with discoverability as users can see what’s available to them to select, and they can get the kind of experience that we’re all used to in our everyday lives. When we’re online shopping or booking a holiday, we click and we expect things to be available instantly. Self-service is not just a nice to have. When it’s done right, it also reduces costs to the business and increases flow of value.
As teams are not waiting on other teams or human intervention, they can request the tools or services that they need and they can get them, so developers are not blocked and they can stay in that flow state for longer. APIs are incredibly important. You’re likely all familiar with the famous Jeff Bezos mandate from 2002, where he told the employees at Amazon, all teams will henceforth expose their data and functionality through service interfaces and anyone who doesn’t will be fired. That’s a bit dramatic. This type of interoperability is critical as our tech stacks have become more complex. A platform should be built with APIs as a first-class citizen, making it flexible and extensible within your organization.
The API is how you expose the functionality of your platform, and it enables other technologies to connect. Your APIs should also be well-documented. I’ve heard one person describe an internal developer platform as just a well-documented API. Humans need to be able to read your documentation and understand your APIs so that they can interface with them. This is where we see the shared responsibility model at play.
The platform team provides the APIs so that the software developers can interact and build on top. These are the boundaries that we see. Golden paths is a concept popularized by Spotify back in 2020. This is the way to create an easy path to production for developers to ship code. Spotify defines golden paths as the opinionated and supported path to build something. It’s a pattern that we’re seeing organizations try to implement. The idea is to make it easy for developers to do the right thing, to choose the supported tools, and follow the recommended processes and guidelines for your organization. As Spotify describes, you can step off the golden path. I’ve heard it described by Mathieu Frenette, who’s at Nesto, as golden paths should not be golden cages. There will always be valid reasons why a particular team or a particular edge case doesn’t fit the defined golden path.
If you can standardize the most common patterns, you will increase flow and productivity and deliver greater business value faster. Modularity is also important. It should be easy to swap components of the platform in and out.
One thing we’ve learned is the only thing that is constant is change. This is something that Gregor talks about in his book. He talks about the floating platform. Your platform should be able to take advantage of new capabilities that are being introduced either by your cloud provider, if they introduce new services, or if you’re running on Kubernetes, maybe new services, new features of Kubernetes, or even just swapping in new tooling, a new database, a new access server. Your platform needs to be able to stay valuable and stay useful by bringing in the new features as they become available. Gregor argues that your platform should be floating, otherwise it’s sinking. A goal of the platform should be to make it possible to swap technologies in and deprecate old ones if necessary, but while still providing a seamless experience for developers.
Core requirements. For me, when I hear core requirements, I think of aspects such as security, compliance, regulation. These are organizational requirements. We need these to be built in to the platform so that they are part of the software development life cycle. This is more of that context work that we saw described in the value line framework. These are important aspects. They are necessary for us to function as a business, but they are not where we want to be spending our innovation budget or our innovation tokens. We just need them to be included. In KubeCon, I hosted a panel which was on the topic of platform engineering and financial services.
One of our panelists, Rachael Wonnacott from Fidelity, she described regulation that her business faces as just an engineering problem. If the financial regulations that she faces can be built into the platform, this removes the need for individual developers to have to worry about them. They are just included. My favorite principle is platform as a product. I gave a talk a few years ago where I described that platform as a product is both as simple and as complicated as applying a product mindset to your internal platform. If you take this literally, you can look at all the teams and activities that are involved when you launch a new product to your end customers. You’ve got user research. You’ve got design. You’ve got sales. You’ve got marketing. You’ve got product management. We know how to do all of these things, but what we don’t see is people applying those same practices to their internal product. I sometimes hear pushback that says, the internal platform isn’t really a product, because people have to use it. They don’t have a choice, so it doesn’t really matter.
Even if that is the case, even if your internal platform is mandatory, it should still be good. If you’re building a platform for your internal colleagues, people who are working with you, don’t we want them to have a good experience? Don’t we want to think about how to make it a good platform for them to use? I’d like to throw one extra pattern in, and that is platform democratization, or as we like to call it in Syntasso, multiplayer mode. With the rise of platform engineering and all of the work needed that I just described, providing a good self-service experience, well-documenting your APIs, constantly evolving the platform to take advantage of the latest things, that’s a lot of work to put on the platform team.
One pattern that we’re starting to see is this inner sourcing pattern, or democratization. It’s a lot to ask for platform engineers to be experts at everything. They can’t know everything about everything, but if you can find a way to have other teams contribute into the platform, to provide services, to provide tooling, provide capabilities, it means that the platform can be the greater than the sum of its parts. It can offer features to all the parts of your organization, but without the platform team having to do everything themselves.
Let’s do a quick reality check. The principles I’ve described sound great. They are a fantastic goal to aspire to, but in my experience right now, reality is a bit of a different place. In a similar way that we’ve seen with DevOps, we are seeing teams being rebranded or rebadged from DevOps teams or from infrastructure teams, and being told, you’re now the platform engineering team. What we’re not necessarily seeing is these teams understanding what platform engineering involves. We don’t see often companies having platform product managers. We don’t see them adopting the product mindset.
As with DevOps, we are certainly seeing a heavy focus on tooling and less on the principles, so we don’t seem to be learning so many lessons from the past so far. Let’s wrap up the lessons from the ghost of platform engineering present. We’ve seen that platform engineering is becoming a popular term, which also means there’s a lot of hype. We’ve seen practitioners and thought leaders starting to agree on some core principles and some core practices of what good platforms and good platform engineering should look like, but we’ve also seen, according to Gartner, that platform engineering is at the peak of inflated expectations, so we might have an inkling of what could come next.
The Ghost of Platform Engineering, Future
That leads us very nicely to what the ghost of platform engineering future is going to tell us. Maybe it should look like that. Let me start with the topic of AI. There’s lots of other folks talking about AI and LLMs, both here at QCon, and the wider world right now. I’m only going to touch on it very briefly. I don’t have a crystal ball about where AI is going to lead us with regards to platform engineering or software engineering, but I think one thing I am confident to predict is that AI is not going anywhere.
One area I think that we will all need to consider is that with developers using AI to help produce application code faster than ever, how will platforms and platform engineering teams manage it? Do we have the right platforms and more importantly the right practices to be able to handle this avalanche of code, safely and securely? I’m going to leave you all to ponder those questions, because I’m going to move on and talk a bit about the latest research from the DORA Accelerate team. Lizzie talked a bit about the DORA reports. DORA, which is now part of Google, has been producing the State of DevOps Report for 10 years. The most recent one came out, and it has some really interesting data around platform engineering that I’m going to share.
The report found that 89% of respondents are using an internal developer platform, and the overall impact of using the platform has been positive, with organizational performance increasing by 6%, and teams and individuals being more productive by 10% and 8% respectively. It seems that Gartner’s prediction of 80% of software organizations having a platform engineering team has already come true two years early, and we could predict that this trend will continue. The report also has some surprising data. It found that internal platforms are not helping with software reliability. They found that software delivery throughput, which is the amalgamation of change lead time, deployment frequency, and failed deployment recovery rate, is actually reduced by 8% where developers are using an internal platform.
The second thing they found was that software delivery stability decreased by 14%, and that’s the combined metrics of change failure rate and rework rate. Why is this the case? Should we just ditch platform engineering altogether? I hope not.
The data is not clear, but I was lucky to hear directly from Nathen Harvey, who leads that DORA team at Google, and is one of the authors of the report. Nathen shared his thoughts on a panel at the Platform Engineering Day that I hosted, and he suggested a few reasons. These are his hypotheses. They’re not proven by fact. They’re just his ideas. He suggested a few reasons as to why we’re seeing these numbers. Firstly, it could be the case that software stability was a pre-existing condition, which bringing in the internal platform just hasn’t helped. That could also be because the goals of the platform were not to fix software reliability. The goal of the platform was to fix some other organizational challenge, such as tech spool, or compliance, or some other issue.
Therefore, the use of the platform and the software stability are not related. The platform was not brought in to fix software stability. It’s just those two things are separate. He also suggested that the internal platform might not be offering good enough feedback to the developers, so it might not have observability or metrics built in. It’s not helping the developers to monitor how their deployments are going. Or that the platform doesn’t have good enough testing tools built in or enough guardrails around testing to encourage developers to actually test their code before being deployed. These are just some hypotheses to consider. I want to throw out a couple of more hypotheses that I have.
Again, these are not proven by any data. These are just some suggestions. This is a call out to the talk from Courtney Nash. Courtney mentioned automation complacency, which Wikipedia defines as us not paying sufficient attention to the output from automation. Not only are we potentially producing more code, thanks to AI, but we might also be trusting that output of the AI code more, and maybe checking the code less. A new term that I came up with following Courtney’s talk is platform complacency. If we’ve been told internally that our internal platform is the new hotness, it might be that we also know the team that built it, then maybe we have more trust that the platform is going to take care of everything and that we can deploy code to it without worrying about it so much. These are just some ideas. I’d love to gather thoughts from people here about what you think or even if you’re seeing these kinds of patterns within your own organization.
Some of these factors could partly be why we are seeing platform engineering potentially heading towards this trough of disillusionment. As with many other trends we’ve seen in the past, we could predict that the hype is outpacing the reality, and organizations do not understand that platform engineering is a more profound change than just renaming your ops team. The DORA report strongly calls out that overall having an internal developer platform has a positive impact on organizational performance, but the key factors for success are having a user-centered approach and driving continuous improvement of the platform. This leads me to my first call to action, which I could summarize as platform as a product. I described earlier that it is as simple and as complicated as applying a product mindset to your internal platform. This is where I feel like everyone is talking about it, but very few organizations are actually doing it.
My prediction is that for those organizations that can get this right, that can really build that internal platform that supports and accelerates their developers, those are the companies that we will see innovate and be the most effective. The most important thing, going right back to the spirit of DevOps from 2008, is to increase collaboration and empathy across teams. My call to action to all of you, whether you are a platform builder inside a company or a consumer of platforms that someone else is building, is to go and find someone on the other side of that divide and just hang out. Maybe grab a coffee, maybe organize a brown bag session, maybe go embed yourself into another team for a day, but try and build some empathy with some folks on the other side of that divide. If we can truly make internal platforms focused on the platform user needs, this will ensure that the platform is a force multiplier for your organization.
This is my second call to action. The thing to think about is how to drive improvement of the platform. For me, the best way to drive improvement is to measure your starting point, identify where you want to get to, making sure it’s aligned with your company’s business goals, and then work out the steps to get there. This slide shows the platform engineering maturity model, which was published by the CNCF at the end of 2023. The authors are very clear to state that all models are wrong, but some are useful. I’m not going to go into too much detail, but you get the idea. There are five aspects, those are the horizontal rows. Then there are four stages of maturity, going from left to right. The idea of this model is not to be optimizing. It’s not to be at level 4 on all aspects. The idea is to understand where you are and work out where you want to be. That might not be optimizing at all levels. The idea is to target where you want to improve and then work out the steps that are right for you and for your team and for your organization.
As DORA states, the best teams are those that achieve elite improvement, not necessarily elite performance. If you’re still wondering whether you can have an impact, I want to share this inspiring quote from the book by Camille Fournier and Ian Nowland, from their book, “Platform Engineering”. They state that the true mark of a platform leader is the ability to turn friction into opportunity, forging ahead to create systems that are greater than the sum of their parts, lead with resilience, empathy, and vision, and you’ll transform skeptics into believers. Platform leader does not mean that you have to have leader or manager in your job title. If you are in a platform team, or if you’re doing the kind of work that feels like you’re building a platform, then you are a leader in platform. You are doing that work day in and day out, and you have the power to listen to others, to build empathy, and to turn skeptics into believers.
Recap
We’ve looked at the latest data from the State of DevOps Report, and we’ve seen that platform engineering increases organizational performance. We’ve covered how focusing on achieving elite improvement, potentially with the use of a model to help measure where you are and where you want to go, can improve your team and drive the best outcomes. We’ve looked at platform as a product, and how being focused on the needs of the platform users can help us potentially avoid falling into that trough of disillusionment.
Questions and Answers
Participant 1: How do we fund the platform engineering team? Is it centralized? Is it something that we do maybe a marketplace, where I can purchase some capabilities? How do we fund that team?
Kennedy: If I go back to the platform maturity model, it’s one of the actual aspects is to look at investment and funding. It depends, obviously. I think one thing we talk to customers about quite a lot is that cross-charging model, and how teams who are using the platform, whether that platform team can charge back for some of the use of services. It’s very context specific, but it’s absolutely a hot topic. If it’s something you’re focused on, there’s a whole platforms working group that’s interesting within the CNCF that’s talking about some of these topics, which you could join.
Participant 2: You talked about platform complacency. I understand it’s really new for you as well, but do you already have some thoughts on how to avoid it? Because indeed, I see it as a real problem, as a platform is really starting to work, as people are coming to it themselves, and then they’re going to trust it far more than they should. How can you avoid that?
Kennedy: For me, I think right now, it’s something to do with that understanding and empathy across the teams. The platform team needs to be able to build trust. We want people to trust the internal platform. We want people to use the internal platform. The platform team also needs to be very clear about the capabilities and about the guardrails. I can imagine that there’s probably some solution around the documentation, the APIs. Being crystal clear of the capabilities, and making sure that the platform team, as part of their platform as a product mindset, that they take a similar approach with publishing their roadmap, or sharing the functionality. That teams using the platform really understand what the platform will do and what the platform won’t do, so that there’s clear boundaries and there’s a clear contract between the users of the platform and the builders of the platform. It’s an interesting topic. I’m really keen to see how that evolves in the next few years.
Participant 3: I got very confused by some of the productivity numbers you shared. It seems like they were saying people rate themselves as being more productive, but the team at Google, DORA, I think that measured it, said throughput actually went down. Then on the slide after, you had some org that said still overall it’s a positive impact. Can you help disambiguate things a bit?
Kennedy: I’d strongly recommend, first of all, to download the report. It’s a lot of pages, but there’s also quite a lot of summary and references. The meat of it is not too long. It’s quite easy to read. I think the thing that DORA identified is that there are different things happening. Like I said, they haven’t drawn strong conclusions as to why.
Overall, companies that have an internal platform are performing better. That’s something that they state. What does performing better look like? It’s an amalgamation of lots of different things. When they look specifically at that software reliability, some of those metrics are worse. They’re not saying that software reliability and having a platform are actually caused together. The easiest thing is to go through and read it. What I found maybe missing is the conclusions. The report just states what the surveyed people answered. It has some hypotheses, but it doesn’t say, this is happening because x. It just came out. I’m interested to go back and talk to more customers, talk to more platform teams, and understand, are they seeing some of those same things or are they not?
See more presentations with transcripts
