US 2021
Crossing the Platform Gap
Teams delivering high quality experiences to customers are critical to your business and they need to be as productive, efficient and supported as possible. But with multiple teams in your organisation with differing requirements, how do you balance flexibility with complexity and support a platform that provides the tools required on-demand, whilst also minimising duplication and cognitive load?
In this talk, Paula will describe this “Platform Gap” challenge that many organisations face and provide recommendations on how to solve this by reviewing and improving team interactions. She will explain how your internal platform can be used to support this model whilst still focusing on delivering a delightful experience to the users of the platform through applying product management practices.
PK
Paula Kennedy
Chief Operating Officer, Syntasso
Transcript
Hi there and welcome to my talk, crossing the platform gap. Thank you to the DevOps enterprise team for having me. And thank you for watching. I'd like to start with a brief introduction. My name is Paula Kennedy. I recently co-founded a company called Cintas. So with a great team of colleagues, I've worked in the technology industry for more than 20 years, 10 years in software as a service. And then for the last 10 years, I focused in the platform space most recently, working at pivotal and later, as part of VMware, working with customers who are running large internal platforms. So what will I be talking about? I'm going to describe the platform gap, the challenge that my team and I have seen at many companies we've worked within the past and which might sound familiar to some of you in the audience. I'll explain it in terms of why you should worry about it.
I'll make some suggestions of things that you could do about it. I'll also be providing some examples where customers have made significant progress in solving some of these challenges. And then hopefully I'll leave you with some things to think about going forward. So what is the platform gap? Okay. Let's say you have a team. We'll call them team a, they are responsible for a product. Let's say it's a mobile banking application. And because you're following the DevOps principle of you build it, you run it. This team is managing their own Kubernetes clusters. They're also managing a database. Let's say they've got some machine learning in there as part of the stack. And then finally they're using K native and Quebec for their application. Now, if you're a slightly bigger team, maybe you've got a separate team. B team B might be responsible for a mortgage calculator.
And let's say that their stack is similar to TMA, but in this case, they have a CRM tool as part of the stack. And then as a big of organization, you might also have TMC. The TMC might be taking care of credit cards and their stack looks very similar to DNA, but they've got things configured just slightly differently. Maybe they're running some different software versions. And then finally you have team D have running the legacy payment system, which is running on bare metal on premises. Looks very different to the other teams, but it's still a core part of your business. And maybe you've got hundreds of other similar, but separate teams. Maybe your organization has made acquisitions in the past. And you've got lots of separate teams doing similar things, but not working together. This is what it looks like when you've got a platform gap.
Each team is juggling all of the components of the stack themselves. They've all got to cross this gap going from infrastructure to actually delivering value, to end customers with the applications. And what are the implications of this platform gap. There's several problems with this model. The first thing to notice is the cognitive load on each team. Now cognitive load is a term found in the field of psychology and is defined as the amount of information that working memory can hold. At one time. In this case, we can see the team a is managing quite a lot. And the more things that they're managing, the more information they have to remember about each part of the stack and the less they are focused on the actual application that is delivering value to the business. That was my old colleague, James Waters used to say, the application team should be focused on delivering business value above the value line.
The value line can be defined as separating what's core to your business versus what you can and should outsource. Now, in this case, we mean it to say that what is the core specialism of this application team? What should they be focused on instead of also trying to wire all of these infrastructure elements together, and because this team has high cognitive load and reduced Headspace to focus on the application, this could be having lots of impacts. This could be reducing the speed of which they can react to customer feedback that reducing the speed to which they can add new features, what to iterate. What's a patch and keep them application secure. And generally they're maybe not keeping up with your competition.
And if you look across the business, you've got all of these teams, all facing those same cognitive, low challenges slowing down the whole organization. And it's, it's clear when you look at this diagram that there's lots of duplication and wasted effort. If we remove team D and their bespoke stack from the visual, you can see that across each team, there were common items in their stacks where your organization could be pooling resources to save time and effort and money by sharing these services, your organization could benefit from economies of scope, which can be defined as the average total cost of a company's production decreases. When there was an increasing variety of goods produced. In this case, it means that if some of these common parts of the stack could be grouped together and shared the cost to add new teams and new products would be incrementally lower, thus reducing the average cost per business application.
Now in this model, what's happening with team communication and collaboration. We can see, it looks like the teams are working in silos. There's some pretty thick brick walls between them. And if this is the case, then they're not working together. They're not sharing best practices or knowledge or skills. You might have multiple people across the organization struggling to solve the same problems without any shared learning or pooling of resources. What are the rules of engagement between these teams? How should they, or could they even work together? Maybe there are other hidden elements that your broader organization is not aware of. That could be pieces within the stack of each team that are hidden in the murky world of shadow it. Teams could be using tools that don't meet internal governance or compliance requirements, which could possibly believe into security risks. Maybe one team is using the next greatest tool, which would massively benefit 10 other teams. If only they could access the service without themselves having to take on the extra cognitive load. So what does all of this mean to summarize, as in TASA, we define the platform gap as the chasm ETE must cross between the infrastructure and delivering their meaningful product value. By having this platform gap you're facing issues such as high cognitive load on each team, duplication and waste team silos with little or no collaboration, potentially shadow it, and also potential security compliance gaps, generally just a nightmare all over the business to audit what's going on.
And aside from our teams, combined years of experience, working with customers, who've experienced some or all of these issues. Is there any other data out there? There was a recent report from Dynatrace where they surveyed globally 700 CEOs in large organizations with over 1000 employees across multiple countries. In this report, it found that out of the 700 CEOs who responded nearly half say that their it teams are stretched more thinly than ever. So you can imagine the cognitive load on those teams, half of the CEOs say that their business and it teams work in silos 40%. So that limited collaboration is disrupting its ability to respond to change. And three quarters say that they are fed up having to piece together data from multiple tools to assess the impact of it investments. So you can imagine what type of spool of technology those CIO is must be dealing with.
So with all of these platform gap issues within these large scale organizations, how can we go about attempting to cross this platform gap? Well, with all good questions, there's no easy answers, but it really comes down to two areas of focus at an organizational level, what changes should be made. And then, because this is the platform gap, I've got a specific focus on at the platform team level with regards to platform, team structure, and practices. So let's look at organizational level first and a great place to start is with team topologies, which has an excellent book published in 2019 by Matthew skeleton and manual pace. This is a photograph of my copy of the book. The book itself covers for team types or typologies and three interaction modes. And it was heavily featured in this year state of DevOps report. It's an excellent book. And one of the key benefits is that it provides a common vocabulary for people across your business to understand organizational models and team interactions, which can help to increase understanding and therefore flow of change across the business. Now, to answer the questions around platform gap, I'm going to focus on just some specific parts of their model, but I would strongly recommend to go read this book because it's absolutely fantastic. So the parts that I'm going to focus on is just two, if the three interaction modes, which are collaboration defined within teams, apologies as teams working together, three defined period to discover new things and X as a service to find us one team provides one team consumes something as a service, for example, an API.
Secondly, on the team types, I'm focused specifically on two out of the four stream aligned teams, define those, a team aligned to the main flow of business change with a cross-functional skills mix. This is often synonymous with an application team, such as the teams, ABC, that we looked at earlier and then platform team defined us a team that works on the underlying platform, providing a compelling internal product to accelerate delivery by stream align teams. So it's within these two areas that I've focused heavily in the last few years, but what have I been doing and why do I view it as so critical for success of companies? The pattern that my team and I have been encouraging customers for a number of years now is to start with collaboration. This could be described as a period of discovery or user research where the platform team needs to work with the stream aligned teams to understand and define the requirements.
This collaboration requires provides a shared responsibility for both teams and allows the teams to increase their knowledge, that understanding and have empathy for each other's needs. Now, whilst collaboration is critical upfront to define the boundaries of the services that the platform will be providing. It's not just an upfront activity. It's also useful to maintain just a lightweight, ongoing collaboration. This is to ensure that the platform continues to deliver value as needs can change tools can change. Technology can change. The one constant we have is change. So the next step once requirements are understood through collaboration is to move to an X as a service mode. This sets clear responsibilities between teams reduces friction and reduces communication challenges. It enables faster delivery as the stream aligned team has autonomy to self-serve the services that they need on demand whenever they need them. Particularly if the platform team can make their service easy to consume.
So we can understand that the problems we previously looked at in the definition of platform gap, these can begin to be tackled. If we have a platform team supporting the application teams, providing the services that those teams need. And if those teams have clearly defined interaction modes. Now I mentioned earlier that the platform team is defined as a team that works on the underlying platform. But what do I mean when I say platform, am I talking about one specific type of technology back in March, 2018, Evan Botcher wrote this great article, which contained this definition of platform. Digital platform is a foundation of self-service API 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. So you can see this definition is technology agnostic.
It doesn't mention any specific type of technology, whether it's a curated set of tools and services, which are arranged together as an internal product, which leads to the second part of how to tackle the platform gap. And that is specifically at the platform level and the set of activities that the platform teams should be doing as part of delivering their platform and making it easy to consume this specific set of activities that we have seen drive real success within organizations can be grouped under the heading platform as a product at its very simplest. This means taking everything that you consider for external products that you build and applying that same product mindset and same set of practices to your internal platform, to give you some concrete examples, it can look something like this. So here's my platform team down the bottom of this slide. Firstly, the platform team needs to understand who their customers are.
Now, if we go back to the original organization model that I had, it would look something like this. You can see that you've got teams, ABC working on their applications and those teams are the customers for the platform team. Now the platform team needs to treat those people like that. Customers there might be developers, product managers, designers in those application teams. Those people are the customers for the platform team. And the first thing to understand is what are your customer needs? And to figure that out, we need to use collaboration. So this could look like user interviews could be a journey mapping, exercise. It's really any mechanism that you can use to discover and understand the customer requirements. And then it takes you to be able to figure out how you might go about meeting those requirements and delivering value.
Once those requirements are defined, the platform team needs to start building the platform that set of services that they've identified that their customers need. Now again, the practices that the platform team should follow those development practices should really be similar to other product teams. They should be building in small batches seeking user feedback early and often checking that the requirements are still valid and making sure that they're minimizing risk along the way of the build process. At this point, it would be very beneficial to have a product manager for the platform. Someone who can outline a clear product, vision, and roadmap who can play our ties, the backlog in response to user needs. I could support external stakeholders.
Once the platform has a service that's ready to be used by a customer. We know that the next step forward is to move to the X as a service mode. This means providing a method by which the customer can access the service on demand without having to have any communication or intervention by the platform team. This could look like an API provided to the development team or a developer portal, some, some way to make the platform easy to consume and self-serve, and as mentioned earlier, there needs to be ongoing, lightweight collaboration, maybe a check-in on a regular basis to ensure that the platform is continuing to meet user needs because as needs change, the platform needs to develop and adapt. And as well as this core set of processes, that the application that the platform team should be following, there were other steps. A platform team can take to really drive value for their platform and deliver to the rest of the business.
One part of the platform definition from Evan Botcher stated that the platform should be a compelling internal product, meaning that the application teams should want to use it. Not it shouldn't be mandatory for them. They should be excited to use it. And the platform itself should be the easiest path for teams to get their applications to production. This could look like lots of different things. It could look like evangelizing the platform, maybe branding it, giving it a cool name and marketing it internally, such that teams get curious and excited to try it out. Maybe it looks like including inside of your platform, the specific security and compliance requirements that are specific for your business, build those in to the platform. So that teams know if they're running their applications on your platform, then it will meet the requirements of security and compliance. And it means there'll be fewer hurdles for them to worry about than if they were trying to run this themselves.
It could look like your internal platform provides a specific bespoke tool as a service to your teams, but something that's an internal tool, something that they couldn't get from a cloud provider or an external vendor, it would give your platform a competitive advantage. And maybe you want to be focusing on developer experience, sunshine and rainbows for your developers, making sure that your platform has a nice developer experience, but basically that it's as easy to consume as possible. And it's delightful for developers to use all of these steps. Combined could lead your internal platform to being easy to use, which would lead to it. Being adopted by multiple teams, you'd have reduced cognitive load on each team, which would free up developers time. And this platform would fit the exact requirements of your business. And through the lightweight collaboration model, the platform can continue to remain up-to-date and secure and relevant.
And your platform team through this collaboration can ensure that if more tools get added in or more services get added in, they can remove services that are no longer being used. They can standardize. And you end up with a platform that is fit for purpose and being used across your business. Now, at this point you might be asking, how do we know this to be true? Uh, or what does good look like? Well, let's take a look at this year. State of DevOps report. It states that highly evolved firms use a combination of streamlined teams and platform teams as the most effective way to manage cognitive load. At scale, these highly evolved firms strive to create a compelling value proposition for application teams that is easier and more cost effective than building their own solutions and internal platform. In nearly all cases, isn't something you can buy outright.
It's something that's built and tailored to the needs of your technology organization. And finally, not every platform team is automatically successful, but the successful ones treat their platform as a product. And aside from this excellent research, there are plenty of publicly available case studies where organizations that I've worked with in the past have talked about the successes they have had in 2019. I spoke at spring one platform conference in Austin, and I shared just a few statistics of some customers we had worked with in the past who saw huge improvements in their flow of change. By implementing some of these practices, we had one customer who was able to support 1500 developers, which is four operators. We had one customer who was able to over the course of just 10 months scale their platform to support 20 nineteens across four countries and also increase their deployment frequency.
By more than three X, we had one customer who saw a 90% improvement in release velocity from around 30 days to two to three days to release. And finally, we saw one customer have an 89% reduction in security patching lead time from 45 days to five days. So it was clear that for these customers, the work of introducing a central platform team and implementing some of these practices significantly benefited them in several ways. So to summarize how to tackle the platform gap, we need to organize teams for fast flow, specifically, ensuring we have a dedicated platform team begin the learning process through collaboration and then drive towards the platform meeting those user needs as a set of services available on demand. We need to take everything we've learned from product management of external products and apply those same practices to the internal platform. And we need to understand that driving the full value out of the platform means treating it as a product to be maintained.
It's not built and finished. It needs to be maintained, improved, and developed over time to ensure it remains relevant and fit for purpose. So what's next. That's fantastic. We're really keen to continue this conversation with other folks in the community. And we would love to collaborate with you. You can find us at our website. We would love to hear stories of similar pains that you felt. And we'd love to answer questions. We've also been working on a tool, put politics, which has a framework for enabling platforms, basically enables a contract between platform and streamlined teams to be codafide. It's very early in the project. We only released mid September and it's still in beta. So if anyone would like to play with it, it's available and get hub. We'd love to collaborate. Please take a look and let us know what you think. And if you would like to provide feedback on the tool or on this topic, please feel free to email us@feedbackatsometasks.io or message me on Twitter. Finally, I would like to say thank you very much for listening and I hope you have a wonderful rest of the DevOps enterprise summit conference. Thank you.