Очень интересное наблюдение. Факт, что продуктовая/заказная/внутренняя разработка устроены очень по разному.

На WAW был очень жаркий круглый стол, "Стандарты в процессах разработки в эпоху ИИ".

Спорили прямо сильно. А я вспомнил старое эссе Джоела Спольски "5 миров". Он говорит, что в программировании есть 5 миров:
- продукты (он пишет shrinkwrap, "упакованные" — то есть, коробка с диском; это 2002 год, облачных сервисов ещё не было)
- внутренняя разработка
- встроенное ПО
- игры
- одноразовое ПО (скрипты и т.п.)

Статья, конечно, устарела, и сейчас у нас очень редко продаются продукты "в пленке", зато есть очень много онлайн-продуктов, которые не нужно устанавливать. Внутреннюю разработку можно разделить на заказную и разработку своими силами. Встроенное ПО получило возможность частых обновлений. Некоторые игры тоже стали выпускать в состоянии глубокой альфы, и это норм. "Одноразовые" скрипты стали частью пайплайнов DevSecOps, и не очень-то одноразовыми.

Джоел обращает внимание, что почти вся литература по организации разработки и системному анализу написана людьми из внутренней разработки — потому что только в этой области компании могут привлекать консультантов и экспертов, которые в основном и пишут книги.

Это же проявилось и у нас на круглом столе: кому-то важна стандартизация процессов, имея в виду предсказуемость оценок и сроков завершения проектов — это явно люди из заказной разработки, для них сроки===деньги в самом прямом смысле. Для внутренней разработки своими силами сроки, по моему опыту, не так уже важны. Только в редких случаях, когда это нужно к какому-то событию, но тогда и угадывать их команде не надо.

Я с такими проектами много работал: изменение нормативки, запуск новой внешней системы, софт для поддержки какого-то события. Для банка вариант не запустить интеграцию с новой платежной системой ЦБ в срок просто не рассматривается, даже не ставится этот вопрос.

С другой стороны, какие-то внутренние вещи для удобства вообще не имеют большого значения. Автоматизируем мы какой-то процесс в этом месяце или в следующем — в принципе, большой разницы нет. Даже год не всегда важен. Именно отсюда все данные про проекты с превышением сроков и бюджета, как будто это что-то плохое. И умные книги — как за долю времени на анализ улучшить прогноз времени на выполнение.

А вот в продуктах — за что топили другие участники дискуссии, и я в том числе — важно число экспериментов и, соответственно, TTM — время до предъявления фичи рынку. И вот тут аналитики вообще не нужны — нужна хорошо построенная архитектура и инфраструктура, которая позволяет быстро делать фичи без глубокой проработки, выкатывать на часть аудитории и смотреть на реакцию. Потом быстро обратно откатывать, если не пошло, ну или развивать дальше, если угадали. Всё, что замедляет релиз — убирать из процесса. Аналитиков в первую очередь. По последним веяниям тут даже продакт-оунеры лишние — в больших продуктовых компаниях команды без них работают.

И это нас приводит к тому, как мы смотрим на людей и каких людей набираем. На этот счет есть ещё из 60-х годов два разных подхода: Теория X и Теория Y — про то, кто такие люди вообще. Теория X говорит, что люди ленивы, не амбициозны, не любят свою работу, избегают ответственности и низкомотивированы. Соответственно, им нужны стандарты, регламенты, KPI, ручное управление и микроменеджмент. С точки зрения менеджера, таких людей лучше всего заменить ИИ.

Теория Y видит в людях высокомотивированных, креативных, инициативных, отвечающих за результат своей работы (taking ownership). С этой точки зрения их нужно усилить ИИ и максимально избавлять от рутинной бездумной деятельности.

Общий вывод: следите, про какой мир вы говорите — примеры про управление атомными реакторами и кардиостимуляторами относятся к встроенному ПО, а цели людей из заказной разработки и продуктовой (и даже внутренней) прямо противоположны. И какая у вас основная теория в отношении людей — X или Y?

Блокировки при работе с СУБД

