Темпы работы ИТ-подразделений корпораций сегодня сильно выросли, при том что на фоне тотального проникновения технологий в повседневную жизнь конечные пользователи все больше рассчитывают на постоянную и непрерывную доступность сервисов. Проектирование архитектуры корпоративного программного обеспечения уже не может опираться на традиционные практики и движется в направлении agile и непрерывных циклов выпуска. Между тем разрыв между agile-выпуском и практикой архитектурного планирования сегодня как никогда велик. Пути его устранения обсуждаются в работе [1], авторы которой, опираясь на опыт наблюдений за рынком и отраслевые исследования, описывают эволюцию роли архитектора ПО в современном мире.
Архитектор в индустрии ИТ
Роль архитектора в ИТ не имеет четкого определения, хотя сама эта должность встречается часто.
Обычно архитектор — это специалист, принимающий ключевые решения о структуре и поведении системы. Наиболее распространена должность архитектора ПО, есть также архитекторы сетей, сред хранения, проектировщики информационной архитектуры и архитекторы систем безопасности. В сущности, в любой предметной области, связанной с ИТ, есть специалисты, занимающиеся архитектурным планированием. Можно перечислить следующие характеристики архитекторов: они имеют глубокие познания в своей предметной области; планируя структуру системы, работают с уровнями абстракции, более высокими, чем исполняемый код; располагают полномочиями принятия решений.
Фред Брукс предложил следующее определение роли архитектора [2]: архитекторы отвечают за концептуальную целостность проектируемой ими структуры, они имеют дело с более высоким уровнем абстракции, чем ответственные за реализацию, разработку и инженерное проектирование, — их интересуют основные компоненты системы, интерфейсы между ними и особенности взаимодействия. Они должны разбираться в концепциях, моделях и деталях реализации.
О роли архитекторов в рамках проектов скорой (agile) разработки спорят немало. Некоторые из тех, кто практикует agile, убеждены в том, что планировать архитектуру заранее не нужно, так как она сама «проявляется» по мере воплощения идей и рефакторизации проекта. Другие считают, что это справедливо лишь для простых, изолированных проектов. Но если инициатива масштабная, то не обойтись без планирования архитектуры и для успеха проекта будет важна соответствующая должность. В таблице приведено сравнение обязанностей архитектора при использовании традиционного и agile-подходов [1, 3].
* Эпик — масштабная технологическая инициатива по совершенствованию технологических платформ, обеспечивающих реализацию бизнес-функций [www.scaledagileframework.com/enablers] |
Обязанности архитектора — традиционные и в эпоху agile-проектов |
Определение роли архитектора
Деятельность архитектора можно оценивать в главных единицах его работы, причем речь идет не о замысловатых диаграммах, логических моделях или рабочих прототипах. Базовая единица работы архитектора — это архитектурное решение, а основной результат деятельности архитектора — набор решений, которые он принял в ходе разработки системы. Как ни странно, в большинстве организаций не практикуют систематическое принятие и документирование архитектурных решений, хотя это, наряду с контролем их реализации, — одна из ключевых обязанностей архитектора.
Принимая решения, архитектор должен взаимодействовать с участниками проекта и анализировать возможные варианты выбора. Решения не принимаются архитектором в изоляции — он является движущей силой процесса принятия решений и следит за тем, чтобы они своевременно доводились до конца.
Архитекторам следует фокусироваться на планировании архитектуры конечного продукта, а не просто разрабатывать решения для изолированных проектов. При этом необходимо проявлять дальновидность, так как продукты и ПО живут намного дольше проектов. Ориентация на продукт помогает сосредоточиться на потребностях участников, а не на графике или бюджете. Другими словами, архитектору нужно действовать в рамках команды по работе над продуктом; соответственно, важную роль играют коммуникативные способности и навыки взаимодействия.
В контексте одиночного продукта архитектор является ключевым участником соответствующей команды. Его главная функция — обеспечивать баланс между запросами клиента, которого представляет менеджер по продукту, и требованиями руководителя по выпуску продукта (см. рисунок). Задача архитектора — обеспечить согласованность и устойчивость архитектуры продукта. C менеджерами по продукту нередко приходится согласовывать компромиссы, особенно на ранних стадиях жизненного цикла проекта, а ведение этих переговоров с перечислением доступных возможностей — одна из основных обязанностей архитектора.
При создании новых версий архитектуры обязательно нужно учитывать комментарии и предложения. При этом сама она представлена кодом, работающим на физической инфраструктуре, — назовем это «реализованной архитектурой». Время, когда архитектуру представляли в виде набора документов, ушло в прошлое — сегодня задача архитектора состоит в том, чтобы разбираться в реализованной архитектуре, дорабатывать ее и разъяснять другим.
Поэтому архитекторам нужно не только понимать код, но и иметь возможность при необходимости писать его самим. Демонстрация работоспособного кода зачастую лучший способ урегулировать споры между двумя архитекторами.
Подводя итог, можно следующим образом определить роль архитектора: архитектор обеспечивает реализацию программного продукта, принимая архитектурные решения таким образом, чтобы сохранить его концептуальную целостность.
Слагаемые успеха
Помимо необходимых технических навыков, архитектору нужен опыт еще в ряде областей.
Принятие решений
Архитектору необходимо мыслить в терминах минимально жизнеспособной архитектуры. Ее планирование начинается с небольшого числа решений, основанных на фактах, а не на догадках, а расширять архитектуру можно только при абсолютной необходимости. Если требуется принять решение, архитектор должен, действуя быстро, обеспечить необходимые для этого условия. Архитекторов ценят за способность принимать верные решения в условиях неопределенности. Эта способность зависит от опыта (большинство архитекторов — высококвалифицированные технические специалисты) и умения применять верные инструменты в нужное время.
Коммуникация и взаимодействие
Коммуникация для архитектора — превыше всего. Больше половины его рабочего времени должно уделяться именно эффективному общению и взаимодействию.
Специалисты по планированию архитектуры (бизнеса, информации, приложений, инфраструктуры, решений, предприятия) могут быть склонны к работе в изоляции, из-за чего их отдел могут называть «башней из слоновой кости». Но им необходимо делиться знаниями, а не держать их при себе. Важна также возможность получать отклики со стороны (в том числе и от представителей других отраслей). Кроме того, новые идеи, которые можно было бы задействовать в корпоративных проектах, стоит искать вне области своей компетенции.
Участие в команде выпуска
Когда речь идет о проекте, строящемся на концепции непрерывной поставки, основная обязанность архитектора — избавляться от препятствий и предоставлять командам выпуска необходимые для выполнения их задач ресурсы. В частности, архитектор должен проверять работоспособность новых технологий путем создания прототипов.
Тестирование и развертывание
В эпоху концепций DevOps и непрерывного выпуска архитектору уже недостаточно фокусироваться только на архитектуре ПО. При проектировании систем нужно предусматривать возможность тестирования инкрементальных обновлений (в том числе системного тестирования, а также контроля качества и производительности), поэтому архитектор должен хорошо понимать соответствующие процессы. Кроме того, нужна возможность быстрого и легкого развертывания проектируемой системы в различных средах (в среде разработки, тестирования и рабочей), в том числе в частных и публичных облаках.
Роль архитектора ПО меняется — из специалиста в традиционных областях он превращается в универсала, какими являются архитекторы проектных решений.
Что касается архитекторов предприятия, то они востребованы как и раньше, но им нужно избегать фокусировки на создании артефактов, которые не имеют прямого отношения к реализованной архитектуре. Вместо этого нужно сосредоточиться на проектировании архитектуры, ориентированной на продукт, опирающейся на сервисы предприятия и эффективное взаимодействие с командами выпуска. Вместо традиционного создания множества электронных документов лучше уделять больше внимания реализуемому коду, избегая слишком подробного предварительного планирования архитектуры.
Кроме того, нужна ротация архитекторов между разными командами выпуска — это поможет обогатить опыт принятия архитектурных решений. Главный способ приобретения такого опыта — работа в различных предметных областях. Ротация архитекторов между командами разработки помогает как самим специалистам, так и предприятию в целом. Однако заниматься одновременно несколькими проектами не стоит — это ведет к снижению продуктивности.
***
Кроме того, для архитектора все важнее становятся нетехнические навыки, в том числе коммуникативность и способность действовать в условиях неопределенности.
Литература
- M. Erder, P. Pureur. Continuous Architecture: Sustainable Architecture in an Agile and Cloud-Centric World. Morgan Kaufman, 2015.
- F.P. Brooks Jr. The Mythical ManMonth: Essays on Software Engineering, Addison-Wesley, 1975 (Фредерик Брукс. «Мифический человеко-месяц, или Как создаются программные системы». — Пер. с англ. — М., Наука, 1988, — 270 с.: ил.)
- 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.