Март 28

Раздвигая горизонты. Позиция архитектора в современном аутсорсинге

Вопрос знатокам: какая одна из высоких позиций в IT-компаниях все еще непосредственно связана с решением технических задач? Если коротко, то так можно охарактеризовать позицию архитектора.

Это, наверное, одно из немногих карьерных направлений, чья ветка продолжает расти прямо из ствола разработчиков. Сколько времени нужно Project Manager’у или Business Analyst’у для того, чтобы перейти в другой бизнес — к примеру, биотехнологии? Один-два года? Вероятно. Ведь «священные книги» для PM и BA — PMBOK и BABOK, — работают и там. Сколько времени понадобится для разработчика или архитектора? Вторая половина жизни? Скорее всего. Вы ведь не возьмете на софтверный проект архитектора железобетонных конструкций.

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

Была ли жизнь на Марсе?

«Я не могу возмущаться деянием Герострата,
пока не увижу архитектуры храма Дианы в Эфесе.»
Станислав Ежи Лец

Попробуем переформулировать вопрос: Была ли архитектура программного обеспечения актуальна 10, 20 или 30 лет назад? Почему сегодня мы должны задумываться о ней больше чем когда-то? Зачем нам выделенный Архитектор, ведь есть же Tech Lead, мы работаем по Agile, у нас Dedicated Team и пр.?

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

Хотя мы знаем (например, из The Mythical Man-Month, Fred Brooks), что большие проекты уже в начале шестидесятых имели выделенные архитектурные группы, которые работали над дизайном системы для ее последующей реализации. Но проекты такого масштаба встречались на пути отечественного разработчика не чаще, чем цвел папоротник в ночь на Ивана Купала.

Так что же поменялось за это время? Почему в наши дни архитектура становится актуальна даже в аутсорсинговом бизнесе?

В экономике есть модель под названием «циклы Кондратьева». Если коротко, то примерно каждые 40-60 лет меняется технологическая эра. Так между 1891-96 до 1945-47 развивалось тяжелое машиностроение и электроэнергетика; с 1945-47 до 1981-83 — массовое производство, химпром, автомобилестроение; с 1981-83 до ~2018 (прогноз) — электроника и вычислительная техника.

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

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

Мы масштабируемся, или, точнее, социальная природа нас масштабирует, разделяя по функциям и наделяя определенными полномочиями — Project Manager, Business Analyst, Software Developer, Operations Engineer, Quality Engineer (плюс всевозможные вариации из IT-рубрики на jobs.dou.ua).
И теперь еще добавляется Softwarе (Technical/System/Solution/Enterprise/Bla-bla) Architect.
Что интересно, в 2010 году в номинации Best Jobs in America по версии CNN профессия Software Architect получила 1-е место, далеко оставив позади дантистов (12-еместо).

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

Так вот какой ты, серверный олень!

Architecture is design but not all design is architectural.
P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers,
R. Little, P. Merson, R. Nord, J. Stafford (2010).
Documenting Software Architectures: Views and Beyond

А теперь попробуем ответить на третий вопрос: «Зачем нам выделенный архитектор, ведь есть же Tech Lead, мы работаем по Agile, у нас Dedicated Team и пр.?»

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

Для начала разберемся, что есть Software Architecture. На сегодняшний день в ходу две формулировки (представлены в свободном переводе):

Архитектура — это структура вычислительной системы, которая включает программные компоненты, внешние свойства этих компонентов, а также отношения между ними [Software Engineering Institute]
Архитектура — это все решения, которые, сделав однажды, затем трудно изменить [Grady Booch, Martin Fowler]

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

Для наглядности компетенции архитектора существует модель «T», где вертикальная черта литеры определяет специализацию, а горизонтальная — кругозор в подходах и технологиях.

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

Таким образом, архитектор становится посредником между миром бизнеса и технологий.

И здесь апологеты Agile методологий могут воскликнуть: «А как же самоорганизация команды, плоская структура, равенство и братство?»

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

