- PVSM.RU - https://www.pvsm.ru -
5 сентября в Москве состоялся Круглый стол «Архитектор ИТ проекта» в ВШЭ. Организатор круглого стола, Максим Смирнов, ведет блог про архитектуру [1] и канал на Facebook [2].
Я очень рада, что такие события проводятся. Стать классным архитектором было и остается моей мечтой. Мне очень долго было не понятно, как вообще попадают в архитекторы, как нужно развиваться и какие направления выбирать, чтобы они привели к архитектуре, и, я думаю, что такие вопросы возникают не только у меня. Замечательно, что есть сообщество, куда можно прийти и задать вопросы архитекторам.
На круглом столе было представлено 4 доклада по 15-20 минут, после чего были вопросы из аудитории и обсуждение.
Доклады были краткими и по сути, а обсуждение очень живое и развернутое.
Далее мои заметки по ходу докладов.
Геннадий Круглов
Certified SOA Architect, ктн
В рамках выступления были затронуты основные этапы архитектурного процесса:
Основные моменты выступления:
Желательно сделать прототип, чтобы показать его бизнесу.
При выборе архитектурного стиля по-возможности нужно вовлечь разные стороны – разработчиков, безопасность, эксплуатацию.
При разработке эскиза нужно сделать разные срезы архитектуры — бизнес, технологии, безопасность.
По возможности необходимо привлекать людей, которые потом будут непосредственно работать с этой частью системы.
После обсуждения с заинтересованными лицами, демонстрируется прототип. Если проект стартует, выполняется более детальная проработка каждого уровня архитектуры.
При разработке необходима синхронизация с архитектором, чтобы проверить, что процесс идет по выбранному пути.
Навыки, которые по мнению докладчика, нужны архитектору:
Дмитрий Романов, ИТСК
Проектирование ИТ решений, архитектурное сопровождение проектов, около 80 проектов в год, около 50 архитекторов участвует в процессе.
Служба главного ИТ архитектора определяет техническую политику в области ИТ, которую исполняли ИТ архитекторы проектов. Отвечая на вопрос, где архитектор обычно набирает нужную экспертизу, Дмитрий указал следующие источники:
Рассматривая вопрос о необходимости роли архитектора в ИТСК, Дмитрий указал, что архитектор ИТ-проекта нужен, чтобы, например, не возникло ситуации, когда 1 год делали проект, потом полгода поработали и поняли, что нет масштабирования, а потом 2 года переделывали. Важно четкое понимание, что предложенную архитектуру можно реализовать. В зависимости от методологии управления проектом, в ИТСК архитектор либо входит в команду (если это agile), либо входит в экспертную группу проекта.
Иван Лукьянов, Департамент информационных технологий г. Москвы, продукт “Государственные услуги и МФЦ”
Профессиональная биография докладчика: разработчик в Диасофт, руководитель команды разработки (BSC Praha), ведущий консультант (Неофлекс), руководитель направления дирекции архитектуры и стратегии в Альфа-банке, начальник отдела развития архитектуры (ДИТ).
Иван рекомендует начать работу с описания существующей архитектуры (as is), сформировать целевую архитектуру (to be) и анализируя разницу между точками, “где организация сейчас” и “куда организация хочет попасть” описать шаги по приведению системы в целевое состояние.
Основные акценты ИТ-проектов в части архитектуры:
В компании сейчас разработана собственная методология, включающая шаблоны используемых в работе документов. Были использованы принципы TOGAF [3] и Gartner. Утверждены архитектурные принципы, разработан документ “Архитектурно-технологическое решение”, где описываются бизнес требования к решениям и проект их реализации.
Черты архитектора:
Архитектура — это не неподвижный памятник, отлитый в граните, а живое, эволюционирующее представление того, чего мы хотим достичь с точки зрения поддержки бизнеса.
Евгений Асламов Aslamov [4], ведущий архитектор, ГК Ланит.
Путь Евгения к роли архитектора: разработчик, аналитик, руководитель проектов.
В ходе краткого рассказа автор затронул несколько вопросов, связанных с ролью архитектора в заказной разработке: что его окружает, что он делает и как он это делает.
На взгляд Евгения, говоря про архитектора в заказной разработке, мы попадаем в зависимость от различных факторов — сроков, бюджета, команды, сложности и объёма задач. Как правило, в сложных проектах (несколько тысяч пользовательских сценариев, интеграция с парой десятков систем, большие объёмы данных, суровые требования к High Availability&Disaster Recovery) архитектурные задачи закрываются группой специалистов — архитекторов. На более скромных проектах с этими задачами может справиться один человек и не всегда выделенный под задачи архитектор — его роль может быть совмещена с другими ролями — ведущего разработчика или аналитика.
Архитектор, как и любой участник команды, работает в некотором контексте. Один из набросков такого контекста:
Заказчик
Команда
Контракт
В рамках контекста архитектор или группа архитекторов выполняет следующее:
Отвечая на вопрос «Как он это делает?», Евгений затронул прежде всего вопрос выработки архитектурных решений. Было выделено несколько составляющих, помогающих в этой задаче:
Вместо заключения: одной из неформальных задач архитектора, да и любого специалиста, который любит своё дело — популяризация знаний, технологий, подходов, умений, которые позволят команде решать задачи на проекте более эффективно и с бОльшим удобством.
Статья Евгения на habr Готовим проект в Sparx Enterprise Architect. Наш рецепт [6]
Далее была секция вопросов и ответов, самые запомнившиеся можно прочесть ниже.
Геннадий:
Software architects — бывшие тим лиды или тех лиды или ведущие разработчики.
Дмитрий:
Архитекторы берутся из разработчиков из консультантов, с широкой экспертизой.
Разработчик умеет говорить и рисовать презентации — solution архитектор.
Евгений:
В целом, из любой части — из разработки, тестирования, управления проектом и т.п. Но в любом случае, какие-то технические специализации помогают — их не приходится развивать с нуля.
Пример из личного опыта: в компанию Ланит взяли студента из мехмата МГУ, умный, коммуникабельный человек без звёздной болезни. Немного поработал в аналитике, разработке, общении с заказчиком. В итоге стал прикладным архитектором в нашей компании.
Иван:
Из разработчиков. Если есть хороший разработчик, то он и дальше может углубляться в языки программирования, развиваться вглубь. Но если, ему в свое время, стало любопытно как рождается техническое задание, кто анализирует, кто принимает решение надо это или не надо делать, то это сигнал к тому, что специалист встал на стезю начинающего архитектора. Следующий уровень любопытства — как решение рождается в целом, на уровне бизнеса. Как можно показать руководителю организации, что ему это нужно, а что нет. При описании роли архитектора Грегори Хопп (Gregor Hohpe) использует метафору лифта [7]. Каждый этаж, где останавливается лифт, это некоторый уровень в организации: первый этаж — машинный зал — это разработчики, производство; последний этаж — руководство организации. Воплощая архитектуру в жизнь, архитектор коммуницирует на каждом из этажей (с первого до последнего) и на каждом этажей он должен справляться с различными трудностями — технологическими, политическими, коммуникационными.
Архитектор умеет собирать нужную информацию и донести до каждого уровня. Фактически, он выступает в роли медиатора между участвующими сторонами.
Должен быть баланс между полномочиями. Полномочия архитектора лежат в технической части, а руководителя проекта — в организационной.
В случае, если баланс смещен в сторону РП — можно получить проект в срок, но не работающий или не масштабируемый. А, если в сторону архитектора, то можно получить прекрасный проект, когда он уже никому не нужен. Это как ответить на вопросы «Кого ты больше любишь — маму или папу?».
Иван:
В больших организациях более 2000 человек сделать одну корпоративную архитектуру и ей следовать практически невозможно. В ДИТ сделано разделение на продукты (сервисы), у каждого продукта есть свой стек технологий, своя архитектура. Что касается корпоративной архитектуры — она больше нужна акционерам, чтобы они понимали, куда движется организация с точки зрения развития архитектуры. Для этой цели в организациях часто выделяется роль Chief IT architect, основная задача которой — определять общий ландшафт корпоративной архитектуры.
Важно общение. Нужно выстраивать коммуникации и просто общаться.
Проектному архитектору может быть не нужно знание корпоративной архитектуры, но важно знать с кем будет интеграция и на что будет влияние.
Важно делать архитектурные комитеты, возможно знать туда не только корпоративных архитекторов, но и проектных.
Можно посмотреть на это с точки зрения value — кто приносит больше value. Если решения работают, то там и value.
Enterprise architecture сама по себе ценность не приносит, а приносит она ценность через solution архитекторов, которые уже реализуют конкретные задачи.
Никому не нужны generalists — все меньше нужны люди, которые знают ничего обо всем. Лучше уметь отвечать на конкретные вопросы, например, достаточно ли тут RabbitMQ или нужна Kafka.
Есть ли какие-то комплексные модели, которые можно обсчитать, проверить и т.д.?
Евгений: у нас есть архитектурный репозиторий, но нет автоматизации расчёта каких-либо метрик. Связи между моделями и сами модели позволяют рассматривать архитектуру как нечто целостное, а не набор картинок. Одна из задачи репозитория — и обеспечить анализ влияния. На этой основе можно делать оценку стоимости изменений.
Очень здорово, что можно прийти и послушать архитекторов, познакомиться с сообществом. Такие встречи для меня всегда возможность понять, куда нужно копать, чтобы найти необходимые знания. Кроме того, можно обсудить рабочие кейсы и получить рекомендацию.
Спасибо Максиму Смирнову и ВШЭ за организацию круглого стола архитекторов!
Также огромное спасибо авторам докладов (Евгению Асламову, Геннадию Круглову, Ивану Лукьянову) за подготовку этого текста, так как изначальные заметки писались по ходу докладов и содержали ошибки и неточности, которые были исправлены.
На фото замок Шамбор во Франции [8], говорят каждый владелец пристраивал по своей башенке. Иногда, архитектура проекта выглядит именно так. На мой взгляд, архитектор нужен для того, чтобы было все красиво и по-возможности просто, чтобы даже с кучей башенок в разном стиле, все равно получился бы красивый замок.
Автор: KristinaMyLife
Источник [9]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/arhitektura-prilozhenij/301492
Ссылки в тексте:
[1] блог про архитектуру: https://mxsmirnov.com/
[2] канал на Facebook: https://www.facebook.com/mxsmirnov.arch/
[3] TOGAF: http://www.opengroup.org/subjectareas/enterprise/togaf
[4] Aslamov: https://habr.com/users/aslamov/
[5] ATAM — Architecture Tradeoff Analysis Method: https://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_method
[6] Готовим проект в Sparx Enterprise Architect. Наш рецепт: https://habr.com/company/lanit/blog/352826/
[7] Грегори Хопп (Gregor Hohpe) использует метафору лифта : https://martinfowler.com/articles/architect-elevator.html
[8] Шамбор во Франции: https://www.chambord.org/en/
[9] Источник: https://habr.com/post/432386/?utm_campaign=432386
Нажмите здесь для печати.