Hello, I'm Robert Kelly, VP of technology enablement at Liatrio. Liatrio is an enterprise technology modernization consultancy. A lot of what we do, or what our team gets to do is, what we traditionally call DevOps app modernization, but. I really like, to think, it's how we describe platform engineering today. I'm really excited to be here with comp 42 today. this is the first time I've given this talk, so I'm absolutely going to be looking for feedback from you and, from others. I'm looking forward to starting the conversation today about all things platform, platform engineering and the challenges we're seeing within large, companies. Enterprise technology organizations. like I said, I'll be starting the discussion here, about why platforms need to be small, no matter how large they are, try to keep it a little bit light hearted. And, I think, going for around 15 minutes here. So let's get going. so what is a platform? I wanted to give my perspective here, maybe set the stage, make sure we're on the same page here, but the platform definition, I'm not trying to redefine anything here. I'll use some of the definitions that are out in the wild today. platform has become overloaded. If we say platform, it may mean one thing to you, may mean something to me, something to someone else. But, we've been building platforms for years, and really lately, over the past few years, we've been trying to give it a lot more, deliberate attention, especially at the enterprise. CNCF platform, white paper says. A platform for cloud native computing is an integrated collection of capabilities defined and presented according to the needs of the platform users. that CNCF platform white paper, check it out. It's awesome. A lot of great folks put a lot of awesome time into that. so check it out. That, paper also says that, it quotes the Martin Fowler's definition of a platform, which I really like. A digital platform is a foundation of self service APIs, tools, services, knowledge, and support, which are arranged as a compelling internal product. I think we're looking at those as the foundational platform definitions for today. And we're going to use that as the, a starting point. I want to take a little bit of a deeper dive there. I want to say. Really, platforms provide abstractions. They are providing, abstractions in a way that they're abstracting away complexity of the underlying systems, processes, allowing its users to interact with a simplified, more accessible interface. really, platforms are giving us, should be, giving us an easier way to do things. the platform is an easy button, right? maybe not. Is it really? So are platforms always a simpler solution? Do they always give us something easier to work with? If I called, the customers of your platform and asked, is platform easy? What would they say? So the point here is if a platform is making something more difficult, then it would be otherwise if the platform or the team who built the platform were not in the way, then we're not helping. Okay, Why is this? Why is this? platforms are disruptive technologies, and this is where I want to spend a little bit of time digging in a little bit, understanding why platforms are disruptive, why I think the disruptive anyway, and what that means. So because platforms are providing automation, golden paths, templates, and other capabilities, the intent is to offer the organization a better way of building and shipping software and digital services. Then if they didn't exist. So the idea here is get the platform out there and provide more value. Okay, but why, why is disruptive technology so important? Why is the idea here? something I want to look at. here's a quote for, from Clayton Christensen's book, the innovators dilemma, products based on disruptive technologies are typically cheaper, simpler, smaller, and frequently more convenient to use. Okay. that might not be the way you describe your platform today, but let's dig in here a little bit. So what I think is important is that we've been building these platforms for years, but maybe we haven't realized that we're innovating or building disruptive technologies. So the challenge is much of the platform technology that's being augmented or abstracted is actually toil, or difficult enterprise processes. The disruptive tech isn't. It's replacing AWS specifically, but it is disrupting the enterprise processes that would otherwise be much more painful for the team's building technology. So that's where most of the value is. Most of the value of the platform is abstracting away those painful enterprise toil or other processes that are just really making it more difficult to deliver software. So platforms have become disruptive. But I think they've become disruptive in the wrong way. Let's talk about that for a moment. So why isn't the platform easy? Why isn't the disruptive technology providing a compelling product for its customers or the platform engineers building the platform? So today, most enterprise platforms have evolved over time to fit the current operating structure of a larger organization. So this is Conway's Law. If you're not familiar with Conway's Law suggests that the way a company or team is structured will heavily influence the architecture or the products or systems it creates. for instance, if an org is divided into three teams that each handle a different part of the project, that final product is likely going to consist of three different modules that reflect the boundaries between those teams. So let's say over time, DevOps team has grown, or maybe it hasn't grown to support the enterprise and the platform has likely grown as well, trying to keep up, the DevOps team might potentially, or maybe even the DevOps org likely owns the tooling and processes to build and deploy enterprise applications and infrastructure. There are potentially hundreds of tools spread out across dozens of automation paths here to build out this platform. And when you hear about cognitive load, platforms have become synonymous with the term tool sprawl. And we're really asking platform teams to become experts in integrating all of the latest tools rather than collaboratively solving business problems. And that's really the goal. And so this path today isn't sustainable. So to summarize this a bit. The platform has had a snowball effect and in many cases become a monolith, just like other enterprise applications. let's take a look at this. let's break it down. Really. if we're looking at the platform as a monolith, it really doesn't have to be a monolith. And this is a bit of an opinionated view that I have here. and I'd like to discuss it further. feel free to reach out. We can talk anytime. When we look at a platform here at a higher level. Where you understand that really it's a sum of several platform capabilities. We've got internal developer portals, CI CD pipelines, security tools, observability, cloud infrastructure, FinOps governance. Now AI ML is growing like crazy. These capabilities vary in complexity in their own areas, really. Today, some, are tools that are purchased, some are built and supported internally. we're just dealing with a lot here, right? So the focus of the platform is really expanding to provide delivery teams what they need to get their products to production. But looking at it as one platform is really where we find some of the challenges now. So looking at it, one platform, here as is really just a lot. So it's really just too much. And it's too much for one, certainly for one team to manage. And if we've got a DevOps team that's grown over time and, and really to support hundreds of tools, it's just unsustainable. So rather than looking at the platform as one big thing for one team or, really even for, Two teams, we should make a conscious decision to break it up and provide a better experience to our enterprise customers. So this is where I say platforms must be small. And let me take a deeper dive here. we can't look at all of the capabilities in this platform as again, a single platform, it's a platform of platforms. And this is where I said, platform is overloaded. How many times have I said platform? It's too many, right? but again, this platform of platform could be supported by several platform teams. Each of those platforms provide important capabilities to its customers, and even though they may need to be on their own product roadmap, how we ask our teams or customers to interact with them shouldn't be distinctly different. And the platform just shouldn't feel large. So for listening. It's all about accessibility when it comes to it. So let's look at that a little bit here. this could be us starting small and we may need to start really small, just like any monolithic, application we might want to break down. We need to treat the platform the same way. A good starting point here is the thinnest viable platform. And this is defined here in the book, Team Topology's awesome book. And, Team Topology states, a TVP is a careful balance between keeping a platform small and ensuring that the platform is helping to accelerate and simplify software delivery for teams building the platform. and to summarize that, we can explain the platform or TVP as the smallest set of APIs, documentation, or tools needed to accelerate teams delivery. And in some cases, version 1. 0 of a platform is just a wiki page. So keeping things very small is super important. this image on the left is not a picture of a platform, but it's a picture of a team interaction model. So this highlights how a platform team is providing a capability of their product as a service for other teams. As the platform might grow, and more features are added, that doesn't mean that the team using the platform need to change the way that they're working to adopt these new capabilities. So self service tools like internal developer platforms and APIs give us a more common platform interface. Things feel the same. It's a standard way to adopt new features. So we get back to having that easy button for customers. and at that point, there is minimal lift to adopt those new capabilities. So the platform feels small, regardless of how much work goes into the platform tooling or automation behind the scenes. To boil it down here, this means breaking up the monolithic platform. It comes down to, we need a strategy and a plan to break it up. there's going to be some work done in value stream mapping, domain driven design, to understand what the platform's boundaries are and how many platforms do we really have. And even though we haven't treated the platform as a product before, we need to make the effort and investment to supply, to support it properly. As platform teams. If we're working with the platform, we need to redefine what it means to own the platform. Probably means raising the bar on platform standards, treating everything as code, really leaning in on APIs and self service, and maybe relearning how we're building applications in our platforms. This means getting real user feedback, understanding who our customers are, and really measuring the use of the platform to find out what metrics are really important there, And things like opening up, inner sourcing and pull requests so that the internal community can, support the app applications and platforms along with the teams, and the platform teams that are traditionally building them and really just finding a more modern working model that, that just works for the organization. So that's a big change, a lot of lift, and a lot to look at once, right? that's it. Thank you. Again, easy, right? No, that it's all I've got today, but I really just wanted to start a conversation and start small and get the discussion started, get some feedback. hope you got a lot from this today and, hope we can, connect, and have a discussion. So again, connect with me, Robert Kelly, DFW on LinkedIn or email robertatleatriot. com. And thanks again.