5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру и канал на Facebook.

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

На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.

Доклады были краткими и по сути, а обсуждение очень живое и развернутое.



Далее мои заметки по ходу докладов.

Доклад 1
Ключевые навыки архитектора решений в проектах «с нуля»

Геннадий Круглов
Certified SOA Architect, ктн

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

1. Вовлечение бизнеса.
2. Вовлечение инженеров.
3. Прототипирование.
4. Выбор архитектурного стиля и технологического стека (микросервисы, монолит, SOA).
5. Разработка драфта архитектуры.
6. Демонстрация заказчику.
7. Проектирование решения.
8. Документирование арх решения.
9. Архитектурный надзор.

Основные моменты выступления:

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

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

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

Навыки, которые по мнению докладчика, нужны архитектору:

• Навыки коммуникации (убеждения, ведения переговоров)
• Презентации
• Произведения мозговых штурмов и воркшопов
• Знание архитектурных стилей
• Широкий кругозор современных технологий (важно понимать сильные и слабые стороны)
• Навыки проектирования решений и приложений
• Навыки разработки с использованием разных фреймворков, продуктов и языков программирования
• Знание фреймворков документирования решений
• Понимания разных типов SDLC (systems development life cycle)
• Широкая сеть профессиональных связей
• Навыки в управлении командами разработки

Доклад 2
Архитектурное сопровождение ИТ проектов

Дмитрий Романов, ИТСК

Проектирование ИТ решений, архитектурное сопровождение проектов, около 80 проектов в год, около 50 архитекторов участвует в процессе.

Служба главного ИТ архитектора определяет техническую политику в области ИТ, которую исполняли ИТ архитекторы проектов. Отвечая на вопрос, где архитектор обычно набирает нужную экспертизу, Дмитрий указал следующие источники:

1. Опыт — создание аналогичных систем
2. Коллеги — кто то в рамках компании или в других компаниях
3. Вендор — консультации с разработчиками
4. Тематические форумы
5. Технопарк — апробации или песочница на базе Технопарка

Рассматривая вопрос о необходимости роли архитектора в ИТСК, Дмитрий указал, что архитектор ИТ-проекта нужен, чтобы, например, не возникло ситуации, когда 1 год делали проект, потом полгода поработали и поняли, что нет масштабирования, а потом 2 года переделывали. Важно четкое понимание, что предложенную архитектуру можно реализовать. В зависимости от методологии управления проектом, в ИТСК архитектор либо входит в команду (если это agile), либо входит в экспертную группу проекта.

Доклад 3
Архитектура в ИТ-проектах организации: основные акценты

Иван Лукьянов, Департамент информационных технологий г. Москвы, продукт “Государственные услуги и МФЦ”

Профессиональная биография докладчика: разработчик в Диасофт, руководитель команды разработки (BSC Praha), ведущий консультант (Неофлекс), руководитель направления дирекции архитектуры и стратегии в Альфа-банке, начальник отдела развития архитектуры (ДИТ).
Иван рекомендует начать работу с описания существующей архитектуры (as is), сформировать целевую архитектуру (to be) и анализируя разницу между точками, “где организация сейчас” и “куда организация хочет попасть” описать шаги по приведению системы в целевое состояние.
Основные акценты ИТ-проектов в части архитектуры:

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

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

Утверждены архитектурные принципы, разработан документ “Архитектурно-технологическое решение”, где описываются бизнес требования к решениям и проект их реализации.

Черты архитектора:

• Коммуникабельность. Важны коммуникации с руководством, с исполнителями, с поддержкой, с менеджерами и тестировщиками. Архитектор должен играть роль переводчика — переводить с языка бизнеса на технический и обратно.
• Обязательное требование — опыт разработчика (хорошо если ещё и аналитика).
• Уважение к коллегам.
• Постоянное развитие.

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

Доклад 4
Архитектор ИТ-проекта: одна из возможных точек зрения

Евгений Асламов Aslamov, ведущий архитектор, ГК Ланит.

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

На взгляд Евгения, говоря про архитектора в заказной разработке, мы попадаем в зависимость от различных факторов — сроков, бюджета, команды, сложности и объёма задач. Как правило, в сложных проектах (несколько тысяч пользовательских сценариев, интеграция с парой десятков систем, большие объёмы данных, суровые требования к High Availability&Disaster Recovery) архитектурные задачи закрываются группой специалистов — архитекторов. На более скромных проектах с этими задачами может справиться один человек и не всегда выделенный под задачи архитектор — его роль может быть совмещена с другими ролями — ведущего разработчика или аналитика.

Архитектор, как и любой участник команды, работает в некотором контексте. Один из набросков такого контекста:

Заказчик

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

Команда

• менеджеры;
• аналитики;
• разработка;
• DevOps;
• служба качества;

Контракт

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

В рамках контекста архитектор или группа архитекторов выполняет следующее:

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