Badoo (нынче Bumble, единственный серьезный конкурент Tinder на мировом рынке) когда-то был полноценной социальной сетью. Например, у меня в профайле были сотни фотографий. Лента обновлений была полна всяких событий, по разнообразию совсем не уступающих Фейсбуку, особенно в теперешние времена (кто с кем подружился, что поделал, кого полайкал - с кучей свистоплясок вокруг privacy настроек). И конечно, был мессенжер, и с мессенжером была куча проблем. Мы всё делали на базах, и одна из типичных проблем подобных проектов - битые денормализованные счетчики непрочитанных сообщений. Мы избегали частых операций count и старались все счётчики денормализовать. Бывало, где-то косячили, счетчики начинали биться, а отлаживать большую систему, в которой обновления могут прийти из разных кусков – непросто. Косячили не так чтобы много, и вроде работали достаточно стабильно, но время от времени счетчики всё равно бились. Это не только была наша проблема - хорошо помню минимум два крайне неприятных косяка с битыми счетчиками в Телеграме и мессенжере Фейсбука, на которые напарывался сам как юзер.

Есть несколько способов побороть такие проблемы, и самый простой и прямолинейный - оптимистичные блокировки в начале транзакции (select get_lock(), например). Первая транзакция получает блокировку, а вторая транзакция просто не стартует, тк вначале попытается получить блокировку на уже заблокированй ресурс.

А ещё есть метод оптимистичных блокировок через версионирование. Кажется, мы его использовали редко, хотя метод прикольный. Суть в следующем. Куда-то в базе добавляется версия, и обновление идёт не просто по ключу, а по ключу с дополнительным условием, которое гарантирует, что транзакция изменяет “свою” версию. После обновления можно проверить количество обновленных рядов, и если 0 - обработать эту ситуацию как ошибочную.

Однако, вдумчивый читатель мог насторожиться: у СУБД бывают разные уровни изоляции. И действительно, описанная выше логика не универсальна. Уровень READ UNCOMMITTED рассматривать несерьезно. Если у нас уровень изоляции READ COMMITTED, то оптимистичные блокировки работают, как описано выше: вторая транзакция, которая пытается обновить данные с указанием устаревшей версии, не сможет этого сделать, так как версия уже поменялась. В этом случае никаких ошибок нет, но количество обновленных строк равно 0, и вот эту ситуацию (0 affected rows) нужно поймать и обработать. Но READ COMMITTED default уже не у всех баз, у MySQL в отличие от PostgreSQL, уровень по умолчанию – REPEATABLE READ. А вот если у нас уровень изоляции REPEATABLE READ или даже SERIALIZED, то ситуация совсем другая. На этом уровне движок базы самостоятельно отслеживает конфликты, и просто не даст обновить данные, которые успела обновить другая транзакция. И скорее всего в таком случае вся транзакция откатится, нужно будет её повторять. Поэтому оптимистичные блокировки будут работать по-разному для уровней изоляции READ COMMITTED, REPEATABLE READ или SERIALIZED, и это нужно учитывать.

Пишу не проверяя, так что не является финансовой рекомендацией. Кстати, насчет финансов: именно в биллинге постоянно ловили проблемы с блокировками в MySQL, и там был смешной косяк. Старые версии движка блокировок get_lock() не поддерживали множественные блокировки, но это полбеды. Настоящая беда была в том, что предыдущие блокировки просто сбрасывались молча, что могло приводить к неприятным косякам с деньгами на проде. Мы тогда просили Костю Осипова исправить это поведение, причем я изначально просил Костю не просто пофиксить поведение, но и “пропушить” его в апстрим Оракла, так как самостоятельно поддерживать кастомные сборки базы ну совсем не хотелось. Дело было давно (см. скрин), но с тех пор вроде в MySQL get_clock() работает корректно.

Пошли в вестибюль, сделаешь мне кастдев

При проведении кастдевов для нашего обучения выяснилось, что некоторым опытным инженерам непонятны наши тексты с описанием курсов, поскольку они написаны жаргонно, как будто для тех, кто уже “в теме”, а не для тех, кто хочет стать “в теме”. Поэтому я решил написать несколько заметок про темы, которые мы сейчас “качаем” благодаря сотрудничеству с Мишей Курмаевым: производительность бекендов и телеметрию. Начнем с заметки с определениями.

