Improving software flow

Открываю сегодня в Казани наш ИТ-фестиваль с вышеуказанным докладом, а материалы к нему публикую здесь

4 основные книги, из которых родилась идея доклада
- The Phoenix Project (2013 год) - книга написана в жанре производственного романа и похожа на книгу "Цель" ("Goal") или "Критическая цепь" ("Critical Chain") Голдратта.
- The DevOps Handbook (2016 год) - книга с популяризацией devops подхода
- Accelerate (2018 год) - книга, где приводятся крутые выводы о связи процессов и практик внутри организации и ее эффективности, а это именно те вопросы, которые интересуют менеджмент.
- The Unicorn Project (2019 год) - эта книга написана Gene Kim как продолжение предыдущей книги Проект Феникс

Связанные книги
- Team Topologies - книга про Team-First подход при проектировании архитектуры программных систем, так и организации.
- Learning Domain Driven Design - эта книга содержит много рекомендаций о том, как бороться со сложностью при проектировании софта.
- A philosophy of sotfware design - книга посвященная борьбе со сложностью и тому, как практиковать стратегический подход к разработке.
- Making Work Visible - простая книга про улучшение процессов разработки с использованием kanban подходов
- SRE Book - крутая книга целиком посвященная тому, как делать надежные системы и строить процессы вокруг них
- "Lean Software Development" - книга про lean практики в разработке

Исследования
- Google's Project Aristotle - исследование, которое ответило на вопрос "What makes a team effective at Google?"
- A typology of organisational cultures - интересное исследование про типологию организационных культур (pathological, bureaucratic, generative)

Мои выступления на связанные темы
- Культура постмортемов
- От монолита к микросервисам и обратно
- Эволюция подходов к развитию мобильного банка Тинькофф
- Эволюция web Tinkoff на ArchDays

#Processes #Management #Architecture #Conference #ExternalReview #ProductManagement #Leadership #SoftwareDevelopment #Software #SoftwareArchitecture

Как я выбираю какую книгу читать следующей

Мне периодически задают такой вопрос и я всегда отвечаю, что это зависит от контекста и текущей ситуации. Например, пару недель назад пролетела новость про то, что Cisco покупает компанию Splunk за 28 млрд долларов. Это интересная новость в силу того, что Cisco - это топовая компания по производству сетевых устройств и не только, а Splunk - это один из лидеров на рынке observability платформ. Поэтому я решил узнать про нее побольше и, закончив читать предыдущие книги, взял с полки бумажную книгу "Соединяя точки. Уроки лидерства" Джона Чемберса, ex-CEO компании с 1995 года по 2015.

В этой книге Джон рассказывает про свой подход к управлению на примерах из жизни IBM, Wang Laboratories и в основном Cisco, где он за 20 лет построил компанию, которая в 2000 году даже была самой дорогой в мире:) Одна из глав как раз называется "Мой план успешных поглощений", в которой Джон говорит про свой подход, в основе которого лежат 4 ключевых принципа
1) Сосредоточиться на тех поглощениях, что позволят выйти на новые рынки в переходном периоде или расширить на них свою деятельность
2) Прислушиваться к рекомендациям клиентов
3) Сразу же интегрировать компанию в свою структуру, если вы не покупаете ее в качестве самостоятельной бизнес-единицы
4) Настойчиво добиваться соответствия вашей культуре и ценностям

Интересно, что именно стратегическое поглощение Crescendo, закончившееся успешно, позволило Джону стать главой компании, а потом провернуть еще 179 поглощений, которые он проводил в соответствии с приведенными выше принципами. Дальше он поделился семью золотыми правилами, что они использовали при заключении сделок:
1. Каждое поглощение должно соответствовать вашему видению и стратегии
2. В центре внимания должны находиться рыночные преобразования и подрывные инновации в области технологий
3. Прислушивайтесь к рекомендациям клиентов при выборе объекта поглощения
4. Создайте взаимовыгодную ситуацию для обеих компаний, их руководителей, инвесторов, сотрудников и клиентов
5. Отдавайте предпочтение компаниям и технологиям, соответствующим вашему профилю
6. Выбирайте компании, культура которых в значительной степени соответствует вашей
7. Учитывайте географическую близость к своей штаб-квартире или основным операционным центрам

