Digital enterprise architectures have taken advantage of internal platforms for several years now. And as we constantly strive for technological improvement, it’s essential that these platforms are able to adapt with evolving consumer needs.
Internal platforms like IDPs are used throughout multiple industries such as data research, engineering, design, and DevOps. With user demand being so widespread, internal platforms must work to advance beyond the status quo of enterprise technology.
It’s crucial to understand how we can ensure our platforms are keeping up with the times by recognizing the key differences between traditional platforms and their modern counterparts.
In July 2021, we (virtually) sat down with Manuel Pais, co-author of Team Topologies and Kaspar von Grünberg, CEO of Humanitec. Manuel is widely recognized as a thought leader in the DevOps sphere, and he helps organizations globally improve their software and delivery operations. We discussed traditional and modern internal platforms, and he shared his insights from decades of experience as a developer, tester, and independent IT consultant and trainer.
Primary goals of modern and traditional internal platforms
Internal platforms were a bit of a mess when they were initially introduced. Teams had to work with monolithic ticket-based systems instead of dynamic software. Traditional platforms required requests for manually-built assets any time the developers wanted to add something new to the system. As you can imagine, this left the software developers pretty frustrated when they tried to use the platform.
Kaspar, CEO of Humanitec, says, “A lot of the traditional platforms hide everything away, and I see a lot of teams get super frustrated with the 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.”
To streamline development, modern platforms worked to focus on utility by reducing cognitive load and providing abstractions that aided with the unique needs of various teams. Manuel states, “We’re still trying to provide an easy way of doing things, but there’s more nuance. There’s no one size fits all.”
With this in mind, internal platforms shouldn’t be the end-all be-all of the development process. They should offer a golden path that covers most cases, but this will be contextual according to the organization and its goals. Modern platforms focus more on providing custom solutions for software engineering teams, understanding that reducing cognitive load structure, and improving user experience will vary based on every organization, software product, and team structure.
To cater to developers’ needs, internal platforms should enable a way for users to take a separate path if the current system doesn’t meet their needs. Developers need the freedom to work without running into roadblocks within a platform that may not be 100% suitable for every case despire the best intentions of the team behind it. The modern development environment of “you build it, you run it” requires teams to be have flexible systems.
“We encourage people to stay on the golden path by giving them certain guarantees,” Kaspar explains. “So a lot of the things you can nudge developers in the right direction, but if necessary, they can deviate.”
An audience member pointed out that it’s about making the right thing to do the easy thing to do.
Internal platform consumers
When addressing how developers typically use internal platforms, Manuel states, “In my experience, traditional platforms are mostly request-based. So, you have a platform team or multiple platform teams that own these shared service, but it’s still based on someone making a request and waiting for the platform team to execute something.”
But this can easily lead to bottlenecks as developers wait for separate teams to create new environments, creating blocking dependencies where developers have to stop working until someone answers their requests.
On the other hand, modern platforms utilize a self-service approach in the same way many modern companies use SaaS services to automate aspects of their workflow. But Manuel points out that self-service can’t exist in a vacuum and collaboration is necessary for organizations to create 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 and adds that “developer self-service is so powerful because now the platform can set rules, documentation, or APIs that help people and balance the trade-off between cognitive load and being able to do everything.”
As Manuel explains in Team Topologies, organizations need an ecosystem of teams that support each other.
Who should govern internal platforms?
One of the most significant differences between modern and traditional internal platforms lies in the person or team responsible for calling the shots on new features and services. “In traditional platforms, I often see that the CTO or executives have a strong influence,” Manuel states. “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,” he continues. “So, in modern platform teams, the teams themselves decide and those decisions are informed by what they’re being asked to do.”
This shift in governance helps demonstrate how modern platforms are more dynamic and flexible to change than traditional models. Both systems see input from decision-making department leaders, platform leads, and other department leaders who have influence but aren’t decision makers, but internal platforms should be governed by people who can recognize whether a feature they want to build is a common demand.
Manuel also suggests that organizations look at their platform as a product instead of simply a tool. Since developers work with the internal platform every day, companies need to be able to “sell” their software engineering teams on the use of the platform. “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.”
Wrapping Up
Internal platforms affect a company’s team, product, and organization. Although modern internal platforms should work as a tool that enables teams to work more efficiently, it needs to be addressed with the same level of care and attention as any other customer-facing product.
Organizations are able to use internal platforms to create a well-curated experience for software engineers when they treat platforms as a product, collaborate closely with the teams that will be implementing the features, and employ experienced product managers to govern them. If you’ve been searching for a revolutionary product for your DevOps environment, this is it.
Thanks again to Manuel Pais for sharing his time and insights with us.
.webp)
.webp)
