Software Architecture is an overloaded term nowadays. Let's dig deep into its meaning: how to define software architecture, what's right, what's wrong. What's considered as software architecture, and what's not. What's not technical debt? What needs to be addressed to make better decisions as a technical leader. How to evaluate potential software architecture Identification & Elimination of Technical Debt Constant learning based on feedback Software Architecture is an overloaded term nowadays. Let's dig deep into its meaning: how to define software architecture, how to define tech debt, what's the definition of right and wrong, what needs should be addressed to make better decisions as a technical leader.

2. ● 2 года как Software Engineer
● 4 года как технический ко-фаундер
● 3 года как теклид/тимлид
● 5 лет как CTO в Zakaz.ua
● 3 года как Software Architect
● Director of Engineering at Takeoff
Technologies
Карьера

5. It’s not scalable.

7. Quality
Attributes
Environment
Human
Dynamics
Business
Strategy
Software Architecture

8. ●
●
●
●
●
●
●

9. И шо?
● В каждой категории есть тот или иной
стандарт по индустрии
● Это утопия все учесть одним махом
● Это утопия прийти и все поменять за
месяцы, если большие и в продакшене
● Тем не менее, все это важно

10. А еще
● Управление рисками
● Коммуникация изменений (Change
management)
● Коммуникация расписания релизов
(если как мы)

11. 2 years ago year ago now
опыт-опыт-опыт-опыт,
наука, корректность,
технологии,
архитектура
ээээ, а что,
там люди?
требования?
процессы?
стратегия?
ценность?
а там люди,
требования,
процессы,
стратегия.
ценность

12. Как приседать стратегически
3 → ~120

13. 3 инженера

14. 10 инженеров

15. 40+ инженеров

16. Что можно сделать
● Часть вещей включить в Definition Of
Done
● Иметь Definition Of Done и процесс
● Time To Market так же важен, как и
правильная архитектура
● Научиться изящно фиксить фиксы
● “Зачем?”, “Почему так?”, “Чем это
грозит?”

17. ● Стабильность системы – issue rate
● Скорость решения проблем - time to
resolution
● Скорость создания ценности - time to
market*
● Понятные [коммуницированные]
изменения
● Предсказуемость в графике
обновлений
На что мы влияем?
* это не метрика конечно, но
все ее чувствуют

18. Что делает..
клиентов счастливыми

19. Принимая во внимание
предположения, среду и
доступность ресурсов

20. 1. start-up
2. turnaround - a burning platform
3. realignment - a lot of denial
4. sustaining success - challenge invention
Среда в контексте STaRS model

21. ● Мы рассчитываем на рост в X% в месяц
● С максимальным жизненным циклом
клиента L заказов
● При этом сохранять возвращаемость на
уровне Y за период Z
● Одновременное количество клиентов,
которые мы обслуживаем должно быть
не больше, чем N
* это одна из задач архитектора, что тут не бредятина
Ключевые предположения

22. ● Если у меня $5 с клиента в месяц
● И 100 клиентов с приростом в 10% в
месяц
● Это типа идея не очень тратить $5000 в
месяц на AWS*
● Для “скейлебл” решения
* если конечно это не часть бизнес стратегии

23. Вызовы Технические

24. GIT – это данные
● Статический анализ совместно с
историей из GIT - это ценный источник
информации
● Если добавить еще данные из JIRA по
багам, то получится довольно
качественная картина происходящего

25. Tech Debt
● Идентификация Hot Spots - небольших
участков кода, над которыми работают
много людей
● Идентификация нездоровых шаблонов,
которые приводят к техническому
долгу
● Идентификация увеличения сложности
(cyclomatic complexity)

28. Knowledge Loss
● Идентификация людей, которые
работали или работают над одним
участком кода - только у них есть
знания о том, что внутри
● Нахождение кода без документации

30. Onboarding Performance
● Как быстро новые члены команды
начинают доставлять наравне с
остальными
● Как работает онбординг в сравнении с
приобретением опыта в динамике

33. Вызовы Человеческие

34. Онбординг
● Качество онбординга один из
ключевых факторов, которые влияют
на organization agility
● Онбординг через менторинг (100%) и
чтение кода - тупик, съедающий
огромное количество времени и
ресурсов
● Документация - важно, но
гранулярность должна быть вменяемая

35. Автономия
● Авторитарный стиль не работает при
40+ инженеров - риск что останетесь
без хороших инженеров
● Авторитарные решения - это
уменьшение автономии
● Соотв. бОльшая часть работы может
уходить на переговоры с инженерами -
или надо придумать организационное
решение

36. Автономия
● Андрей Панфилов
(dzer6@gihub) предложил
выражать идеи в виде
документа Architecture
Proposals
● Любой в компании может
создать предложение и
продвинуть свою идею

38. Инерция
● Любая идея требует коммуникации
● И времени на внедрение
● Особенно если ценность не в короткой
перспективе
● Или если новая штука вскрывает дыру
в работоспособности команды или
производительности софта..

39. Пример
● Мы решили использовать OpenTracing
● И подключили Elastic APM
● И сделали библиотечки для
интеграции
● И все конфигурации сконфигурировали
● Прошло больше года
● Угадайте какой % сервисов внедрили
команды?

40. Когнитивные искажения
систематические отклонения в
восприятии и мышлении, обусловленные
● субъективными убеждениями
(предубеждениями)
● стереотипами
● социальными, моральными и
эмоциональными причинами
● сбоями в обработке и анализе
информации

41. Когнитивные искажения

42. Крайне важно принимать решения на
данных, которые есть на руках
и только потом на опыте/исторических
данных из других компаний

43. Спасибо
https://twitter.com/maxmaxmaxmax