«Быть API между командами»: какие навыки нужны IT-архитектору в биотехе

Василий Юрташкин, директор Департамента IT-архитектуры BIOCAD, рассказывает, что на самом деле значит быть IT-архитектором и почему в биотехе эта роль похожа на работу дирижера — только вместо оркестра у тебя 20 систем, десятки команд и биореакторы, в которых рождаются молекулы будущих препаратов.

Как не превратить классную игру в баг-фест: зачем бизнесу IT-архитектура

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

Спойлер: проблема не в ваших друзьях (даже если раньше вам так казалось). Просто в архитектуру приложения не заложили устойчивость к нагрузкам — система спокойно держит пару человек, но при настоящем наплыве игроков начинает сыпаться по швам.

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

А вот как именно IT-архитекторы появляются на свет, какие скилы тут решают и как вообще не сломаться в этом прекрасном хаосе — рассказываю по порядку.

Кто такой IT-архитектор (и почему это не секретный инженер-супергерой)

Да, в теории есть стандарты ISO, и даже могучий TOGAF (про них любят спрашивать на собеседованиях). Но по-человечески архитектура — это:

1. Части системы: все элементы — от баз данных и серверов до модулей безопасности.
2. Связи: как данные гуляют между этими частями (и не теряются по пути).
3. Правила игры: что делать можно (и нужно), а чего категорически нельзя, чтобы вся конструкция не рассыпалась.

IT-архитектор — не человек-оркестр и не супергерой (к сожалению, костюмы у нас не полагаются). Это специалист, который:

• Проектирует схемы системы, чтобы она не только работала, но и не падала при первой нагрузке.
• Выбирает технологии (и поддерживает тот самый корпоративный «техрадар» — чтобы стек был живым и не зарастал реликтами).
• Сопровождает изменения — от R&D до релиза новой фичи в интернет-магазине или на производстве лекарств (даже такая тривиальная штука, как «не внедрять ничего без документации»).
• Анализирует требования бизнеса: иногда они звучат как «у нас всё должно летать», а на самом деле заказчикам надо всего лишь надежно хранить список пользователей.
• Следит за безопасностью (иначе ваши данные уйдут на черный рынок быстрее, чем синтезируется очередное моноклональное антитело).

И да — система без участия IT-архитектора вполне может прожить какое-то время. Но через пару лет она понравится только самым экстремальным квестерам: ни один смелый разработчик не рискнет туда лезть без шлема и подстраховки.

Карьерный трек: как превратить себя из разработчика в архитектора (и нужно ли для этого быть гуру во всём)

Карьерный путь архитектора не то чтобы строго регламентирован, но чаще всего выглядит так:

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

Иногда попадаются и те, кто совершает прыжок из бизнес-аналитики, но это все-таки редкость.

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

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

Хард-скилы IT-архитектора: как стать человеком-энциклопедией (но не пытаться быть всем за всех)

1. Разработка
   • Знание хотя бы одного языка программирования на уровне «мидл+» (идеально — и еще парочку на джун-уровне).
   • Применять вайб-кодинг: формулировать запросы для больших языковых моделей (LLM) и проверять, что нагенерила нейросеть.
   • Не надо быть супергением алгоритмов, но надо понимать, кто и как дорабатывает ваши решения.
     
     
2. Системы управления базами данных
   • Четко ориентируйтесь в реляционных и NoSQL-базах.
   • SQL нужен как соль в борще: без него — тоска. Практика — онлайн-тренажеры (например, sql-practice.com), плюс не бойтесь тренироваться на своих пет-проектах.
   • Оптимизация запросов и понимание, где у базы бутылочное горлышко.
     
     
3. Аналитика и моделирование
   • Знаете, что такое UML, BPMN и прочие «картиночки»? Умеете превратить бизнес-фантазии в схемы, а схемы — в работающие требования? Вы на верном пути.
   • Понимание, как живет бизнес-процесс и в каких местах его нельзя ломать ради удобства интеграции.
     
     
