(Cover photo credits: James Harrison @jstrippa via Unsplash)

First, here is some context

The idea of leveraging tools and frameworks to create better software is not new. For example, in traditional product-centric approaches, vendors pushed developers to build services that orbited around a smart integration bus with the vain hope of making the software more robust (Oracle SOA Suite anyone?). Constrained by lots of proprietary technologies, this approach was far from ideal for developers to design and build their applications. Nowadays, with the emergence of standards-based computing utilities (Serverless) and the novel software engineering practices that evolved with them (NoOps), we can look at these internal tools from a more developer-centric point of view.

Nowadays, you no longer need to buy a product to cover all the cross-cutting and foundational software needs. Building your stuff in-house is much better, especially if what you are creating is core to your business and sets you apart from the competitors in the marketplace.

How are high-performing software teams doing it?

The answer is by building tools to show their developers that they believe in them as creative problem solvers they are trying to help. There is nothing more motivating for a software development team than having stable infrastructure, usable tools, and an efficient development process that maximize the value of their creations.

That is why internal software platforms are becoming a thing. They are built in-house and invisible to the eyes of the final customers. These way, these end-users receive the value that platforms help to unleash and developers build in the form of better functional software.

What is a platform?

An internal software platform is a collection of cross-cutting services, principles, and tools that work in harmony to allow developers to build, test, and deploy other domain-specific business services. Platforms provide the digital means (with an accent on documentation, self-service, and APIs) to enable the different development teams to create software products that end consumers will love to use.

During the past few years, we have seen how a few software organizations have started to spin up product engineering teams that create and support internal software platforms intending to enhance time to market, modernize infrastructure operations, and improve customer experience.

10 things you should know about platform teams

Platform teams are product engineering teams that build and support internal software platforms—that easy. I've been running an internal software platform team during the last 7 years already at DXC technology, and I have documented everything I learned in the book "Building Software Platforms. A Guide to SaaS Transition with AWS." Here is a list of things that I consider very important about these teams.

1. Not every company can afford a platform team. Small organizations and startups usually begin by concentrating and assigning multiple functions to incredibly productive and talented individuals. Considering the split of some transversal functions to a dedicated team is a sign of growth and maturity, regardless whether you finally do it or not.

2. There are multiple benefits in treating an internal platform as an internal product. Under these circumstances, platform teams must be considered a product team by the organization too. The artifacts they create are managed per the same rules and policies as any other software product in the portfolio.

3. An internal platform, even in its simplest form, must be treated as software. Consequently, a platform team must be considered an engineering team that builds, tests, and delivers software. It just happens that this piece of software is an internal enabler tool for other teams to build with. From developers to developers.

4. A platform team is not the old operations team re-labeled as a platform team. Be precautious about preserving existing silos and legacy teams so you don't put lipstick on a pig. Not all companies know how to spin up an entirely new start-up organization to cater to the unique platform architectural style, especially if you need to work with legacy ticket-driven organizations and systems.

5. A platform team is not a new shared services team that builds and maintains independent and unconnected services. There might be a tendency in other product teams to interpret this new component in the organization's portfolio as a bucket of services at the disposal of their development teams. You must pay special attention to this viewpoint.

6. The mission of a platform team is to reduce the amount of undifferentiated work carried out by the development teams. This way, developers can consume foundational capabilities in a self-service manner to focus on solving business problems. These capabilities include setting up CI/CD pipelines, spinning up environments, deploying services on the cloud, or even consuming infrastructure APIs that facilitate their daily jobs.

7. Platform teams rationalize services, principles, and tools offered by other 3rd party providers (especially cloud providers) and adapt them to your organization's particular needs. You shouldn't be in the business of competing with other commercially available services with your home-grown solutions (e.g., Kubernetes, Jenkins, Google Material Design System, or Amazon Cognito).

8. Platform teams are curators of developer experiences. There is a lot of value in creating a catalog of opinionated services and offer them as a simplified experience to the different development teams.

9. Platform teams need people with the appetite to research and develop the latest technology and collaborate with the developers. These team members are individuals with a pioneering attitude, including problem-solving, problem-restatement, and out-of-the-box thinking. It is vital to meet developers where they are and help them walk the path to the new vision while resolving all the issues during the journey.

10. Platform team members also have a settling attitude who understand the consequences of introducing a continuous flow of changes into existing systems. These are typically engineering profiles with an operations mindset who look after software properties such as scalability, testability, reliability, and observability.

Bonus: Platform team members play an integrator role across multiple groups, giving them a company-wide view that others (even technology executives) don't have. That is why engineers in platform teams usually embody not only the platform's vision but the whole organization's.

Conclusion

Internal platforms are interesting because they also introduce a new architectural style. We can look at it still as a serviceful style, even an evolution of the microservices approach where each service team is liberated from their responsibilities in transversal and foundational concerns.

What is fascinating about introducing a platform-based architectural style is witnessing new talent and attitudes emerge thanks to the industrialization of cross-cutting functionalities and the heavy-lifting of undifferentiated work.

In summary, we might very well be at the gates of another significant shift in the way we design, build, and deliver software. In the coming years, we'll see organizations starting to adopt this recommended model and adapting their talent acquisition strategies accordingly in need of platform engineers.