Rebuilding mobile bank development around the business
From a CTO who owns not just the design but its implementation
Slide contents
1. Rebuilding mobile bank development around the business
From a CTO who owns not just the design but its implementation
2. From «how it was» to «when it is your turn»
What we'll cover
How it was before 2020
What changed and how we accounted for it
Rolling it out: teams, architecture, quality
Triggers, outcomes and further reading
3. 01. How it was before 2020
End of 2019
4. One team, quarterly releases, a monolith
5. This worked — and here is why
The design matched the business it served
There were a few main products
The team was small — around 50 people
The focus was on adding functionality
Large irregular releases suited the business
6. 02. What changed and how we took it in
The business grew, the IT structure changed
7. A monoline bank grew into a group of companies
The Tinkoff group and the IT structure
2007–2020: from Tinkoff Black to the SuperApp
Six business verticals now
Platforms grew above the infrastructure
Each vertical wants its own pace
8. Each customer gets a team; everyone shares platforms
9. Releases are tied to dates, not to scope
The release train
Teams must be able to work independently
The release leaves on its date
Miss it and you take the next one
The contents stopped being a promise
10. Change the teams and you must change the system
Conway's law, and brownfield rather than greenfield
Organizations design systems that copy their communication
The desired team structure changed
So the system has to be redesigned
The business cannot pause — so we redesign evolutionarily
11. 03. How we rolled the changes out
Teams, architecture, quality, Mobile DevOps
12. Common rules support team autonomy
13. Feature teams own their modules
14. From checklists to test cases and a testing pyramid
Quality assurance
Test model: checklists → test cases
We wrote down the test debt on existing functionality
The pyramid: unit, integration, UI, end-to-end
Plus quality metrics, crowdtesting and contract testing
15. The added load demanded its own improvements
Mobile DevOps
More builds and autotests — we reworked the CI/CD infra
Code, style and architecture control became a requirement
We automated the checks: Danger for iOS, Sonar for Android
Client monitoring and feature toggles were added
16. Responsibility for change passes to the team
17. 04. Triggers and outcomes
When it is time to change your own teams
18. Three signals that teams need to evolve
19. Teams use three interaction modes
20. Everything changed at once, and it was all connected
What came out of it
The business requirements changed
The team evolution triggers fired
We had to redesign the team structure
And with it the process, architecture, quality and CI/CD
All of these changes are connected and run in parallel
That is exactly what makes it hard and interesting
21. Decomposition connects backend, frontend and mobile
22. What to read next
The links from the talk's closing slide
The «Team Topologies» book and its three-part summary
A review of «SRE practices in mobile development»
Articles on platform teams and client-friendly APIs
Earlier talks: Teamlead Conf 2018 and ArchDays 2019
23. Thank you!
polomodov.tech
All slides and links are in the Telegram channel
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@book_cube