Приветствую, хабровчане. В далёком 1998-м я поступил в вуз на инженера-программиста и ещё в первом семестре реализовал свой первый коммерческий программный проект. Нет, это не курсовая для сокурсников, как вы могли бы подумать. Это была простенькая система складского учёта для знакомых коммерсантов (работает, кстати, и поныне). Забавно, но она и стала тем триггером, который через пару лет надолго привел меня в коммерческую продуктовую разработку сперва на позицию разработчика, потом тимлида, аналитика…

В минувшие годы десятилетия довелось заниматься и решениями, которые создают люди, и людьми, которые создают решения, а с недавних пор и сам тружусь архитектором решений. Казалось бы, карьерный сдвиг очевиден. Даже более того – кардинально изменились масштаб, сложность, инструменты, возможности... Но что примечательно, фактически я до сих пор остаюсь на стыке бизнеса и работающих программных систем. Так чем же в действительности занимаются архитекторы решений, и не вымрут ли они, прежде чем очередной первокурсник защитит свой диплом? Давайте разбираться.

Свой среди своих, чужих и всяких

Конечно, слово “архитектура” звучит хорошо и красиво. Да и “архи” («главный, старший») как бы намекает на лидерство. Наверное поэтому архитекторы, вслед за менеджерами, стали появляться повсеместно. И под архитектурой понимают кто что. Бывает даже так:

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

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

Москва не сразу строилась, так и с ростом рынка разработки ПО, объёмов и сложности задач устоялось и разделение ИТ-шных архитекторов прежде всего на:

• Архитекторов предприятия (Enterprise architect),

• Архитекторов решений (Solution architect),

• Системных архитекторов (Software architect, архитектор программного обеспечения).

Ключевое их отличие друг от друга – зона ответственности, класс решаемых задач и, если можно так выразиться, “угол зрения”.

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

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

И, наконец, системный архитектор, будучи экспертом в своем домене/продукте, выполняет детализацию и проработку требований на уровне конечных систем и продуктов. Его задача – подготовить ответ на вопрос “как поддержать требуемые изменения в моих системах?”. Ему позволительно не видеть охват всего решения, но он должен детально представлять необходимые изменения в границах систем своего домена (смотрит вглубь).

Когда, зачем и с чем

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

С чего всё начинается

Поскольку софт обыкновенно нужен для решения конкретных задач, процесс разработки чаще всего начинается с получения инициатив от бизнеса (так называемых business needs). Проблема на этом этапе обычно в том, что бизнесу бывает непонятно, кому или в кого он должен отгружать эти свои инициативы. Кто может оценить трудозатраты, сложность задачи, сориентировать по срокам с достаточным уровнем достоверности для возможности планирования работ? В первую очередь тот, за кем решение вопроса “как делать?”, то есть архитектор решений.

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

Архитектор решений в общении с бизнесом является представителем технических команд.

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

Каждый архитектор решений иногда и аналитик (аналитик требований).

Проект одобрен. Уже кодим или ещё рано?

Итак, первая польза от архитектора решений получена – инициатива оценена и получила путёвку в жизнь. Следом она одобрена, поставлена в планы. Что дальше?

В классическом жизненном цикле разработки ПО после анализа требований (на котором формируется набор аналитических артефактов – новые и изменённые требования к системам) идёт этап проектирования. Как при анализе требований для сложных задач отдельно разбираются требования к решению и системные требования, так и проектирование необходимо как для всего решения в целом, так и для каждой из его подсистем. Способ проектирования определяется принятым в организации архитектурным подходом, например, по тому же TOGAF, или модели Захмана, или ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011.  За его выбор, адаптацию и соблюдение отвечает, как мы помним, архитектор предприятия.

В целом этап проектирования состоит из двух основных этапов:

1. Разработка архитектурного решения архитектором решения для отражения изменений в ИТ-ландшафте предприятия.

2. Дизайн системной архитектуры системными архитекторами для отражения изменений в каждом компоненте, затронутых архитектурным решением.

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

1. Поддержать целостность решения на уровне архитектуры предприятия на этапе создания решения.

2. Обеспечить масштабируемость процессов разработки за счет распараллеливания работ по системному дизайну между различными продуктовыми командами.

Так в чём же заключается проектирование решения? Как правило, это и формирование состава компонентов (основной артефакт – компонентная диаграмма), и описание бизнес-логики взаимодействий между ними (возникает диаграмма последовательности), и формирование API взаимодействий между системами, как и трассировка на аналитические сценарии. Хорошей практикой является оформление всех требуемых архитектурных артефактов в используемом средстве проектирования, насколько оно это позволяет. На этапе подготовки архитектурного дизайна не следует забывать и о необходимости постановки задач в сторону команд разработки с описанием того, что им нужно сделать с системами в их зонах ответственности: разработать ли новые, доработать или сконфигурировать существующие.

Архитектор решения готовит принятые в компании архитектурные артефакты (структурные диаграммы и диаграммы поведения), определяет потребность в API, формулирует состав работ командам (SoW, Statement of Work).

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

Лучше один раз увидеть и обсудить, чем 100 раз услышать и что-то понять не так. Архитектор презентует спроектированное решение командам, синхронизируя восприятие решения между ними.

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

Началась разработка. Архитектор всё, не нужен?

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

Архитектор решений – значимый источник знаний о системах и решениях.

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

Архитектор помогает командам расти и повышать квалификацию.

Хабровчане, а вам приходилось примерять на себя роль архитектора решений? Каково это?