Темпы работы ИТ-подразделений корпораций сегодня сильно выросли, при том что на фоне тотального проникновения технологий в повседневную жизнь конечные пользователи все больше рассчитывают на постоянную и непрерывную доступность сервисов. Проектирование архитектуры корпоративного программного обеспечения уже не может опираться на традиционные практики и движется в направлении agile и непрерывных циклов выпуска. Между тем разрыв между agile-выпуском и практикой архитектурного планирования сегодня как никогда велик. Пути его устранения обсуждаются в работе [1], авторы которой, опираясь на опыт наблюдений за рынком и отраслевые исследования, описывают эволюцию роли архитектора ПО в современном мире.

Архитектор в индустрии ИТ

Роль архитектора в ИТ не имеет четкого определения, хотя сама эта должность встречается часто.

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

Фред Брукс предложил следующее определение роли архитектора [2]: архитекторы отвечают за концептуальную целостность проектируемой ими структуры, они имеют дело с более высоким уровнем абстракции, чем ответственные за реализацию, разработку и инженерное проектирование, — их интересуют основные компоненты системы, интерфейсы между ними и особенности взаимодействия. Они должны разбираться в концепциях, моделях и деталях реализации.

О роли архитекторов в рамках проектов скорой (agile) разработки спорят немало. Некоторые из тех, кто практикует agile, убеждены в том, что планировать архитектуру заранее не нужно, так как она сама «проявляется» по мере воплощения идей и рефакторизации проекта. Другие считают, что это справедливо лишь для простых, изолированных проектов. Но если инициатива масштабная, то не обойтись без планирования архитектуры и для успеха проекта будет важна соответствующая должность. В таблице приведено сравнение обязанностей архитектора при использовании традиционного и agile-подходов [1, 3].

Обязанности архитектора — традиционные и в эпоху agile-проектов

* Эпик — масштабная технологическая инициатива по совершенствованию технологических платформ, обеспечивающих реализацию бизнес-функций [www.scaledagileframework.com/enablers]

Обязанности архитектора — традиционные и в эпоху agile-проектов

 

Определение роли архитектора

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

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

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

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

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

 

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

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

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

Слагаемые успеха

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

Принятие решений

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

Коммуникация и взаимодействие

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

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

Участие в команде выпуска

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

Тестирование и развертывание

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

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

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

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

***

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

Литература

  1. M. Erder, P. Pureur. Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World. Morgan Kaufman, 2015.
  2. F.P. Brooks Jr. The Mythical ManMonth: Essays on Software Engineering, Addison-Wesley, 1975 (Фредерик Брукс. «Мифический человеко-месяц, или Как создаются программные системы». — Пер. с англ. — М., Наука, 1988, — 270 с.: ил.)
  3. D. Leffingwell. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise, Addison-Wesley, 2011.

Мурат Эрдер (m_erder@yahoo.com) — директор по ИТ-архитектуре и проектированию, компания, специализирующаяся на финансовых услугах; Пьер Пюре (pierre.pureur@gmail.com) — корпоративный архитектор, компания из рейтинга Fortune 500.

Murat Erder, Pierre Pureur, What’s the Architect’s Role in an Agile, Cloud-Centric World? IEEE Software, September/October 2016, IEEE Computer Society. All rights reserved. Reprinted with permission.