Отвечая на вопрос «Как он это делает?», Евгений затронул прежде всего вопрос выработки архитектурных решений. Было выделено несколько составляющих, помогающих в этой задаче:

• Опыт и аналогии. Это один их самых главных активов архитектора. И его нужно постоянно увеличивать — не застаиваться в одном проекта, технологии и т.п.
• Кругозор. Можно использовать не свой опыт — опыт коллег, опыт сообществ, стандартов.
• Прототипы. В случае использования нового, неопробованного или с видимыми рисками, прототипирование необходимо. При этом важно корректно и точно сформулировать вопросы, на которые должен отвечать прототип, иначе это может только ухудшить ситуацию.
• Защита своих решений. Перед командой проекта, перед архитектурным комитетом (своим или заказчика), перед самим собой. В качестве одного из решений может быть внедрение (полное или отдельных элементов) ATAM — Architecture Tradeoff Analysis Method. В ряде наших проектов, например, защита решений реализована как презентация ключевых решений коллегам вне проекта для получения альтернативного мнения и замечаний.

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

Статья Евгения на habr «Готовим проект в Sparx Enterprise Architect. Наш рецепт».

Вопросы и ответы

Далее была секция вопросов и ответов, самые запомнившиеся можно прочесть ниже.

Откуда берутся архитекторы?

Геннадий:
Software architects — бывшие тим лиды или тех лиды или ведущие разработчики.
Дмитрий:
Архитекторы берутся из разработчиков из консультантов, с широкой экспертизой.
Разработчик умеет говорить и рисовать презентации — solution архитектор.
Евгений:
В целом, из любой части — из разработки, тестирования, управления проектом и т.п. Но в любом случае, какие-то технические специализации помогают — их не приходится развивать с нуля.
Пример из личного опыта: в компанию Ланит взяли студента из мехмата МГУ, умный, коммуникабельный человек без звёздной болезни. Немного поработал в аналитике, разработке, общении с заказчиком. В итоге стал прикладным архитектором в нашей компании.
Иван:
Из разработчиков. Если есть хороший разработчик, то он и дальше может углубляться в языки программирования, развиваться вглубь. Но если, ему в свое время, стало любопытно как рождается техническое задание, кто анализирует, кто принимает решение надо это или не надо делать, то это сигнал к тому, что специалист встал на стезю начинающего архитектора. Следующий уровень любопытства — как решение рождается в целом, на уровне бизнеса. Как можно показать руководителю организации, что ему это нужно, а что нет. При описании роли архитектора Грегори Хопп (Gregor Hohpe) использует метафору лифта . Каждый этаж, где останавливается лифт, это некоторый уровень в организации: первый этаж — машинный зал — это разработчики, производство; последний этаж — руководство организации. Воплощая архитектуру в жизнь, архитектор коммуницирует на каждом из этажей (с первого до последнего) и на каждом этажей он должен справляться с различными трудностями — технологическими, политическими, коммуникационными.

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

Как должны делиться полномочия между руководителем проекта и архитектором?

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

В случае, если баланс смещен в сторону РП — можно получить проект в срок, но не работающий или не масштабируемый. А, если в сторону архитектора, то можно получить прекрасный проект, когда он уже никому не нужен. Это как ответить на вопросы «Кого ты больше любишь — маму или папу?».

Как быть корпоративным архитекторам, у которых большой поток разных проектов?

Иван:
В больших организациях более 2000 человек сделать одну корпоративную архитектуру и ей следовать практически невозможно. В ДИТ сделано разделение на продукты (сервисы), у каждого продукта есть свой стек технологий, своя архитектура. Что касается корпоративной архитектуры — она больше нужна акционерам, чтобы они понимали, куда движется организация с точки зрения развития архитектуры. Для этой цели в организациях часто выделяется роль Chief IT architect, основная задача которой — определять общий ландшафт корпоративной архитектуры.

Как строится взаимодействие между проектным архитектором и корпоративным архитектором?

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

Можно посмотреть на это с точки зрения value — кто приносит больше value. Если решения работают, то там и value. Enterprise architecture сама по себе ценность не приносит, а приносит она ценность через solution архитекторов, которые уже реализуют конкретные задачи.

Никому не нужны generalists — все меньше нужны люди, которые знают ничего обо всем. Лучше уметь отвечать на конкретные вопросы, например, достаточно ли тут RabbitMQ или нужна Kafka.

Как организованы архитектурные репозитории предприятия?

Есть ли какие-то комплексные модели, которые можно обсчитать, проверить и т.д.?

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

Послесловие

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

Спасибо Максиму Смирнову и ВШЭ за организацию круглого стола архитекторов!
Также огромное спасибо авторам докладов (Евгению Асламову, Геннадию Круглову, Ивану Лукьянову) за подготовку этого текста, так как изначальные заметки писались по ходу докладов и содержали ошибки и неточности, которые были исправлены.

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