Internal platforms have been a big part of digital enterprise architecture for years now. As technology continues to march forwards and evolve, it’s never been more important for these platforms to grow to meet consumer expectations. 

Whether those consumers are data scientists, engineers, designers, or, of course, developers, internal platforms like IDPs are under constant demand to move beyond the traditional scope of this enterprise technology. 

So what are the key differences between traditional platforms and their modern counterparts, and how can we make sure our platforms are keeping up with the times? 

In July, we were joined by Manuel Pais, co-author of Team Topologies, to learn from his decades of experience working as a developer, tester, and today, an independent IT consultant and trainer. He’s widely recognized as a thought leader in the DevOps sphere, and he helps organizations across the world improve their software delivery and operations. 

Primary goals of modern vs. traditional internal platforms

When internal platforms were first utilized, they were a bit of a mess. Instead of dynamic software, teams had to work with monolithic, ticket-based systems. Whenever developers needed a new asset, they had to send a request, and the team that operated the platform had to manually build that asset to fulfill the request. 

This approach left the consumers of that platform - who are, in this case, software developers - frustrated. As Kaspar, the CEO of Humanitec, states: 

“A lot of the traditional platforms hide everything away, and I see a lot of teams get super frustrated with these platforms. Because they work in 90% of cases, but the 10% drives them crazy. So it restricts the creativity of developers and holds back innovation.” 

With that in mind, modern platforms moved towards goals that focused on utility through reducing cognitive load and providing abstractions that were useful to each specific team. Manuel explains: 

“We’re still trying to provide an easy way of doing things, but there’s more nuance. There’s no one size fits all.” Modern platforms focus more on providing custom solutions for software engineering teams, understanding that reducing cognitive load and improving consumer experience is wholly contextual based on each organization, software product, and team structure. They should provide a golden path that covers most cases, but again, this will be contextual based on the organization and its goals. However, the key thing here is that internal platforms shouldn’t be the be-all and end-all of the development process. 

Instead, internal platforms should allow developers a way to opt out and take a separate path if the platform doesn’t cover their needs. In a modern development environment of “you build it, you run it”, developers need the freedom to work without being restricted by a platform that, despite the best intentions of the team behind it, may not be 100% suitable for every case. 

Kaspar adds: 

“We encourage people to stay on the golden path by giving them certain guarantees. So a lot of the things you can nudge developers in the right direction, but if necessary, they can deviate.” 

As one member of the audience said, it’s about making the right thing to do, the easy thing to do.  

Internal platform consumers

So, how are internal platforms typically used by developers? Manuel says:

“In my experience, traditional platforms are mostly request-based. So, you have a platform team or multiple platform teams that own these shared services, but…[it’s] still based on someone making a request and [waiting] for the platform team to execute something.”

This can easily create bottlenecks where developers are left waiting for separate teams to spin up new environments, creating blocking dependencies where they have to stop work and wait for someone to answer their requests. 

In comparison, modern platforms favor a self-service approach, similar to how many modern companies use SaaS services to automate parts of their workflow. 

However, Manuel adds that organizations can’t have self-service capabilities in a vacuum, and that collaboration is needed to make internal platforms that have useful abstractions and features that developers actually need. 

“If you’re building and running a team, you’re responsible for the service you provide to end customers. But, we need to provide you with the tools - we can’t just say you’re on your own. And that’s the problem, teams are being asked to do so many things without being given the proper help and support from other teams.” 

Kaspar agrees, adding:

“Developer self-service is so powerful because now, the platform team can set rules, documentation, or APIs that help people and balance the trade-off between cognitive load and being able to do everything.”

The main takeaway, which is something Manuel explains in Team Topologies, is that organizations need an ecosystem of teams that support each other. 

Who governs internal platforms?

Perhaps one of the biggest differences between traditional and modern internal platforms comes from the person, or teams, responsible for deciding on new features and services. Here’s what Manuel had to say:

“In traditional platforms, I often see that the CTO or executives have a strong influence. They think about very high-level goals, but that tends to lead to very bloated platforms where we build too much and don’t understand if it’s going to be used. 

There’s nothing wrong with having long-term strategy and goals, but in terms of deciding what we build, that should be with the people who do the work and are going to consume the platform.

So, in modern platform teams, the teams themselves decide and those decisions are informed by what they’re being asked to do.”

This change of governance goes a long way to explain why modern platforms are more dynamic and adaptable to change than their predecessors. While both traditional and modern platforms see inputs from heads of department, platform leads, and other heads of departments as inputs rather than decision-makers, internal platforms need to be governed by people who understand whether the feature they want to build is a common demand. 

Organizations should also look at their platform with the idea of it being a product, not only a tool. Because developers will be working with their internal platform daily, businesses need to be able to “sell” the use of that platform to their software engineering teams. Manuel says a good litmus test for new features is this:

“If I’m going to build this thing, would I buy it from a third party? If the answer is clearly yes, then you can see how it’s providing value internally.”

The takeaway

Internal platforms have a considerable impact on the team, the product, and the organization. While a modern internal platform should be a tool that allows teams to work quickly, it also needs to be treated with the same care and attention as any other customer-facing product.

When organizations treat platforms as a product, collaborate closely with the teams that’ll be implementing them, and employ experienced product managers to govern them, internal platforms create a well-curated experience for software engineers. If you’ve been looking for a game-changing product for your DevOps environment, this is it. 

Thanks again to Manuel Pais for joining us to talk about how to modernize internal platforms. If you’ve not watched the full webinar, you can find the recording here.