Отдельно Джон говорит о том, что объединение - это хорошая возможность для компаний разных размеров, где большая компания поглощает маленькую. А вот для сравнимых по размерам компаний лучшим вариантом является стратегическое партнерство - это не так рискованно как объединение, но позволяет получить хорошие результаты. В этом случае оно тоже должно иметь стратегическое значение для компаний, у обеих компаний должна быть мотивация к этому партнерству, эту идею должен разделять весь топ-менеджмент компании, а также в рамках партнерства стоит инициировать несколько проектов, чтобы общий баланс ценности портфеля был относительно справедливо распределены между компаниями.
Отдельно Джон приводит статистику того, что из 180 поглощений только треть была неудачными, а несколько десятков компаний выросли в миллиардные направления по обороту. Именно за счет поглощений компания Cisco активно наращивала свой портфель продуктов для "Changing the way, we work, live, play and learn".

P.S.
Отдельно потом напишу про книгу целиком, а то тут получилось рассказать только про одну главу:)
#Management #Leadership #Processes

dbt — ядро современной платформы данных - Евгений Ермаков - SmartData 2023 (Рубрика #Architecture)

Интересный доклад Евгения Ермакова про построение дата платформы в toloka.ai, которая, получив независимость от Yandex, вынуждена была переезжать на новые технологии. В итоге, выбор пал на databricks, dbt, airflow и tableau. Автор рассказывает о том, почему был сделан такой выбор и как в итоге это все работает.

Основные моменты следующие:
- Сама toloka - это система для краудсорсинга, куда заказчики приходят с задачками навроде разметить данные, а с другой стороны на платформе зарегестрированы люди, которые их выполняют
- Архитектура базируются на трех китах:
-- Data lakehouse
-- Процессы в соответствии с подходом data mesh
-- Современный технологический стек
- До переезда на новые технологии ребята использовали много своего, часть из которого уже есть в opensource: YTsaurus, datalens
- После переезда выбрали новые технологии и dbt стал ядром системы, закрывая функциональность: data quality, data catalog/ data observability, batch processing (вместе со spark), orchestration (вместе с airflow)
- Изначально dbt (data building tool) нужен был в качестве удобного инструмента для transformation шага в ETL/ELT
- Интересно, что в концепции компании dbt есть мнение и относительно ролей, где помимо стандартных data engineers и data analysts появляется еще analytics engineer. В итоге, data engineers - это те, кто делают так, чтобы data платформа работала эффективно, data analysts ищут инсайты в данных и помогают их эффективно использовать, а вот analytics engineers - это ребята, что-то среднее между другими двумя + хорошо укладывается в концепцию data mesh, где нет централизованной дата-команды, а есть дата-команды по доменам
- Основой dbt-проекта является dbt model. Модель состоит из файла с описанием логики (.sql или .py файл) и файла с описанием конфигурации. В .sql файле есть запрос на формирование объекта, другие модели используются через ref() или source() + используется jinja шаблонизация. В .py файле возвращаем dataframe с рассчитанными данными, есть доступ ко всем возможностям pyspark + другие модели тоже используются через ref() или source()
- Материализацию запроса dbt берет на себя и есть разные стратегии, из которых самая интересная incremental
- Настройки хранятся в dbt_project.yaml и profiles.yaml
- dbt поддерживает большое количество баз данных, например, postgres, mysql, clickhouse, ...
- dbt - это консольная утилита, например, при запуске dbt build происходит сборка всех зависимостей между моделями, а также компиляция python/sql запросов и запись в manifest.json
- Команда dbt run запускает скомпилированные запросы, где запуск можно настроить по разному, но интересно запускать по графу
- Кстати, dbt умеет генерировать документацию командой dbt docs generate и дальше можно посмотреть на lineage данных
- Также мы можем писать тесты в том же месте, где мы описываем модели, а дальше запускать их при помощи dbt tests. Например, можем проверять unique или not null на поле, а также если хотим relations между моделями
- У dbt есть еще много возможностей, но про них стоит почитать самостоятельно:)
- Дальше автор рассказывает как сделать data mesh на уровне dbt + airflow. Автор рассматривает варианты вида:
-- Монолитный - один dbt проект на всю компанию
-- Микросервисный - отдельные dbt проекты на каждый домен
-- Layered - отдельные dbt проекты по уровням
-- Смешанный - анархия, где проекты создаются кто как хочет
Выбрали монолитный подход и получили аля монорепо под data mesh, в котором живут все. Обусловлено это было тем, что при микросервисном подходе ломались все связки между моделями (до 1.6 не могли называть модели одинаково в разных проектах + была проблема с импортом друг друга, так как это приводило к циклическим зависимостям).
Из интересного еще сделали конвертор графа исполнения dbt в airflow формат, чтобы запускать DAG из airflow.