Телеметрия — фонарик в тёмном подвале твоего продакшена, помогает найти «неведомую херню» до того, как она найдёт тебя. Сбор, передача и анализ данных о работе системы.
Трейсы — это следы, оставленные запросом по всей системе, чтобы не заблудился и не потерялся в клубке твоих микро-сервисов. Последовательность событий, показывающая путь запроса через систему.
Распределенный трейсинг — это как гео-метка твоего девайса, но для запросов, показывающая, как они путешествуют через все сервисы, не заблудившись и не застряв в пробках. Отслеживание пути запроса через несколько сервисов в распределенной системе.
Спан — это как одна остановка в путешествии запроса, запись в дневнике, где фиксируются время, важные детали и связь с соседними станциями. Одна операция в трейсе, содержащая временные метки, метаданные и связи с другими спанами.
OpenTelemetry — это стандарт для телеметрии (трейсы, метрики, логи). За стандарт OpenTelemetry отвечает Cloud Native Computing Foundation (CNCF) при участии сообщества разработчиков и компаний.
APM — это аббревиатура для Application Performance Monitoring
Основные инструменты, предоставляющие возможности для сбора и анализа трейсов: OpenTelemetry Collector, Jaeger, Zipkin, Signoz, Elastic APM, Datadog APM, New Relic, Lightstep, Honeycomb
Кастдев (Customer Development) — это изучение клиентов и их потребностей.
Вестибюль (“vestibulum” , на латыни означает “прихожая” или “передняя комната”) — входное помещение здания перед основными комнатами или залами. Школьники на перемене мчались в вестибюль делать кастдев.

Сделаем онлайн-встречу про телеметрию на следующей неделе, напишу про это отдельно.

цитата

букинг проводил реальный эксперимент - насколько команде нужен тимлид, в нем участвовало более сотни команд из нескольких сотен, результаты сравнивались. Результат эксперимента - выяснили, какие процессы проседают, а какие - работают. Что интересно, операционка - работает, проседает развитие сотрудников. И дальше они тимлидов вернули, но начали ихз фокусирвоать на том, что важно, и не работает без тимлида.

Интересно. Буквально недавно думал на эту тему, похожие мысли возникали.
https://news.1rj.ru/str/mtsepkov/959

в прошедшую субботу мы с Алиной закончили очередной курс по нашей методике бизнес-анализа с добавлением ИИ

курс резко вырос в объёме с 8 до 16 часов, но всё равно было видно по участникам, что нужно больше времени, поэтому будем выходить на 24 часа

в целом пришлось туговато, тк оказалось, что апрель очень горячий месяц и есть много разных дел, которые надо делать параллельно (у меня конфа + 2 выступления на других)

пока сохраняются сложности с позиционированием, тк ряд аналитиков предполагают, что в ходе бизнес-анализа могут появиться функциональные требования к системе

у нас конечно другой подход, поэтому зашло не всем и до конца курса из 10 человек доплыли только 7.

напомню основные онтологические позиции нашего курса:

1. бизнес-требования — это НЕ цели конкретной инициативы (как у Вигерса и в BABOK) и само собой не любые высказывания, которые говорит «бизнес», а утверждения о свойствах бизнеса, включая его части, которые выдвигают уполномоченные организации и люди:

а) требования к организации целиком — «организация должно оказывать услуги населению», «организация должна сдавать налоговую отчётность в правильном формате» — авторы требований учредители, владельцы, регуляторы. источники — законы, устав, миссия и т.д.

б) требования к подразделениям — «департамент продаж должен принимать заказы от клиентов», «департамент разработки должен создавать программные продукты». авторы требований — владелец, корпоративный архитектор. источники — положения о подразделениях.

в) требования к участникам деятельности (оргролям) — «менеджер по продажам должен связаться с клиентом после получения заявки». авторы: владельцы процессов, эксперты-технологи. источники: рабочие инструкции, регламенты бизнес-процессов

2. бОльшая часть таких требований должна извлекаться из уже существующих внешних и внутренних НПА. если в ходе работы всплывают какие-то новые требования, они должны рассматриваться как часть обновления организационных решений и проходить соответствующий цикл рассмотрения, а не просто замыливаться как хотелки в разработку.

3. в проекте по улучшению ситуации на каком-либо участке бизнеса должны изучаться и приниматься во внимание все бизнес-требования, относящиеся к участку (15-30-50 требований), а не только цели изменений

4. важнейший источник потенциальных требований к решению — потребности исполнителей. в ответ на требования, которые предъявляет к их роли организация «логист должен планировать маршрут грузоперевозки» эксперт-технолог бизнес-процесса вместе в исполнителями может предложить технологию работы, а из неё уже конкретные потребности «логисту нужно видеть список подходящих под условия заказа маршрутов, чтобы выбрать целевой. при этом это не «пользовательские требования», тк пользователи как таковые не вправе требовать ничего сверх того, что им уже обещано в законах и договорах. это скорее идеи о необходимых свойствах решения, но сформулированные на языке информации и данных, а не на языке функций и интерфейсов.

5. если достаточно подробно выявить потребности исполнителей, то комплект бизнес-требований, потребностей, целей и ограничений служит мощным и достаточным основанием для создания качественных требований к решению.

