As a project lead I’ve repeatedly found applying the concept of ‘Infrastructure as Product’ (IaP) fundamentally transforms teams’ approach and delivers better quality software by enabling development teams. But how do we apply such a product mindset to software infrastructure development? Isn’t it impossible? The obvious challenges include:
What does a ‘product mindset’ mean from an infrastructure team perspective?
How to start when instilling a product mindset in an infrastructure team?
How to help developers think about what it means to build products for developers?
In resolving these challenges for my own projects, I have 3 recommendations, based on what I’ve seen work on multiple occasions:
Recommendation one: Align people with the IaP mindset
Firstly we need to get the platform engineering (infrastructure) team on-board with the IaP mindset.
Let’s understand this by using metaphors. The first example is train travel; for a train to travel between destinations it needs infrastructure in place in order to arrive safely. The infrastructure includes the rails, signals, electricity and the platforms where passengers on-board/off-board. etc.
Let's take another example of car travel. The paved road is provided so the driver can travel safely and smoothly to their chosen destination. The infrastructure includes the paved road, traffic lights, signage, road markings and traffic islands.
If you apply either of those metaphors to an IaP mindset, the infrastructure has pipelines that are used to deploy the software, making core tasks simple, such as automated security checks, testing. A feature team uses this infrastructure to deploy the software securely to its destination. By using the ‘rails’ or ‘road’ the team is provided with a safe deployment pipeline to specific environments.
In our metaphors the infrastructure is the enabler, whether it’s a car driver using a paved road or a train using the rails, they don’t have to worry about construction or maintenance they just use it to complete their journey. Similarly, in software development the infrastructure team becomes an enabler that allows the feature team to deliver their software.
This is the same as a customer who is using an app the feature team builds, the infrastructure team needs to provide infrastructure to the feature team (their customers) which they don't need to think about either.
Using some of these metaphors can help with onboarding the team with the IaP mindset.
The three key lessons I learned by having a product mindset at this point are:
It’s critical to listen, gather good requirements and feedback continuously. The team can help with the requirement of gathering processes using various techniques and asking the right questions in order to clarify the consuming teams requirements
Infrastructure needs to be coded so that it can be built, tested, maintained and deployed continuously
Thinking of IaP from a provider point of view can help keep customer requirements in mind and ensure you are building the right thing
All this is only possible with an IaP mindset and approach.
Recommendation two: Understanding the consumers and the providers of IaP
I read articles, books and reference sources, including the book Infrastructure as Code by Kief Morris, to understand the theory. I took my understanding and applied the knowledge I had gained to real-life situations.
Two years ago I experienced infrastructure being built by a Platform Engineering (PE) team for a feature team. As a QA in the feature team (a consumer in this context) I was the bridge between the teams to ensure the infrastructure product was good quality. A key practice was providing a fast feedback loop between the two teams to ensure the infrastructure team was satisfying the feature team’s needs. We also used product design techniques including; user research, personas and user journeys to bring the work to life.
Three key lessons I learned as part of a team consuming infrastructure were:
Be the bridge and encourage collaboration so the PE team is building the right thing and building the thing right by understanding the requirements
If the PE team understands the right things to validate and why it’s important they will build a good quality product. Fast feedback is critical to allow the feature team to help the PE team deliver rapidly
The feature team is empowered to utilise the infrastructure without worrying about maintenance of the infrastructure
Recommendation three: Getting started with IaP adoption
The best place to start is by clearly establishing the vision and goals of how the team will provide IaP. A real life example of such a vision that we used in one of our project is:
A platform with a set of capabilities that will enable an autonomous team to be responsible for what they have built in a secure, realistic, scalable, auditable, measurable, testable and repeatable way while being adoptable for Cloud Native Transformation.
An example of some goals related to the above vision would be:
Standardising the platform for: security, cost efficiency, scalability and performance.
Creating a scalable underpinning for all Apps
Establishing a predictable cost model for the platform
Enabling and empowering the application teams (being customer focused)
Define four key metrics and basic implementation
The next thing is milestone planning to help with prioritisation to build a MVP (Minimum Viable Product). For example defining the milestones for the goals:
Building basic infrastructure pipelines
Running a tracer bullets through the infrastructure to rapidly establish the path to production
Sharing the milestones and supporting them with the backlog of epics and stories
Finally establish the ways of working to work in a similar way to how typical cross-functional application teams operate in terms of team profile, ways of working and engineering practices.
Three key lessons I learned during my time as a Project Lead encouraging a product mindset were:
Bring the team on-board with the IaP mindset by sharing real examples
Establishing a vision, goals and milestones and defining stories to achieve them
Establish a cross-functional team that is outcome driven and uses automation
In summary
There are many ways that we can encourage a product mindset being applied to software infrastructure development and get people on board with IaP. Using a suitable metaphor like the train and paved road encourages the right kind of thinking around how developers can build products for other developers. Helping the team find a place to start by working with them to establish a vision and goals is also a critical success factor. The recommendations above should help you meet the challenges of instilling product thinking and adopting this approach is one way of delivering IaP.
Credits: Thanks to Kief Morris, Andrew Harmel-Law and Julian Holmes for their advice and support in building this content!
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
