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
Team, process and architecture at the end of 2019
One shared IT team with shared prioritisation
Large releases roughly once a quarter
A monolithic app split into horizontal layers
And a Mother API — a Scala 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. A team per customer, plus a platform
The mobile bank platform
Six customers — six feature teams
Release and Platform — delivery and modularity
Design & Improvements — the shared UI
Performance and Reliability — the shared qualities
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. Autonomy rests on shared rules
Unification and autonomy
Process rules: delivery management and releases
Technical rules: a module per team, control in CI/CD
Autonomy comes from application modularity
Three workstreams grew out of that
13. Every feature team owns its own modules
Splitting into modules
Feature team modules follow the domains
Shared modules are the platform teams' job
Three layers inside a module
A mono-app is assembled per feature team
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. A delivery manager drives the change in each team
The role and how it works
A data-driven change manager
Owns the end-to-end delivery of value
Shortens time to market, raises predictability
A year: from a change plan to an advisory mode
17. 04. Triggers and outcomes
When it is time to change your own teams
18. Three triggers for evolving your teams
And the symptoms that make each visible
The software got too big for one team
Delivery slowed down, and the trend holds
Business services rest on scattered lower-level ones
Each trigger shows up through its own symptoms
19. In our case the platform is handed over as a service
Team types and interaction modes
Stream-aligned — the business feature teams
Platform — the mobile bank platform teams
The interaction mode is X-as-a-Service
The topology follows size and maturity
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. Backend, frontend and mobile take the same road
A closing thought on converging approaches
A monolithic backend gets split into microservices
A monolithic frontend — into micro-frontends
A monolithic mobile app — into modules
The vocabulary changes, the move does not
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