6. чтобы выбрать хорошие цели инициативы, надо изучить существующие проблемы на выбранном участке бизнеса.

подробнее можно почитать у Алины в статье про её методику ЛЮСТРА

#пилоты #курсы

Всем привет. Давно не писал, а сегодня вдруг созрел #наброс на вентилятор.

Периодически (да что там периодически - часто!) сталкиваюсь в ИТ среде с майндсетом, что нужно делать либо "хорошо", либо никак. Специально пишу слово "хорошо" в кавычках, чтобы подчеркнуть, что чаще всего это однобокая оценка, которая оценивает только одну-две характеристики решения, например, соответствие красивым схемам в книжках и статьях или эмоциональному чувству прекрасного говорящего....

С точки зрения же заказчика (того самого мистического "бизнеса", которого принято упоминать шёпотом при закрытых сборищах ИТ-шников) эти оценки чаще всего непонятны и выглядят попыткой запутать.

Много раз говорил и повторю еще раз. Бизнес-закзачику нафиг не сдались все наши ИТ-шные заморочки. Все это - вынужденное зло, с которым приходится мириться. Заказчику нужно решение какой-то проблемы тем или иным способом. Мы будем нужны и востребованы ровно до тех пор, пока мы можем генерировать решение этой проблемы лучше, чем кто-то (или что-то - привет ИИ). Что значит лучше? Чаще всего это означает быстрее, дешевле, качественнее.

Кстати, еще прикол в том, что если пытаться делать в лоб то, что просят - то чаще всего получится полная хрень (еще один привет ИИ 😊). Но это не потому что заказчик глуп и ничего не понимает. Это от того, что глупо делать то, что просят.
Тут как пример вспоминается сюжет из записок врача Булгакова, когда к нему пришел пациент больной сифилисом с жалобой на горло и просил порошки для полоскания.

Делать надо то, что нужно. И важнейший в нашей отрасли навык - это умение выслушать, что просят, понять (иногда не с первой попытки) что нужно, и придумать/предложить как это сделать так, чтобы и заказчика устроило с точки зрения сроков/качества, ну и самим было хотя бы не очень противно.

Увы, часто бывает, что отличное решение с точки зрения заказчика может оказаться не очень красивым и удобным с точки зрения ИТ-специалиста, приходится искать компромисс. Еще и убеждать заказчика приходится, что это именно то, что ему нужно - это, кстати, отдельный навык 😉 Но что поделаешь - клиент платит...

про #моделирование

Я проповедую подход под названием Model Based System Engineering (MBSE) в применении к созданию программных систем. Изначально этот подход создавался для физических инженерных систем, но сами принципы вполне применимы в ИТ.

Суть в том, что мы на этапе анализа, проектирования не ТЗ на разработку пишем, а создаем структурированное описание в виде модели системы, точнее набор согласованных между собой моделей с разных точек зрения, включая, но не ограничиваясь теми, которые принято относить к описанию архитектуры. Модель включает в себя явное представление спецификации, требований к поведению системы в ключевых аспектах. На стадии разработки происходит реализация воплощения системы, соответствующей этой модели.

В инкрементальном процессе разработки у нас всегда есть какое-то актуальное состояние {модель + система}, и есть поток инкрементальных изменений модели и соответствующих изменених системы.

Цель создания и поддержания модели - снятие неопределенностей, подтверждение полезности будущей системы или её изменения до того, как будут потрачены существенные ресурсы на реализацию, поэтому модель еще на стадии проектирования должна позволять как-то оценить, насколько создаваемая система будет решать задачи, ради которых создается, а потом, после реализации, сравнить то что получилось с тем что ожидалось.

Важные моменты:
1. Глубина детализации моделей и технология их создания, поддержания и модификации должны быть достаточно легковесными, чтобы не превратить модели в обузу. Модель должна позволять до разработки быстро прогонять множество итераций обсуждения, верификации и модификации.
2. Способ представления моделей должен быть понятен заказчикам, разработчикам, тестировщикам и т.п., чтобы обсуждения и уточнения моделей были конструктивными.
3. Технология ведения моделями должна позволять представлять в виде отдельного читаемого артефакта инкрементальные изменения модели - это позволяет отказаться от ТЗ. На стадии анализа и проектирования очередного инкремента достаточно внести и согласовать в команде изменения в модель исходной системы, и артефакт, представляющий это изменение становится почти готовой постановкой на реализацию, останется лишь для полноты картины приложить к нему описание мотивации изменений.

