The Secret Weapon of Modern Software Engineers: Introducing Internal Developer Platforms

“Today is going to be awesome.” 

After talking about the impact of Developer Experience on productivity in a recent article we wanted to talk to someone with first-hand experience. Meet Sarah, a new developer at ACME. Okay, it’s a fictionalized version but looking over Sarah’s shoulder on her first day will show you what DevEx can do. There is hard work to be done to make it look this easy, but it is very well worth it.

It was an important day for Sarah. She was starting to work as a senior software engineer at ACME, a top technology firm, and she was really excited about the company, the role, and the project.

“Today is going to be awesome,” Sarah thought as she was exploring the office. She had just gotten her access badge, and the initial credentials for the corporate account, and was on the way to pick up her new laptop.

A few moments later she met with Ryan and Anna Marie. Ryan was the Scrum Master on the team where Sarah was going to work, and Anna Marie was the Engineering Manager looking after her and others on the team.

They chatted for a bit, beginning to get to know each other. Shortly afterward, Anna Marie told Sarah about the expectations for her very first day.

“I know you have lots of questions, and we have lots of things to tell you about the company, the project, policies, and all that stuff. But for today, let’s focus on you getting onboarded fast and happy,” Anna Marie shared and then winked at Sarah.

“We have an internal platform that will help you get up to speed and reduce frustrations in your daily tasks,” Anna Marie continued. “Once you have your account set up on the laptop, simply visit https://thenexus.internal.acme.io/ and look for what you need. You’ll be surprised by the experience, but if you find any issue just let me or Ryan know.”

“Anything else I should know about the team or project before starting?” Sarah asked.

Ryan responded, “You just need to know that you will be working on the Aristotle project. With the assistance from the internal platform and its Nexus Copilot, you will be up to speed in no time. Enjoy the experience!”

Sarah already knew a bit about developer platforms, but she hadn’t had the opportunity to use any before, so she was really curious about what ACME had for her.

Sarah configured the usual stuff on the laptop, got her mail and chat tools ready, and opened the “mysterious” Nexus in the browser.

 —

It was a beautiful site. Well designed and with lots of stuff easily available. Sarah was able to identify some of the key areas for her to explore: a developer tools marketplace, a reference architecture catalog, component archetypes and examples for many programming languages, the business API catalog, and other interesting stuff.

However, what really got her attention was a “terminal-like” prompt in the corner, cursor bleeping like an old 80s computer, and an enticing, inviting prompt message: “You will never walk alone with The Nexus Copilot.”

She typed into the terminal: “Hi, I’m Sarah, the new member of the Aristotle project. Could you help me set up my computer? What tools would you recommend I configure to start with?”

After a few seconds, she got a response from the prompt: “Hi Sarah and welcome to ACME. Here you have some suggestions of nice tools that your teammates also use: Visual Studio Code enhanced with ACME favorite plug-ins, Rancher Desktop, Testcontainers, and OpenLens. If you like, I can share a script to install everything for you.”

Sarah responded yes and the prompt responded back with a shell script. Sarah was able to see that the script looked really promising, taking care of the installation of Homebrew and the rest of the suggested tools, including the recommended plug-ins for the IDE.

While waiting for it to finish, Sarah ran the script and asked the Nexus Copilot another question: “What else should I know to start working with my team?”

The Nexus Copilot responded fast: “As a team member on the Aristotle project, I would recommend you to visit the project wiki at https://wiki.internal.acme.com/space/Aristotle, the project board at https://alm.internal.acme.com/board/Aristotle, and join the chat channels Aristotle-Main, Aristotle-GTK, and Aristotle-Issue-Feed.”

Sarah was profoundly surprised. In no time she has been able to get the basic tools that she needed and access the project documentation and the issue board. She was able to see there in the board the first task assigned to her with a welcoming name: “Update SomeLib version in e-cart microservice to remove vulnerabilities – For Sarah on her first day.”

And there she went. Thanks to the readily available project documentation, she quickly understood the high-level architecture of Aristotle, identified the e-cart microservice, the Git repository where the e-cart code was located, and the important facts about the workflow in use by her new team, including a TL/DR explanation of how to fill in pull requests and get information from the CI build to know whether the expected quality criteria were ok, and finally how to test and promote changes when ready.

In the following four hours and after two cups of coffee, Sarah completed the first assignment, tested it locally thanks to the tools installed before, and was ready to get it reviewed and hopefully released before going home.

The whole experience, including the welcome, tool setup, and everything else, happened in less than a day of work.

—

