Skip to content
TechLead Conf · June 30, 2021

Rebuilding mobile bank development around the business

From a CTO who owns not just the design but its implementation

/ Reshaping Mobile Bank Development · TechLead Conf 2021

Slide contents

  1. 1. Rebuilding mobile bank development around the business

    From a CTO who owns not just the design but its implementation

  2. 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. 3. 01. How it was before 2020

    End of 2019

  4. 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. 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. 6. 02. What changed and how we took it in

    The business grew, the IT structure changed

  7. 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. 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. 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. 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. 11. 03. How we rolled the changes out

    Teams, architecture, quality, Mobile DevOps

  12. 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. 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. 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. 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. 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. 17. 04. Triggers and outcomes

    When it is time to change your own teams

  18. 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. 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. 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. 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. 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. 23. Thank you!

    polomodov.tech

    All slides and links are in the Telegram channel

    Alexander Polomodov, Technical Director & Fellow, T-Technologies

    @book_cube