4. Инфраструктура и жизненный цикл ПО
   • Понимание сетей — must have. Хотите еще глубже? Разберитесь, почему на физическом заводе и в облаке архитектурные решения разные.
   • В CI/CD важно не столько уметь самостоятельно настраивать инструменты автоматизации, сколько понимать, где автоматизация действительно ускоряет разработку, а где может ее замедлить.
     
     
5. Информационная безопасность
   • Скандалы, утечки, эксплойты — архитекторы должны их не только знать, но и предвосхищать.
   • В бонус — разбираться в регуляторике и законах, актуальных для вашей сферы. Особенно в биотехе и фарме, где ГОСТ и GxP-стандарты всегда рядом: сначала кажутся суровыми, а со временем становятся надежными союзниками при проектировании архитектуры.
     
     
6. Прослеживать тренды
   • Нетворкинг, тусовки, конференции и даже визиты на собеседования (именно так узнаёшь, чем живет рынок).
   • В BIOCAD есть курсы — как для начинающих, так и для опытных специалистов, — где можно обновить или получить самые свежие знания по стеку.
     
     
7. Главное — не пытаться объять необъятное
   • Не нужно знать всё-всё на свете — для этого есть коллеги. Важно уметь объясняться с каждым: и с разработчиком, и с аналитиком, и с инженером поддержки — чтобы вместе строить интеграции, сшивать данные и находить слабые места решений.
     
     

Но даже обладая всеми необходимыми хард-скилами, архитектор может легко «наступить на грабли». Вот самые частые ошибки и их последствия на реальных кейсах:

Софт-скилы IT-архитектора: ни одна схема не летает без коммуникации

Всё вышеперечисленное — только половина картины. Вторая половина — как вы общаетесь, аргументируете и строите доверие.

1. Коммуникация
   • Архитектор — это переводчик с IT-шного на человеческий и обратно. Пояснять сложные вещи простыми словами, слушать, спокойно аргументировать и выстраивать диалог даже с теми, кто мыслит совсем по-другому.
   • Советую читать книжки по логике и — важный лайфхак из жизни — не бояться задавать вопросы и просить совет. К слову, многие боятся, что их вопрос покажется глупым, но практика показывает: именно такие «простые» вопросы часто двигают процесс вперед.
     
     
2. Управление и запуск проектов
   • Обычно эта прослойка нужна именно в старте чего-то нового — уметь собрать команду, договориться, убедить, что «ящик Пандоры» еще не открыт.
     
     
3. Стратегическое мышление
   • В архитектуре редко дают сделать что-то идеальное во всех смыслах. Реальная жизнь — это постоянные «ползунки»: хочешь скорость — теряешь надежность, хочешь дешевле — теряешь гибкость. Всегда надо думать, что станет с этим выбором через год или три.
     
     
4. Конфликты — неизбежны
   • Честно: почти каждая архитектурная задача — это столкновение интересов разных отделов. Важно найти компромисс или так убедительно объяснить свою позицию, чтобы спор исчез сам собой.
     
     
5. Гибкость
   • Иногда ваши старания так и остаются «на полке», а иногда — запускаются в продакшн. Главное — не переживать. Как в классике: лучше уметь (иметь) и не нуждаться, чем наоборот.
     
     
6. Прокачка — всегда
   • Корпоративные курсы, реальные проекты, книги — например, «Государь» Макиавелли (читать обязательно, особенно второй раз — на продвинутом уровне).

Всему этому можно научиться — и внутри биотеха тоже

Не волнуйтесь: абсолютное большинство этих скилов осваивается «в бою», по ходу работы — еще на уровне обычного разработчика или аналитика. Ваша задача — впитывать знания и чужой опыт как губка: не стесняться спрашивать и, главное, слушать ответы.

В биотехе, как и в других сферах, архитектура часто работает на той тонкой границе, где заканчивается магия R&D и начинается суровая реальность GMP, GxP, тысячи регуляторных требований, десятки интеграций — и всё надо связать в одну реально работающую машину.

В BIOCAD можно не только получить этот опыт, но и вырасти дальше. Есть обучение, есть кадровый резерв, есть настоящая катушка сложных задач, с которыми точно не заскучаешь.

Итоги по-архитекторски

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