Если на старте проекта договориться о составе и формате представления моделей, то дальше процесс становится почти прозрачным, с минимумом писанины. Звучит красиво, вопрос в том, какая же технология представления моделей позволяет работать таким образом. Удивительно, но пока что самый удобный и лаконичный способ моделирования, который удалось найти - это текстовые описания под гитом в markdown, plantuml, yaml и прочие лаконичные умеренно структурированные представления. Популярный в отрасли Confluence не удалось приспособить, он не позволяет явно управлять изменениями.

кому интересно, какое-то время назад рассказывал про всякие полезные модели
https://news.1rj.ru/str/sysarchthoughts/122

Привет всем. Так получилось, что меня некоторое время назад опять занесло в менеджеры.
Но я тут опять про архитектурное моделирование, ибо накипело.

"А что мы вообще тут делаем?" или почему архитектор - лучший друг менеджера

Я ненавижу ремонт. Терпеть не могу всю эту грязь, пыль, торчащие трубы и обломки плитки. Но куда деваться. Иногда все-таки надо и обои поменять, и плитку в ванной переложить.
Мой самый страшный сон - начинать ремонт без плана...

Закупили обои. Начали клеить - не хватило одной полосы. Надо еще целый кусок покупать, а в магазине эта серия уже распродана, новый рулон не попадает по цвету... Положили красивый керамогранит на "глаз", и теперь дверь стандартного размера не входит в проем - надо делать на заказ, это и время, и деньги. И оно всё тянется, тянется и тянется...

Примерно то же самое происходит в IT-проектах без предварительного архитектурного моделирования. Команда работает, старается, но что-то постоянно не стыкуется, результата нет, заказчик нервничает.

Архитектурная модель — это как чертёж дома перед стройкой. Она чётко определяет:
- ЧТО мы строим и из ЧЕГО, каких элементов оно состоит (микросервисы, модули, компоненты)
- КАК эти элементы взаимодействуют между собой (API, очереди сообщений)
- КАКИМИ свойствами должны обладать эти элементы (реализуемые функции, отказоустойчивость, производительность)

Когда есть такая модель, задачи на разработку формулируются не абстрактно ("доработать функционал оплаты"), а конкретно: "реализовать сервис платежного шлюза с поддержкой отмены транзакций и временем отклика до 200мс".

При тестировании мы проверяем не "работает/не работает", а соответствие элементов модели заявленным характеристикам.

Без архитектуры вы как прораб, который не знает, сколько этажей в строящемся здании и где будет вход. Можно ли в такой ситуации сказать, на каком этапе находится стройка? 🤔

Архитектурная модель — это общий язык для всех участников. Когда разработчик, тестировщик и менеджер говорят о "сервисе аутентификации", они имеют в виду одно и то же, а не три разные вещи.

Архитектура - это не просто квадратики и стрелочки, она определяет разбиение системы на части и задаёт названия этих частей, задаёт словарь, с помощью которого формулируются задачи на изготовление или доработку частей. Архитектура разбивает большую задачу на множество задач попроще, которые можно выполнять и отслеживать по отдельности. Это сильно упрощает и разработку, и отслеживание хода работ.

Так что если хотите знать, где вы находитесь в проекте и куда движетесь — начните с создания архитектурной модели. Иначе рискуете построить вместо дома что-то среднее между сараем и космическим кораблём. Причем сарай почему-то получается чаще...

P.S. Предыдущий текст был создан с использованием LLM.
Было интересно попробовать, насколько этот зверек способен реально помочь с написанием текстов. Не могу сказать, что он был в полной мере написан моделью, но модель сделала значительную часть работы.
В промте была задана тема, несколько тезисов, заданы стиль и ограничение на размер. Попросил добавить примеры.
В полученном тексте процентов 20-30 пришлось переписать полностью, в частности, название и начальную подводку. Остальную часть показалось достаточно слегка подредактировать с точки зрения стиля.
Интересно мнение аудитории - имеет ли право на жизнь такой метод или текст получается отстойный и так больше делать не надо?
- лучше писать чаще и вот так ☝️☝️☝️
(ставь 👻)
- или как раньше, но тогда будет сильно реже
(ставь 🤡)?

Нужны ли архитектору нотации или квадратики со стрелочками как искусство

Великий сыщик Шерлок Холмс считал важным не забивать голову лишней информацией. Помнится, узнав что Земля вращается вокруг Солнца, он пожелал поскорее про это забыть, как бесполезное в его жизни знание.

