Раздвигая горизонты. Позиция архитектора в современном аутсорсинге
Вопрос знатокам: какая одна из высоких позиций в IT-компаниях все еще непосредственно связана с решением технических задач? Если коротко, то так можно охарактеризовать позицию архитектора.
Это, наверное, одно из немногих карьерных направлений, чья ветка продолжает расти прямо из ствола разработчиков. Сколько времени нужно Project Manager’у или Business Analyst’у для того, чтобы перейти в другой бизнес — к примеру, биотехнологии? Один-два года? Вероятно. Ведь «священные книги» для PM и BA — PMBOK и BABOK, — работают и там. Сколько времени понадобится для разработчика или архитектора? Вторая половина жизни? Скорее всего. Вы ведь не возьмете на софтверный проект архитектора железобетонных конструкций.
Обширный опыт и глубокие технические знания — вот благо (или проклятие) профессионала, который посвящает себя одной дисциплине, не сворачивая с однажды принятого пути. И в этом есть резон! Позиция архитектора программных решений по праву считается одной из самых высокооплачиваемых во всем мире, и Украина не исключение (о чем наглядно свидетельствует рубрика «Зарплаты»).
Была ли жизнь на Марсе?
«Я не могу возмущаться деянием Герострата, пока не увижу архитектуры храма Дианы в Эфесе.»
Станислав Ежи Лец
Попробуем переформулировать вопрос: Была ли архитектура программного обеспечения актуальна 10, 20 или 30 лет назад? Почему сегодня мы должны задумываться о ней больше чем когда-то? Зачем нам выделенный Архитектор, ведь есть же Tech Lead, мы работаем по Agile, у нас Dedicated Team и пр.?
Ответ на первый вопрос — да, архитектура в программных системах существовала и раньше, даже если о ней никто не думал. В этом и заключается определенный парадокс. Создавались (и до сих пор создаются) системы, где большинство архитектурных решений принимаются или на базе ограниченного опыта одного-двух проектов или по наитию — т.е. бессознательно.
Хотя мы знаем (например, из The Mythical Man-Month, Fred Brooks), что большие проекты уже в начале шестидесятых имели выделенные архитектурные группы, которые работали над дизайном системы для ее последующей реализации. Но проекты такого масштаба встречались на пути отечественного разработчика не чаще, чем цвел папоротник в ночь на Ивана Купала.
Так что же поменялось за это время? Почему в наши дни архитектура становится актуальна даже в аутсорсинговом бизнесе?
В экономике есть модель под названием «циклы Кондратьева». Если коротко, то примерно каждые лет меняется технологическая эра. Так между до развивалось тяжелое машиностроение и электроэнергетика; с до массовое производство, химпром, автомобилестроение; с до
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 получила место, далеко оставив позади дантистов место).Как когда-то в строительной сфере «Главные Строители» (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]
То есть, архитектор ответственен за разбивку системы на составляющие части (подсистемы, модули), определение протоколов и принятие всех трудно-изменяемых решений (например, выбор технологии).
Таким образом, архитектор становится посредником между миром бизнеса и технологий.
И здесь апологеты Agile методологий могут воскликнуть: «А как же самоорганизация команды, плоская структура, равенство и братство?»
Все так же, если проект не выходит из рамок одного приложения и в команде достаточно зрелые разработчики. Но если эта система или решение объединяет в себе несколько команд, то без выделенного профессионала (или нескольких профессионалов) не обойтись. В противном случае проект рискует потонуть в смоляной яме переделок и заплаток или переносом сроков релиза на все более отдаленную перспективу. В традиционном строительстве подобные риски снимаются как раз архитекторами, и разработка более-менее крупных программных решений также следует этому принципу.
Еще одно расхожее предубеждение гласит о том, что «Архитектурный Дизайн — это чистой воды Waterfall» — видимо, его апологеты вспоминают опыт IBM в построении мейнфремов в или проекты NASA по высадке человека на Луну. Но то, что это не так, наглядно демонстрируют те же Agile и Lean архитектурные методологии. В конечном счете, процесс разработки не должен влиять на главные цели архитектуры — соответствие продукта требованиям бизнеса, целостность и системное качество.
Наконец, для полноты картины обозначим границы ответственности между Software Architect, Project Manager и Technical Leaders (во множественном числе, поскольку рассматриваем проект с несколькими командами) в отдельно взятом проекте в компании X: