While platform engineering is still an emerging trend, it’s one that organizations of all sizes are starting to pay attention to and adopt. Engineers across a variety of disciplines are increasingly being called to work in dedicated platform teams so that organizations can reap the potential benefits of having their own Internal Developer Platform, or IDP.
However, that’s not to say that IDPs automatically convey those benefits. Without understanding the best practices of platform engineering, having core principles in mind throughout platform development, and having a shared vision for the outcome, IDPs aren’t likely to deliver the same impact.
So, what are the best practices and main principles organizations need to follow? What should organizations do as the industry moves forward with platform engineering? And why do organizations need a shared vision for their internal platform?
To answer these questions, we’re joined by Lee Ditiangkin, Principal Strategy and Business Development for IBM Automation Portfolio at IBM. With over 20 years of experience working in engineering, product, and operations management, and 10 years of experience building and managing internal platforms, Lee shares his insights into building a shared vision for platform success.
Platforms as a product
The role of a developer is to create and release software features for the end customer. However, developing a product isn’t a linear path from developer to customer.
Larger organizations in particular tend to have multiple engineering disciplines that sit between the developer and the customer. Products created by developers have to travel through tools and engineering, release ops, sec ops, SRE, and any number of other engineering disciplines before they’re released to the customer. As internal platforms are becoming a bigger industry trend, organizations are increasingly consolidating these other engineering disciplines around platform engineering.
With these engineering disciplines focused on building the toolchain and providing a service to developers, organizations now have two sets of customers. There’s the external customer that purchases the end product, and the internal stakeholder that uses the internal platform developed by platform engineering teams.
In practice, this means organizations need to be concerned about more than just how customers interact with their products at scale. They also need to ensure that their developers can get through all of the different layers of engineering to ensure that they can release on time. Lee explains:
“When I was working on this at Apple, our perspective was that it was about more than just the customer. It was about everyone and everything else. Platform engineering really becomes the glue of these development organizations at scale.”
As with any product, organizations need their customers to trust that the platform will meet their needs. Part of this is figuring out the balance between what internal stakeholders need and how that will affect the end customer. This balance should make it easier for developers to focus on the future while having the tools they need to deliver high-quality code on schedule. It will take time for developers to trust the product, as Lee says:
“They need time to experiment to see if it’s better. If it’s not better then they’ll move on. In my experience, you need to meet each other eye to eye and decide if you’re both willing to experiment with new things. Concerns around limitations, or being told what to do, are barriers to entry.”
Internal marketing for platforms is a key part of working with this product mindset. Just as companies would with any other product, platform teams should be building conversion pipelines, taking on customer feedback, and using that information to inform development. Organizations need to ask developers what features they want to see and create a balance between developing for customers that like the product and for customers that don’t. This is key for ensuring internal support, especially at the executive level.
Platform engineering goals and outcomes
The availability of tools in modern development far outstrips what was available in the early 2000s. While this increase in innovation undoubtedly meant that organizations could build powerful toolchains, it’s also meant that there’s been a significant increase in complexity.
With so many tools on the market, one of the first goals of platform engineering should be to ensure that toolchains are flexible and reusable regardless of what tools are being used. Lee says:
“You need to observe patterns in your IDP to see what services are used for what application, and then you can build the flexibility to hot-swap things in the future. For example, Sneak might be hot right now, but in five years' time, there might be something new, and I want to be able to swap to that. You can’t always stay with one tool for 20 years.”
Secondly, platform engineering needs to use data and KPIs to have observability over the development pipeline. Organizations need to be able to see how long it takes engineers to fix bugs or manage infrastructure, as this gives them the information they need to fully develop the platform. Lee adds:
“You want to see what people are using and where they’re going, so we can understand if we want them to stay on that route or if we want to add more abstraction. But you need to understand user behavior and what patterns your KPIs demonstrate to understand what to do next. You need to measure everything to understand that.”
The final goal of any platform engineering team should be to offer a valuable level of abstraction. This needs to give internal stakeholders one central point to go to that allows them to manage their toolchain without needing to worry about underlying code or processes. As Lee puts it, “The beauty of platform engineering is that centralizing all of these practices means all the other stuff becomes really easy to use.” This is the end goal of platform engineering - to improve the developer experience by abstracting cognitive load.
The future of platform engineering
As platform engineering continues to take hold in organizations large and small, the industry is seeing a range of communities come together to improve the practice. With events like PlatformCon and other conventions for engineering disciplines like DevOps and SRE, it gives engineers the chance to learn from each other as these disciplines mature.
Part of this is building a culture that appreciates the value of change and adaptability. There will always be events outside of the control of platform engineers. What matters is that platform engineering continues to adapt to work with new technologies and new ideas from a product-focused mindset.
As a new generation of engineers enter the workforce, having an adaptable product-focused mindset will drive the platform engineering discipline forwards. Lee explains:
“If you look at the new generation we’re hiring, they all want to build a startup. So we looked at it as building a culture where they could experience building a startup in the safety of a big company like Apple. We’d take in anyone with an interest in engineering and train them for six months before putting them on the team. I told them that sure, there was a good chance they’d leave the team within 1-2 years, but in that time they’d learn how to build a product, and hopefully learn enough for them to build their own startup.”
Finally, developing a shared vision is a vital part of developing a well-balanced, valuable IDP. Lee talks about his experience of shared product ownership over a platform:
“There were three of us who owned the platform. One person couldn’t roll out anything that any of the others didn’t want to use. Once, we tried to roll out a caching layer, but one of the owners didn’t want it because it wouldn’t add value to his team. We really had to align on everything, and we did that by having data they could trust to back up what we wanted to do.”
By having a shared vision for what a platform needs to achieve, engineers can ensure they’re working towards building features that add value, rather than working towards “vanity DevOps”.
Thanks again to Lee Ditiangkin for joining us in this enlightening discussion around platform engineering, its evolution, and how we should rethink our need for control as this discipline continues to evolve. If you haven’t watched the webinar yet, make sure to watch the recording for the full story.
.webp)
.avif)