Иногда встречаю похожее отношение к формальным нотациям, дескать нах.. зачем мне вникать в эти ваши UML/ArchiMate/BPMN, большинство стейкхолдеров впадают в ступор при виде "правильных" диаграмм, а все обсуждения происходят вокруг рисунков на салфетках с квадратиками и стрелочками. Может и правда, строгие нотации - это излишнее, устаревшее, древнее го.. знание, которое нужно как можно скорее забыть и более не вспоминать?

Но вот мне так вааще не кажется. Нотации - это же не просто способ рисования, это способ структурировать и упорядочить мышление. Самое главное, как по мне, это не то как оно изображается, важно что именно изображается. Нотации содержат ценное знание о том, какие аспекты системы важно выделять, какие отношения вообще бывают между компонентами. Они задают язык, на котором мы думаем и потом разговариваем.

Рисуя "квадратики со стрелочками" на салфетке, архитектор осознанно упрощает сложную модель, которая живет у него в голове (или, может быть она даже выражена где-то в формальной диаграмме), и целенаправленно выбирает те элементы модели, которые важны для конкретного разговора. Но чтобы создавать сложную модель - неплохо бы иметь в голове язык для её создания. Можно, конечно, придумать свой язык, а потом обижаться и расстраиваться, что его никто не понимает, а можно использовать уже кем-то выстраданные, вымученные и вылизанные абстракции. Нотаций много, выбирай на вкус подходящую к конкретной задаче.

Картинка к предыдущему посту - рисунок Фредерика Фореста. Она предельно проста и лаконична. Но почему-то у меня не возникает сомнений, что для того, чтобы добиться этой простоты, лаконичности и выразительности, он довольно долго изучал и анатомию, и законы перспективы, ну и всё остальное, что там еще художники изучают.

Так что не игнорируйте нотации. Не обязательно им прямо строго следовать в каждой схеме, но важно, чтобы всегда могли объяснить, а что же именно кроется за обозначениями. А в идеале, чтобы и объяснять ничего не надо было, а "наброски на салфетке" были столь же точными и выразительными, как этот рисунок.

Я сейчас активно применяю AI в PDLC, так как канал архитектурный, поделюсь наблюдениями в части архитектуры на основе проектов с клиентами.

1. Мусор на входе - мусор на выходе. AI анализирует данные и здесь очень большая проблема. Сейчас же только ленивый не идет в AI и с чем сталкивается сразу на входе? Либо данных нет, либо они в ужасном состоянии, либо они с огромными пробелами, разбросаны, в итоге мы получаем фрагментированный и непригодный контекст. Если раньше можно было отложить на второй план управление тех долгом, не уделять должного внимания документации, то теперь, если вы хотите получить преимущество от использования AI, придется эти долги отдавать, иначе он выдает какую-то глупость. А отдать этого долг AI никак не помогает, у него просто нет входной иформации. И вот мы начинаем проводить event storming, архитектурые воркшопы, архитектурную базу знаний (структуру документации), чтобы ее можно было начать использовать с AI и только после этого (не совсем только) получить значительный эффект.
2. Для архитектуры очень важен бизнес-контекст, а он обычно тоже слабо описан. Структурированное описание бизнес-требований, с метриками и бизнес-архитектурой тоже становятся достаточно важными. Еще очень важным становится качественный discovery-цикл. AI может прекрасно обрабатывать со всех сторон результаты интервью клиентов, но если интервью проведено плохо – ничего не поможет, поэтому навык проведения интервью (а тут уже AI особо не поможет) тоже достаточно важен. Опрос AI в некоторой роли тоже не сильно помогает, потому что у каждой компании свой контекст, который публично не транслируется за пределы компании того, с кем проводите интервью.
3. Все-таки AI в ближайшее время на заменит архитектора, политику никто не отменял. Он даст гипотезы, подсказки, кучу материалов, но окончательное решение, валидация и ответственность будет все равно за архитектором, поэтому развитие архитектурных скилов критически важно (да, и навык критисеского мышления становится еще более важным, потому что AI порой выдает очень уверенно и обоснованно чепуху). Сильного архитектора, если у него в материалах порядок и у бизнеса в материалах порядок AI действительно очень сильно усиливает, проверено.

В общем, очень похоже на микросервисы. Микросервисы - это архитектурный стиль, один из многих. Чтобы спроектировать хорошее микросервисное решение, нужно хорошо понимать фундамент архитектуры, проектирования распределенных систем и DevOps и микросервисы тогда становятся всего лишь одним из стилей в арсеналей архитектора. С AI выглядит точно так же. Так что потребность в базе никуда не делась, а, видимо, стала даже более важной, иначе мы рискуем получить тысячи нерабочих решений и экспоненциальный рост техдолга.

