Моё видение IT-ландшафта и путь, на котором оно сложилось

Коротко. Я архитектор систем, в которых сбой стоит дорого: медицинских, государственных, финансовых. Взгляд, изложенный ниже, сложился не из чтения отчётов, а из перехода от написания кода к ответственности за решения, цена ошибки в которых измеряется не количеством дефектов. Если коротко, то он такой: архитектура это не схема, а страховка, и покупается она до того, как понадобится.

Практика с 2004 года, работа с AI-системами с 2023 года, проекты для заказчиков в 14 странах. Базируюсь в Ришон-ле-Ционе.

Как это складывалось

Двухтысячные: своё дело и понимание цены решений

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

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

Десятые: системы, где ошибка стоит не дефекта

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

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

Двадцатые: AI внутри регулируемых процессов

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

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

С чем ко мне приходят

Формулировки разные, но задача почти всегда одна из четырёх.

• Пилот не выходит в работу. Модель показывает хорошие числа на подготовленных данных и не переживает встречу с реальным потоком и с людьми, которые должны ей пользоваться.
• Унаследованное душит развитие. Каждое изменение требует ручной работы, и вопрос стоит не «как переписать», а «что модернизировать и в каком порядке».
• Решения навязаны извне. Набор систем сложился из отдельных закупок, общей схемы нет, и каждая интеграция делается заново.
• Появились требования, которых раньше не было. Данные, которые можно было хранить как угодно, теперь нельзя, и это меняет не настройки, а структуру.

Общее у всех четырёх то, что вопрос уже не в выборе технологии. Спор о том, какая библиотека лучше, почти никогда не является настоящим вопросом.

Во что я верю по части IT-ландшафта

Короткий список убеждений, на которых строится работа. Они спорные, и я готов их обсуждать.

1. Архитектура покупается заранее или не покупается вовсе. Она ценна ровно тем, чего не произошло, и поэтому её ценность невозможно предъявить постфактум. Это неудобно для продажи и не меняет сути.
2. Модернизация почти всегда дешевле замены, и почти всегда её недооценивают, потому что переписать заново звучит проще, чем разобраться.
3. Ограничения снаружи важнее предпочтений внутри. Если система работает с медицинскими или платёжными данными, требования к ней приходят не от команды, и архитектура следует из них, а не наоборот.
4. Решение, не записанное с обоснованием, не является решением. Через год его будут обсуждать заново, и это самая дорогая из привычек.
5. Хороший консультант задаёт вопросы, а не знает все ответы. Из них самый полезный обычно звучит как «а что будет, если этого не делать вовсе».

Как я работаю

Я независимый архитектор и не получаю от поставщиков ничего за рекомендацию. Практическое следствие: вывод «оставить как есть» или «вам не нужен проект, у вас проблема в процессе» для меня нормальный результат работы, а не её провал.

Участвую лично, а не через отчёт: разбираюсь в том, что построено, говорю с теми, кто этим пользуется, и остаюсь до тех пор, пока решение не заработает и не станет понятным вашей команде. Формат прозрачный, почасовой или фиксированным объёмом, на ваш выбор.

Подробнее по отдельным темам: чем консалтинг отличается от аутсорса, как устроена архитектура решения и с какой задачи начинать с AI.