Еще одно расхожее предубеждение гласит о том, что «Архитектурный Дизайн — это чистой воды Waterfall» — видимо, его апологеты вспоминают опыт IBM в построении мейнфремов в 60-х или проекты NASA по высадке человека на Луну. Но то, что это не так, наглядно демонстрируют те же Agile и Lean архитектурные методологии. В конечном счете, процесс разработки не должен влиять на главные цели архитектуры — соответствие продукта требованиям бизнеса, целостность и системное качество.

На заметку: Если Вам будет нужна матрица для ноутбука b133xw01 v 2, тогда заказать ее Вы можете на сайте www.glavmag.su.

Наконец, для полноты картины обозначим границы ответственности между Software Architect, Project Manager и Technical Leaders (во множественном числе, поскольку рассматриваем проект с несколькими командами) в отдельно взятом проекте в компании X:

	Software Architect	Project Manager	Technical Leaders
Анализ требований	Акцент на архитектурных драйверах проекта, т.е. на тех требованиях, которые формируют или влияют на архитектуру: Бизнес домен и основные функции системы Ограничения (например, планируемая дата релиза) Системные требования (например, масштабируемость, хостинг-модель, отказоустойчивость) Технологические риски и их возможные решения	Объем работ; план проекта (календарный план и промежуточные релизы); Коммуникационный план; Проектные риски.	Анализ требований, находящихся в пределах ответственности одной команды (т.е. тех требований, которые не влияют на другие команды проекта); Подготовка к дизайну и реализации.
Оценка проекта	Декомпозиция работ (WBS); оценка трудозатрат (человеко-месяцы); Проверка оценки с использованием альтернативных методик (историческая, function point, пр.)	Декомпозиция работ (WBS); Пересчет человеко-месяцы на реальную структуру команды; Формирование бюджета проекта, учитывая риски, выходные, отпуска и т.п.	Участие в декомпозиции работ и оценки трудозатрат.
Техническое решение	Выбор референс-архитектуры; компромисс альтернативных решений (Trade-off); Выбор технологий; документирование архитектуры	Поиск «ресурсов»; формирование команд	Дизайн подсистемы; прототипирование
Коммуникация решения	Презентация и «продажа» решения; возможные изменения в ходе переговоров с командой заказчика; Обмен знаниями и обратная связь с командами.	Утверждение плана работ и проектных рисков	Обратная связь по архитектуре решения; Влияние технических решений принятых на уровне команды на общую архитектуру решения.
Поддержка разработчиков	Консолидирование полной картины (Big Picture) проекта; Интеграция команд в плоскости технических решений; Продолжающийся обмен знаниями; Помощь командам в архитектуре и дизайне; Решение конфликтов в техническом спектре.	Мотивация; Контроль выполнения работ; Решение конфликтов; Пиво и пицца :)	Мотивация разработчиков команды; Помощь членам команды в дизайне и реализации.
Проверка архитектурного качества	Контроль целостности архитектруры и атрибутов качества системы (quality attributes — e.g. scalability, maintainability, etc)		Контроль качества дизайна и кода
Эффективный стиль менеджмента (PAEI Model, Adizes Methodology)	PaEi Фокус на результат и генерирование идей для решения технических проблем.	pAeI Фокус на администрирование процесса и интеграцию коллектива.	Paei Фокус на результат работы команды.

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

И что дальше?

Great designs come from great designers.
Frederick P. Brooks — No silver bullet, 1987

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

Даже в модели Dedicated Team есть место для архитекторов, так как все чаще заказчик не имеет «домашней» (in-house) компетенции в технологиях сегодняшнего дня — SaaS/Clouds, Big Data, BI/DW, SOA.

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

P.S. Данная статья возникла как результат обобщенного опыта успешного развития архитектурной компетенции в компании SoftServe. На сегодняшний день более 15 профессионалов составляют Архитектурную группу, оказывая услуги компаниям с мировыми именами, включая General Electric, Pearson Education, Allscripts и другие. Группа растет, и мы всегда рады пообщаться со специалистами, которые решили для себя продолжать карьеру в направлении архитектуры программных решений.