Сегодня заканчивается подача заявок на осеннюю конференцию Flow в Питере

Если кто хотел выступить — самое время вписаться: https://flowconf.ru/callforpapers/

Моя тема:

Пошаговая технология проектирования архитектуры. Срываем покровы таинственности с самой непонятной и мутной дисциплины в современном ИТ.

Аннотация
Как начинать проектировать архитектуру как инженер, а не профан? Где взять целостный подход, если вокруг лишь фрагменты общей картины — DDD, атрибуты качества, интеграционные шаблоны, event storming, модели C4?

В этом докладе я расскажу о полной технологии проектирования архитектуры, которую мы разработали вместе с ноосферой в лице OpenAI (в основном книги издательства O'Reilly) и отточили с архитекторами информационных систем. Эта технология описана в открытой методичке и охватывает всё: от стратегических целей бизнеса до физической архитектуры.

В отличие от разрозненных методов, я собрал воедино:
- подходы от DDD до Attribute-Driven Design;
- чек-листы, шаблоны и таблицы, одобренные архитекторами;
- релевантные кейсы из сферы FinTech, ритейла и госсектора.

Этот доклад — приглашение в архитектуру как в процесс, в котором опытный ИТ-специалист может наконец выступить не просто наблюдателем игр демиургов, а активным деятелем, равноправным участником. Расскажу, с чего начать, как не утонуть в деталях и частностях и какие шаги ведут к обоснованной и устойчивой архитектуре.

Целевая аудитория
- опытные системные аналитики и разработчики, которые всё чаще сталкиваются с архитектурными задачами и хотят понимать, как проектировать архитектуру от и до, а не обрывками;
- руководители отделов анализа, проектирования и архитектуры, стремящиеся расширить архитектурную экспертность в команде;
- ИТ-преподаватели, авторы учебных курсов и руководители ИТ-школ, которым нужно разобраться, чему именно учить в сфере проектирования архитектуры.

С чем уйдут участники доклада
- с пониманием, какие шаги включает проектирование архитектуры согласно современным методикам;
- с готовыми шаблонами и чек-листами, которые можно использовать уже завтра;
- с инструментом, который помогает идти по предложенной технологии и создавать качественные артефакты в ходе проектирования в рабочем контексте;
- с ощущением, что архитектурное проектирование — это не сакральные знания, а устойчивая и постижимая за конечное время технология деятельности.

Погружение в Лейкхаус! Офигенная новость, ребят – качаем, наконец, DWH! В следующую среду 13-го августа в 18:30 msk в Zoom состоится встреча с Алексеем Белозерским, руководителем группы BigData Services VK Cloud.

Тема встречи “Погружение в Лейкхаус: почему все о нём говорят”.

Обсудим:
- Ретроспектива развития хранилищ данных. Принципы и компоненты. Озера vs DWH. ETL vs event streaming. Витрины. Базовые классы компонент: базы и подтипы, распределенные хранилища, стриминг и процессинг, in-memory grids. HDFS/Hadoop, Spark, колоночные базы (Clickhouse, Vertica etc), Greenplum/Greengage, Exasol, Snowflake и тд и трансформация в современный стэк, Trino/Iceberg/S3 или in-memory processing, аналитические embedded-базы типа DuckDB
- Тренды, разделение compute/storage, in-memory вычисления. Почему сейчас старые методы не едут. Какие требования от современного бизнеса и почему старые ХД не удовлетворяют им: рост объемов, рост аналитической нагрузки, требования регуляторов в разных странах.
- Как это все расшивается на "новом" стеке из Лейкхауса - и почему об этом все говорят.

Встреча состоится в Zoom, в этот раз она свободна и для сообщества Devhands Club (слушатели наших курсов) и для всех остальных желающих принять участие в живой дискуссии, но обязательно нужно быть авторизованным в Zoom.

Topic: Devhands Open Sessions: Lakehouse deep-dive (A. Belozersky)
Time: Aug 13, 2025 06:30 PM Istanbul/MSK
Zoom: https://us06web.zoom.us/j/85409552470?pwd=mfmnt6aRvmllJB1iLx8Ws4sdiIqVD3.1
Добарить в календарь: https://addcal.io/e/k0dw9sgjk8ai

Приходите, приводите друзей!

Не так давно я писал, что что нотации - это не просто способ рисовать квадратики со стрелочками, а в первую очередь - инструмент структурирования мышления аналитика или архитектора. Сегодня хочу показать это на конкретном примере — нотации EPC (Event-driven Process Chain).

Суть нотации EPC удивительно проста: мир состоит из событий (состояний) и функций (действий). События запускают функции, функции порождают новые события. Вокруг функций крутятся информационные сущности, являющиеся входными или выходными данными функций, а также ресурсы, необходимые для их работы (например, сервис-исполнитель функции). И всё, больше почти ничего не нужно для описания любого процесса.

При попытке описать автоматизируемый процесс терминах EPC невольно задаёшься вопросами:
- Какие события случаются в процессе или в каких состояниях бывают объекты, задействованные в процессе?
- Какие действия переводят объекты из одного состояния в другое?
- Кто или что выполняет эти действия?
- Какая информация и какие ресурсы нужны для выполнения действий?

Можно провести определенные параллели этой нотации с концепцией Event Storming. Оранжевые стикеры событий и синие стикеры команд в Event Storming — это почти те же события и функции из EPC, только в более неформальном виде. Но есть нюанс, в Event Storming подразумевается, что событие триггерит команду (т.е. событие достаточно для запуска команды), а в EPC связь между событием и функцией означает, что функция может исполняться только после наступления определенного события, т.е. событие/состояние необходимо для функции, но недостаточно. EPC дополнительно уделяет внимание информационным потокам, исполнителям и другим ресурсам, необходимым для работы функций.

В свое время эта нотация очень помогла мне осознать и структурировать процесс конфигурирования IDM системы. Наша система имела большое количество взаимосвязанных конфигурационных параметров и настроек. Технически все было не очень сложно, но из-за их количества и разбросанности по элементам конфигурации было очень сложно понять и объяснить другим с чего и как нужно начинать настройку, какие опции на какие аспекты поведения влияют.

И я начал просто выписывать процесс настройки по шагам: вот, настраиваю вот это (элемент-действие, например, настройка подключения к Active Directory), использую для этого вот такие элементы конфигурации (информационный объект - параметры конфигурации подключенной информационной системы), получаю в результате событие (например, подключена AD). Событие описывает новое состояние системы, в котором я получаю возможность переходить к следующим действиям - настройками других элементов.

Так постепенно я задействовал все элементы конфигурации в разных процессах конфигурирования и увязал процессы конфигурирования в цепочку через события. Дальше аналогичным образом описал использование элементов конфигурации в процессе функционирования системы как исполнителя действий с учетными записями в ответ события жизненного цикла сотрудника компании, от приёма на работу до увольнения.

Эти две диаграммы позволили четко увязать между собой элементы конфигурации, шаги процесса конфигурирования и собственно функции IDM - что и зачем нужно настроить для того, чтобы корректно работали определенные функции процесса управления учетными данными.

Не скажу, что я супер строго следовал нотации, когда рисовал эти модели. Как я уже говорил, важна не сама нотация, важна картина мира, которая создается с её помощью, аспекты, которые нотация подсвечивает и делает явными.

Именно про это ключевой тезис этого поста: нотация EPC - очень полезный инструмент для анализа процессов с целью выявления и структурированного документирования событий и промежуточных состояний самых разных систем, действий, приводящих к этим событиям и состояниям, ну и нужных для этого ресурсов.

Геннадий высказался очень созвучно моим мыслям. Просто продублирую его пост.

Сейчас в моду вошло философское течение, осмысляющее роль архитектора.

Выскажусь и я, раз уж всё равно толком ничего не успеваю.

Я отношусь к числу радикалов, считающих, что архитектура — это фикция. И рассматривать роль архитектора стоит через призму роли самой архитектуры.

Разложу по слоям:

- Бизнес-архитектура — это вовсе не архитектура, но при этом крайне важная штука.
- Корпоративная архитектура — это де-факто учет, секретариат при службе завхоза (офиса CTO).
- Архитектура приложений — это чистая инженерия, программная инженерия.
- Архитектура решений - это пересечение множества элементов структуры того, что назвается бизнес-архитектурой и множества элементов структуры приложений

Если напрямую связать, в том числе инструментально, то, что называют бизнес-архитектурой, с инженерией, то учетную функцию можно полностью автоматизировать.

А всё, чем я занимался за свою карьеру в должностях со словом «архитектор» в названии, — это либо чистая инженерия, либо сопряжение чего-то важного со стороны бизнеса с чем-то важным со стороны инженерии. И да, без такого сопряжения никакой инженерии и не бывает.