Slide contents

1. 1. Architecture at Scale

   How architectural decisions are made at a large fintech

2. 2. Agenda

   Architecture to practical tools

   Why architecture must scale

   Booch, Kruchten, levels

   Software: RFC, ADR, groups

   Solution: SLA, contracts, debt

3. 3. 01. Why Scale

   The context of a large fintech group

4. 4. Why architecture becomes a discipline

   Meeting agreements stop scaling

   12M+ customers

   Multi-product ecosystem

   Team growth — onboarding knowledge

   Distributed teams — decentralized decisions

5. 5. 02. What Is Architecture

   The definitions we rely on

6. 6. Architecture = significant decisions

   Trajectory & boundaries

   Booch: significant system decisions

   Significance = change cost

   Trajectory — system direction

   Boundaries — costly to revisit

7. 7. 03. Three Levels of Architecture

   Software · Solution · Enterprise

8. 8. Three architecture levels

   Software · Solution · Enterprise

   Software — team; IDE, UML

   Solution — department; wiki, boxes & arrows

   Enterprise — company; ArchiMate

   Themes: patterns → options → strategy

9. 9. Enterprise architect is a mythical role

   Where each one grows from

   Software architect — grows from developers

   Solution architect — from analysts, per project

   Enterprise architect — origin unknown

10. 10. 04. Software Architecture

    RFC, ADR, and working groups

11. 11. Before

    Typical software-level pain

    Verbal decisions get forgotten

    Teams reinvent their stacks

    Infrastructure code duplicates

    No design-review language

12. 12. What we introduced

    Light process, heavy effect

    RFC — public discussion

    ADR — short record: context, decision, consequences

    Working groups by domain

    Tech radar + review gate

13. 13. 05. Solution Architecture

    Contracts, SLA, and tech debt

14. 14. Typical solution-level pain

    Many services, no rules

    No SLA — consumers guess expectations

    Weak APIs create consumer hacks

    Tech debt reaches bankruptcy

    Broken dependency can drop the system

15. 15. Design belongs to those who build

    Decisions documented, tech debt funded

    Design owned by devs and analysts

    Document conditions and trade-offs

    Tech debt visible and funded

    Core and platform teams

16. 16. 06. Enterprise Architecture

    The same process — company-wide

17. 17. The same decision process, just wider

    Unifying how IT decisions are made company-wide

    One decision process, company-wide

    Shared CI/CD and PaaS runtime

    Tech radar for external technology

    Doc standards and InnerSource

18. 18. 07. What We Ended Up With

    Conclusions and next steps

19. 19. What works at scale

    Culture beats tooling

    Architecture = costly-to-revise decisions

    Three levels need different tools/people

    RFC / ADR make decisions visible

    Working groups, contracts, SLAs create trust

20. 20. References

    Architecture models, fintech case

    Patrick Kua — Scaling out architectural decision making

    Kruchten — A Mature Discipline? (SEI, 2020)

    Fundamentals of Software Architecture + Technology Strategy Patterns

    ThoughtWorks Technology Radar v.22

21. 21. Thank you!

    polomodov.tech

    All slides and links — in the Telegram channel

    Alexander Polomodov, Technical Director & Fellow, T-Technologies

    @book_cube