Squads
Agile architecture is not just software and technology its how we work too
A good architecture will take into account how multiple teams will work together to deliver a software solution.
This is a possible way to implement Platform Engineering / Team Topologies.
Note: your solution will depend on your context.
TL;DR;
All teams are Squads with backlogs
Platform Engineering
- A core team which can own and realise the common/cross-cutting concerns.
- Implement
inner source, allow for all teams to contribute to the platform. - Promote
self-servicewith guard-rails where possible. - operates like any other product squad.
Product squads
- Can use specialist technologies (always try to enable innovation)
- Product teams, work together to deliver company solutions to delight the customer.
Concept
The people
We are asssuming we have a number of engineers (developers and architects), trying to corrdinate the solution delivery.
Product teams is something we have seen promoted with Scrum, and size of the teams is important to keep cadance
We still need to coordinate change and high level vision which can span multiple teams.
Common concerns
In addtion we are assuming that while developing the solution across the teams, each team will need to implement a high level of duplicate code (cross cutting concerns, software qualities)
We have seen teams be overwhelmed taking into context all of the software qualities.
An example is logging, this is something we can do consistantly and to a standard (OpenTelemetry) across all teams, why implement differently in each squad?
Goal
In this case, lets say we want to increase development capacity by horrizontally scaleing the squads.
Platform Engineering
Taking into account that each squad can by overwhelmed to implement all the software qualities, lets see if we can foster a shared responsibility model.
In the picture above we have
- Product squads - mostly focused on domain services, and use the same patterns where possible provided by the platform (they may implement a technology stacks if and when it makes sense)
- Plarform Engineering Squad - implement the common/cross cutting concnerns (which add up to be the platform)
this is to enable the product squads and accellerate the overall delivery.
Squads working together
The following is a possible way, assuming you have a group of architects that coordintate the Technology, People and Processes
All teams are squads
Architecture Squad
Coordintes change and vision acorss all the squads.
Architect can sit across one to several squads to provide guidance.
Inputs: all the squads (feedback, ideas), and C-board (vision)Outputs: Reference Achitecture, Roadmaps, Decision Records, etc
Platform Engineering Squad
Engineers which take the cross cutting and common solutions
Considers how to enable the other squads with Self-Service and automation.
Inputs: all the squads (feedback, ideas), Architecture (main requirements)Outputs: co-works on a number of the architecture outputs, makes the company platform (standards, code libraries, self-service, developer experience etc)
Product Squad
Delivers the company products which delight the customers
This includes a lot of coordination of the customer journey, and events which support that.
Inputs: Architecture, StakeholdersOutputs: services, documents
Other observations
Inner source
The winning aspect to this is the community forged around the platform, where one solution can help accelerate multiple delivery product teams
One powerful concept in innter source
The platform is owned by the Platform Engineering Squads, however everyone can contribute, similar to Open Source.
(you can also consider communities of practice. An observation is the a high level of content will revolve around common and cross-cutting, which is the platform.)
Forming a new team
A team should be formed on the same basis of why you would form a new service
Evaluate all teams (exmaples questions you may ask yourself)
- are the doing to much? split into new teams
- are 2 teams doing to little? can they be merged
A solution
Its a solution, it may/may-not work for you (remember the ITS DEPENDS, there is no one size that fits all)
you may need to
- consider what would work for you
- take only parts which do
- there is a lot of disapline and other processes not mentioend here
