Rebuilding mobile bank development around the business
From a CTO who owns not just the design but its implementation
From a CTO who owns not just the design but its implementation
From a CTO who owns not just the design but its implementation
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
End of 2019
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
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
The business grew, the IT structure changed
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
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
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
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
Teams, architecture, quality, Mobile DevOps
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
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
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
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
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
When it is time to change your own 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
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
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
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
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
polomodov.tech
All slides and links are in the Telegram channel
Alexander Polomodov, Technical Director & Fellow, T-Technologies
@book_cube