Internal platforms can tie organizations together by normalizing tasks and practices, but not every platform is a resounding success. Those that prevail tend to be more robust, allowing them to better accommodate distinct user skill levels, workflows, and needs – even as the motivating requirements evolve.
In this talk, OpenCredo CEO/CTO Nicki Watt explains what goes into building a truly robust internal software ecosystem that satisfies the needs of multiple engineering teams. She then highlights some of the fundamental aspects enterprises ought to consider as well as the organizational practices, soft skills, and other factors that serve as pillars of the platform engineering discipline.
Nicki also draws on her first-hand experiences working with diverse clients and different setups to explore a critical objective for any platform development team: Building a platform fit to serve the communities that ultimately use it.
Here's what to know if you'd rather not watch the video.
How not to build a robust platform
OpenCredo is a development consultancy that helps companies enhance the efficacy of their software delivery practices. While it advises businesses in a variety of areas, its focus on platform engineering gives it a unique perspective on the struggles involved in achieving true robustness.
Focusing on tooling instead of tool users
The first insight Nicki shares from her time spent guiding companies towards better platform practices is that it's easy to overlook the broader human experience. In their push to adopt novel technologies, many companies forget about the developer experience. They fail to see the innovators whose hard work drives progress for the shiny new innovations that make platform implementations seem so attractive.
So what's the solution to this critical oversight? Nicki advises against the common tactic of thinking of the problem as a Venn diagram – whose sets are the platform, your people, and sufficient process to keep everyone happy. Although finding the intersection might seem like it'd make for a “super platform,” things are never so simple in practice.
The issue, says Nicki, is that real-life target communities are way more complex. Different platform users come with distinct skill sets and requirements, which may be more or less involved depending on typical use cases: There's no happy medium guaranteed to satisfy them all.
It's easy to imagine where this sort of thinking might fall short if you just consider who tends to build internal platforms: platform infrastructure engineers. It's no secret that these teams tend to have an advanced understanding of concepts like infrastructure-as-code and containerization, but organizations commonly make the mistake of expecting other user groups to be able to operate at the same level. This can result in inappropriately low-level functionality, such as Kubernetes controls, being exposed to end-users who really shouldn't have to bother with such details.
Also, remember that skilled user communities are quite diverse. For instance, even though development teams are typically the primary platform users, they're not the only technologically proficient groups you might need to consider. Your company's developer platform might also cater to data scientists, machine learning engineers, and others who fall outside the classically defined DevOps category.
Each of these groups brings its own unique set of requirements to the table, such as needing versionable data or the ability to take part in leadership and governance tasks. Although diverse communities interact with platforms in different ways, they all share a common need to understand how your tool offers a return on the effort they invested into using it. In other words, practices like reporting and publishing usage statistics ought to include targeted communication that caters to users from all walks of life.
Thinking of technology as a cure-all
Nicki says the single biggest misconception she encounters is the idea that technology can solve the platform robustness challenge by itself. Although she admits that effective technical implementations are of critical importance, she maintains that practices such as automating and creating abstraction for different groups aren't enough.
Many OpenCredo clients built platforms only to discover that the teams meant to use them simply didn't. As Nicki aptly describes it, these companies fall into the trap of relying on what she calls the misquoted Field of Dreams movie principle. In other words, they put their faith in the classic line "If you build it, they will come" – but no one actually comes.
The fact that this problem manifests so often proves that technology alone is an insufficient justification for team buy-in. Platform leaders and architects must go further, taking a purposeful, proactive approach to driving engagement that prioritizes gradually shifting their communities towards adoption.
Nicki says this typically involves reconsidering how teams interact with platforms and each other. Enterprises have to take a hard look at finding different ways of engaging and accommodating teams and communities to bring their organizations closer to ideal usage modes.
Failing to account for evolution
Nicki says it's natural for organizations to assume that requirements and other factors are static. This lends itself to the mistaken idea that freshly implemented processes will automatically prove adequate to meet user needs.
Once again, reality holds a painful lesson for those who fall prey to this misconception. Not only do requirements change, but also staff experience levels and team structures undergo continuous evolution. Governance practices and platform processes that take one-size-fits-all approaches rarely pan out.
Nicki highlights the point that building a good internal developer platform requires viewing the problem as a holistic socio-technical challenge. You'll need to assess both the technical and social dimensions of implementing, maintaining, and using a platform with the understanding that these factors are highly entangled. Each aspect is mutually interdependent, and what you do in one area can easily affect other domains, not to mention the whole.
The hallmarks of platform success
Next, Nicki shifts the discourse to solutions by listing some of the characteristics her team usually observes in successful platform endeavors – as well as a few of the principles that tie them together.
Boundaries are set explicitly
According to experts like Nicki, successful platform experiences usually establish clear boundaries and responsibilities. They make it obvious what the platform does, which helps devs get a better feel for how their work aligns with – or misses the mark on – what the teams are using the platform to accomplish.
Without setting clear boundaries and responsibilities, companies can end up creating unproductive blame games. Cultivating an understanding of roles, responsibilities, and expectations can foster effective collaboration to make teams better informed. It enlightens them on how to be not only effective contributors but also good platform citizens.
Features focus on self-service
Self-service capability ranks as the leading must-have for OpenCredo's clients. Organizations want platforms that let users achieve tasks autonomously, and they favor processes that automate as much of the legwork as possible.
Self-service gives users the tools and capability to achieve their goals independently, moving as quickly or slowly as they deem fit. It lets teams decide their destinies, whether they choose to do so via the use of APIs, processes, or documentation.
Technologies and processes evolve freely
An internal platform needs to be sufficiently opinionated to ensure order, but it also has to be tailored to adapt to diverse user communities. If it doesn't accommodate deviation, it just becomes a bottleneck.
Once again, Nicki stresses that you can't hope to flourish with a one-size-fits-all solution. You also need to ensure that your platform achieves optimal reliability as the requirements, KPIs, and other factors that define success change. For instance, if your platform makes guarantees about its auto-scaling capacity yet fails to perform under fire, teams, management, and other users will lose confidence, and people simply won't use it – no matter how strongly you present your case.
Four community-driven principles for platform success
Finally, Nicki advises letting your platform development be guided by what the OpenCredo team calls its four basic community-driven principles. Keeping these concepts in mind can be an effective way to devise practical solutions and abstract approaches to problem-solving.
1. Make teams independent of and not dependent on you
Teams will depend on platform devs to some extent – After all, they have to use the software you build! What you're trying to avoid is ending up in a situation where users require your expertise or intervention every time they need to accomplish a task.
2. Promote freedom over autonomy
Provide freedom – within boundaries. Set clear rules to allow freedom of choice regarding things like technology choices and implementations, but don't create a total free-for-all that might result in a bad community experience for any users.
3. Focus on soft skills
Be a role model by practicing what you preach. If you're going to ask people to use your custom tooling, then you should be doing the same. This is the quickest way to verify that your solutions work and hold your team accountable for fixing those that don't.
4. Respect and recognize community differences
Understanding what differentiates your communities improves your odds of catering to them all. Nicki recommends checking out the book Team Topologies by Manuel Pais and Matthew Skelton to understand more about how your teams interact and how their structure impacts their ability to build a thriving platform. (You can also watch Manuel's PlatformCon talk where he addresses some of these issues!)
As is often the case with these sessions, Nicki had a lot more to say than could be included in this summary. You can read her InfoQ blog on this topic for further detail. Or watch the full video to discover some examples of how the four community-driven principles worked out in real life and pick up a few more practical pointers.
.webp)
.webp)