В итоге, ребята реализовали свой подход к data mesh при помощи open source инструмнетов и вся схема выглядит достаточно стройно.

#Data #Datamesh #DWH #Processes #Management

Research Insights Made Simple #6 - Interview with Nikolay Golov about data platforms (Рубрика #Data)

И, продолжая тему систем хранения данных, я решил сегодня поделиться новым выпуском подкаста про инсайты. В этот раз ко мне в гости пришел Николай Голов для того, чтобы обсудить то, как строить дата платформы в 2025 году:) Коля исполняет роль head of data engineering at ManyChat, а до этого он был head of data platform в Авито. Коля знает все о том как построить OLAP и OLTP системы, интенсивно работающие с данными. Выпуск доступен в виде подкаста на Ya Music и Podster.fm

За время подкаста мы обсудили темы
- Как развивалась карьера Коли в разных компаниях и как он стал преподавать базы данных параллельно с основной работой
- Как можно строить платформы данных (централизованно, гибридно и децентрализованно)
- Как выглядят принципы федерализации данных (аля data mesh) в теории
- Во что этот подход превращается на практике
- Как строить дата платформы в стартапах, средних, а также крупных компаниях в 2025 году
- Что не так с классическими базами данных (Postgres и иже с ним)
- Что не так с MPP базами данных (Vertica, Greenplum, ClickHouse, ...)
- Как data mesh превращается в data mash и как цепочки дата продуктов работают на практике
- Как выделять базовый домен данных, чтобы уменьшить длину цепочек дата продуктов
- Почему облачные аналитические базы так быстры: колоночное хранение + разделение storage и compute
- Что такое medalion architecture
- Куда дальше будут развиваться технологии обработки данных и почему нельзя полагаться на старые подходы и ограничения

Дополнительные материалы
- Статьи из периода работы в Avito "Vertica+Anchor Modeling = запусти рост своей грибницы"
- Статья из периода работы в Manychat: 1 и 2
- Запись "Data Modeling Meetup Munich: From Data Vault to Anchor Modeling with Nikolai Golov"
- Запись "DataVault / Anchor Modeling / Николай Голов"
- Научная статья "Golov N., Ronnback L., Big Data Normalization for Massively Parallel Processing Databases" //Computer Standards & Interfaces, 09-May-2017, https://doi.org/10.1016/j.csi.2017.01.009
- Научная статья "Golov N., Filatov A., Bruskin S.,Efficient Exact Algorithm for Count Distinct Problem", Computer Algebra in Scientific Computing, July 2019

#Data #Datamesh #Processes #Management #Architecture