Anna Marie and Ryan moved closer to Sarah and asked, with apparent smiles on their faces, “How was your day? We were able to see your pull request, and the workflow checks just showed that it looks good and is ready to be merged and deployed later. Tell us, how do you feel?” Anna Marie asked Sarah, visibly excited about the response.

Sarah took a deep breath and heartedly confessed, “It has been amazing! I still can’t believe that I was able to finish it in such a short time. In my previous works, the whole onboarding and first days at work were stressful, full of exhausting training, discovering the relevant stuff here and there, and lots of delays just waiting for things to happen.”

Ryan, happy with how it went for Sarah, added, “We’re so happy to hear that. Here at ACME, we’ve been working hard to make this possible. The platform team created such a wonderful tool, plus the architecture and product teams contributed with lots of relevant content, and everybody else added any other useful bit here and there to fill in any gaps. We still have a long way to go, but we are glad that your first day was memorable.”

“Yes, so, so happy that it was of help to you and made your day an awesome experience,” added Anna Marie. “We really believe that internal developer platforms such as The Nexus are fundamental in removing friction across teams, reducing developer frustration just because of delays waiting for needed stuff to happen or because of the burden of chores and manual, boring, repeated tasks. In this way, we can all focus on important matters, such as solving business problems thanks to human ingenuity and technology, collaborating, and being the best version of ourselves, while the tools, automation, and optimized processes do the rest. Welcome to ACME, Sarah.”

 —

The Rise of IDPs

This story, although fictitious and dramatized, captures how we see and experience software engineering nowadays with the rise of internal developer platforms (IDPs).

With every business being a technology business, more and more every year, developer productivity—no, developer experience as a whole—is now a top priority for any thriving company.

The multiplying effect of even the smallest enhancement and optimization along the software delivery life cycle (SDLC), applied to dozens, hundreds, or even thousands of developers, is staggering.

Moreover, as IDPs foster the self-service approach to common developer needs, they help to successfully remove bottlenecks and waiting times, reduce friction across different roles, and minimize IT waste.

IDP capabilities are diverse and growing every day as teams and the whole organization discover new ways to reduce friction and toil. Some of the most common include:

• Onboarding support: connecting developers and engineers to the needed context and knowledge for new role assignments in a given product, project, or platform team.
• Architecture reference models: blueprints, patterns, and principles, from high-level architecture points of view to detailed views at every architecture layer, inclusive of technology, business, and enterprise architectures.
• Component archetype catalog: component blueprints, examples, and best practices for every relevant archetype, such as frontend (desktop, web or mobile), backend services, data processing and streaming, etc.
• Continuous delivery and site-reliability engineering (SRE) best practices: GitFlow and pull-request-based workflows, continuous integration and continuous deployment reference pipelines, automated testing principles and tooling, configuration and secret management standards, infrastructure as code patterns, observability, GitOps, etc.
• SDLC methodology: including PPSM processes, Agile processes, release management, etc.
• Business API catalog: easy access to existing business services that can be reused across teams, for technical common capabilities, such as authentication/authorization, reporting services, billing capabilities, payment collection platform, etc., and also business capabilities such as customer data services, third-party integration services, and any other domain-specific business capability.
• Environment provisioning: management of project or product-specific environment needs for local workstations, non-production use cases, production (including disaster recovery), and even ephemeral test environments needed at any point along the SDLC.
• Developer tools marketplace: An e-commerce-like experience for the tooling needs of individual developers and whole teams. Search for integrated development environments (local or cloud-based), life cycle management tools, version control and wiki spaces, testing tools, etc. The marketplace applies to every kind of tool: local, remote, or SaaS; free, licensed company-wide, or project-wise, etc.

The possibilities are endless, as we discover more and more ways in which IDPs can contribute positively to developer experience.

- About The Authors

Mirco Hering

For over ten years Mirco Hering has worked on accelerating software delivery through innovative approaches (what is now called DevOps) and six years ago started experimenting with Agile methods. He supports major public and private sector companies in Australia and overseas in their search for efficient IT delivery. Mirco also blogs about IT delivery at notafactoryanymore.com and speaks globally at conferences about Agile, DevOps and organizational psychology.

Follow Mirco on Social Media

• 
• 

Jorge Hidalgo

Jorge is a software engineer and architect with 25+ years of experience mostly with Java, web and cloud. He dedicates most of his time to help clients transform with the help of open-source and cloud-native technologies, Agile and DevOps ways of working, architecting new and innovative solutions, implementing, and then running them inspired by SRE principles. Jorge is leading Accenture Iberia DevOps practice, as well as Accenture global Java community of practice. You can connect with him at “deors314” at X/Twitter, and “in/deors” at LinkedIn.

Follow Jorge on Social Media

•