Channel. Product. Platform.
How the approach to building Tinkoff's mobile bank evolved
Slide contents
1. Channel. Product. Platform.
How the approach to building Tinkoff's mobile bank evolved
2. Alexander Polomodov
CTO of the mobile bank, online acquisition and more
I curate our System Design and Troubleshooting interviews
3. For anyone who has asked these questions
Who this talk is for
Why scale development at all?
How do you do it evolutionarily, without dropping business work?
Which target topology should your teams aim for?
How do you balance platform and product development?
4. Sixteen years in six milestones
The mobile bank as channel, product and platform
5. 01. The mobile bank as a channel
2006–2011: from postal mail to the first app
6. A branchless bank on the Capital One model
How it all started (2006)
Credit cards only at the start
Direct sales by postal mail
Customer contact through call centres
7. The first version of the app was built by contractors
The mobile bank appears as an additional channel
Basic services were picked for the launch
The first version was built to order by contractors
Requirements were written screen by screen
Planning ran as app versions with scope fixed up front
8. 02. The mobile bank as a product
2015: development moved in-house
9. One team of twenty for three customers
The mobile bank as a product
10. This worked — and here is why
While there are few products and the team is small
There were a few main products taking the resources
The team was small — around 50 people by 2019
Priorities could still be managed by hand
The focus was on extending functionality
11. 03. The mobile bank as a platform
2019: verticals, teams and architecture
12. A monoline bank grew into a set of verticals
The group's growth and the IT landscape
2006–2019: from monoline bank to SuperApp
Verticals: retail, SME, investments, insurance
…the mobile operator and non-financial services
And platforms: data, ML, origination, infrastructure
13. Several apps now, and still one core team
Different apps and a shared core team
14. Six business teams and five platform teams
The new team structure
15. Change the teams and you change the architecture
Three states of the same diagram
16. Releases are tied to dates, not to scope
Release trains and the engineering culture
17. Large releases every four weeks
Interim results
Plus smaller releases in between
Processes documented, owned by the team and the DM
Platform teams rolled out modularisation
Set up mobile SRE and optimised performance
18. 04. So what next?
2022: end-to-end delivery and governance
19. Three triggers that it is time to change the teams
The business wants better end-to-end value delivery
20. The end-to-end process runs through a delivery manager
Teams spanning SuperApp, APIs and Backends
21. The rules check themselves automatically
Platform technical governance
22. 05. Wrap-up
The questions I promised to answer
23. From a startup to a SuperApp team of ~400 engineers
The questions I promised to answer
At the start there was no in-house mobile development at all
The app became an advantage — development moved in-house
Products multiplied — a platform became necessary
Cross-cutting teams demanded technical governance
Take this experience and map it onto your own situation
Why scale, how to do it evolutionarily, which topology, and how to balance platform against product
24. Materials for further study
From the talk's closing slide
The written version of the talk — bit.ly/mobileBankEvolution
All recommended materials are listed at the end of the article
25. Thank you!
polomodov.tech
All slides and links are in the Telegram channel
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@book_cube