Привет, Максим! Давай начнем с твоего опыта? В каких проектах тебе удалось поучаствовать? Расскажи про класс систем, масштаб, предметную область?

Привет, Аня!

В основном, я занимался разработкой коммерческого ПО. Коробочного и заказного.

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

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

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

Работал над системами, пользователями которых было всего несколько человек, но от их работы зависела надёжность всей энергосистемы страны. И были системы, пользователями которых были миллионы людей. Например, билетная система для оператора московских электричек.

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

Как ты понимаешь, что такое архитектура? ;)

Классический вопрос. Никто не может сказать точно, что это такое )))

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

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

В скольких проектах тебе пришлось разрабатывать/ проектировать архитектуру с нуля?

Мне везло делать современные системы "с нуля". Но и "по наследству" системы доставались. В карьере архитектора и то, и другое важно.

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

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

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

Как ты обучался проектированию архитектуры?

Ну... на практике. Ставилась задача, и я её решал. И только потом фиксировал какими-то учебными курсами, которые помогали систематизировать знания и закрепить навыки. Так уж получается, что я по жизни занимаюсь уникальными задачами, иногда даже выступаю своего рода кризис-менеджером, который выводит почти безнадёжный проект в релиз. Хотя и провалы у меня тоже были. И на своих ошибках я стараюсь учиться. Но предпочитаю на чужих )

Можешь прямо сейчас начать проектировать архитектуру маленькой системы? что тебе для этого нужно? какие вопросы ты будешь задавать?

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

Как ты считаешь, должен ли архитектор быть немного аналитиком?

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

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

Иными словами, архитектор должен понимать потребности каждого заинтересованного лица, а это возможно, только если архитектор может побывать в его шкуре.

Что бывает с проектом, если архитектор реально ошибся?

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

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

Что это может быть за ошибка? Как не допустить? Есть ли у тебя примеры твоих ошибок, ошибок коллег?

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

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

Ещё пример. Исполнитель смотрит в Техническое задание, предоставленное заказчиком, и реализует систему исключительно по представленным там требованиям. Но требования там даны расплывчатые, и не со злого умысла, а от того, что у заказчика нет своих IT-специалистов нужного уровня. В итоге о том, что у пользователей есть свои цели и свои задачи, которые они намереваются решать с помощью системы, исполнитель не думает. Ещё бы: реализация строго по ТЗ — путь с минимальными затратами, но с меньшим качеством. А путь через реальные цели и задачи пользователей — это максимально возможное качество, но и максимум затрат (хотя это и не всегда так, но большинство РП исполнителя разницу не видят, увы). В итоге получается система, которую использовать очень сложно, если вообще возможно.

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

С чего начался твой карьерный путь? Как ты пришёл вообще в профессию?

Изначально в IT я не стремился совсем, хотя с компьютерными программами всегда управлялся неплохо. В конце школы мечтал заниматься астрономией, но так сложилось, что попал в МИФИ на факультет теоретической и экспериментальной физики. Так что по образованию я физик. Трудовую деятельность начал ещё студентом, и пять лет преподавал физику и астрономию в средней школе. Было интересно, но платили в конце 90-х немного. Три месяца удалось поработать менеджером по продажам, и это дало некоторые интересные навыки, которые потом мне сильно пригождались. Но я понял, что это не моя тема, и вернулся в МИФИ, занимался наукой. И там то мне и поручили разрабатывать программы для математического моделирования разных физических процессов. Через несколько лет я себя полностью посвятил разработке ПО. И вот уже лет двадцать непрерывно работаю в IT. Прошёл весь путь от программиста до главного IT-архитектора предприятия.


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

Спасибо, Максим, за интересный рассказ!