Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

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

Вопрос знатокам: какая одна из высоких позиций в 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 архитектурные методологии. В конечном счете, процесс разработки не должен влиять на главные цели архитектуры — соответствие продукта требованиям бизнеса, целостность и системное качество.

Наконец, для полноты картины обозначим границы ответственности между 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 и другие. Группа растет, и мы всегда рады пообщаться со специалистами, которые решили для себя продолжать карьеру в направлении архитектуры программных решений.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn

Схожі статті




65 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Если бы в софтверных компаниях достаточно осознавали бы важность архитекторов, сегодня бы софт выглядел иначе. ИМХО. Но разработка — это быстрые деньги. Типа ограбления благообразного вида. )))

Отличная статья. Me gusta (-:

Познавательная статья. В табличке действительно не хватает позиции/роли BA, часть его активностей «размазаны» по остальным колонкам. Еще создается впечатление, что Software Architect в вашем случае перетянул на себя очень много технических решений и Tech Lead’у осталось совсем немного, а его фокус свелся к тимлидству и операционным решениям. В моем понимании SA продумывает стратегию и выбирает направление, а TL воплощает принимает тактические решения и воплощает стратегию на практике. Несколько вопросов:

1) Нет ли конфликтов между двумя техническими лидерами по техническим решениям? Как разбираетесь?
2) «Ведет» ли SA весь проект от начала до конца? Если нет, как решаете проблему того, что один придумывает и с него снимается ответственность, а остальные потом «расхлебывают кашу»?
3) Сколько времени SA занимается программированием, чтобы не отставать от реальности? Какие еще методы поддержания квалификации используете?
4) Судя по табличке SAs вплотную занимаются pre-sales работой. Помогают ли им в этом BA и кто-то еще?

5) На каком этапе к оценке проекта подключается будущая команда или хотя бы ее лиды? Является ли оценка, данная SA, окончательной или она пересматривается командой?

PS. Прикольно было увидеть в табличке модель человека по Адизесу :) Практикуете?

можу відповісти
1) архітект має вищу позицію це раз, часто архітектурні рішення приймаються на етапі коли ще і не відомо хто тім/тех — лід
2) більше не веде ніж веде, скоріше долучається у моменти коли є якісь факапи і відхилення від «лінії партії»
3) цей час прямує до нуля, хоч загалом залежить від конкретного архітекта і його місцезнаходження в «табелі про ранги»
4) думаю помагають

5) залежить від ситуації, зазвичай на етапі архітектури і пресейлу команди нема, в кращому випадку є кілька лідів(QA/Tech) які беруть участь в процесі

Спасибо Александр.

В моем понимании SA продумывает стратегию и выбирает направление, а TL воплощает принимает тактические решения и воплощает стратегию на практике.

Так оно и есть, если под стратегией понимать архитектурные решения которые касаются всей системы, а под тактикой дизайн решения подсистемы.
Однако должен быть фидбек, т.е. когда выбраное архитектурное решение (напр. выбор технологии) натыкается на ограничения выявленые Тех лидом или командой. В таком случае идет пересмотр архитектуры.
Попробую ответить на вопросы:
1) Конечно конфликты бывают (как часть нормального процесса :)), в таком случае архитектор берет на себя арбитраж (ответственность за принятие конечного решения лежит на нем), если стороны и дальше не пришли к согласию, вопрос выносится на консилиум куда приглашаются другие архитекторы + менеджмент проекта (что бывает достаточно редко, как правило стороны сами приходят к согласию)
2) Повторюсь (где-то уже писал в коментариях) — Степень участия архитектора в проекте достаточно гибкая величина, все зависит от величины проекта, степени рисков и мачурности команды. Правило здесь простое: «То что не решает архитектор, решает команда» — если в начале проекта требуется принятия многих архитектрурных решений, то лучше использовать фокус архитектора на 100%, затем принятие локальных решений можно делегировать команде, уменьшая занятость архитектора до 10-50%.
Андрей
Андруневчин, я так понимаю описал проект где архитектор не был задействован в процессе разработки, а оказывал помощь в авральной ситуации, за счет самой компании (т.е. без оплаты клиентом).
3) Как решается проблема Ivory Tower Architect? :)
Как правило прототипированием или написанием reusable components котрые могут быть использованы в других проектах.
4) Да, pre-sale и помощь маркетингу как одна из функций архитектора. BA также участвуют в этом процессе.
5) В большинстве случев Core team в игре с момента старта проекта. Команда дает альтернативный естимейшн и фидбек по принимаемым архитектурным решениям.

Задача архитектора не только «продать» свое решение клиенту, но и получить «Buy-in» команды, для этого необходимо иметь технический авторитет и развивать soft skills — presentation, negotiation, conflict management, etc.

А на примере модели Адизеса можно хорошо показать в чем отличие лидершипа основных игроков проекта :)

З досвіду роботи на серві :)

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

А еще архитектор в IT, наряду с консультантами и аналитиками, самая удобная позиция для «распила» бюджета проекта. Ресурс едва ли не самый дорогой, а результат работы часто весьма обтекаемый. Сколько раз видел дизайны на сотни страниц, в которых разве что утопиться можно — одна вода. Извините, если что, но вот такое c’est la vie.

Бывает и такое в индустрии, не спорю.

Услуги по 250 у.е. в час с сомнительным результатом, но после этого как правило к таким консалтерам заказчик больше не обращается. Гораздо лучще плодотворные и длительные отношения, они генерируют в свою очередь новых клиентов через референсы от существующих.

Если результат работы это только документ на сотни страниц то виноват тот «лох», который за него заплатил.

Да, табличка зачетная — сразу видна способность к выделению ключевых структур в абстрактных понятиях и процессах ;) Можно только заметить, что архитекторами не рождаются — ими становятся. Как говорится «опыт растет прямо пропорционально выведенному из строя оборудованию» ;)

Ним народжуються, а потім ще й стають :)

Зачетный ролик, жаль что SoftServe нет в Киеве )))

Мне статья понравилась — читается как сказка на ночь.
Имеет место быть цикл статей на эту тему с детализацией и красивыми картинками.

Имеет место быть цикл статей на эту тему с детализацией и красивыми картинками.

Можно ссылки?

«имеет место быть», как говорят в Одессе)), значит, что будет цикл статей. В данном случае с вопросительной интонацией, поэтому знак вопроса опущен =)...поэтому ссылок, паролей и явок точно не будет, телепатирую....

Есть уже третье издание Басклеменскацмана, amzn.to/1ciwcAX

Ага, вот, значит, кого нужно винить за кривизну интерфейса Pearson Education!

А какой продукт? позвольте уточнить :)

Точно не наше :)

Какие книги/статьи/ресурсы посоветует автор желающим развиваться в направлении архитектуры программных решений?

Из фундаментальных я бы советовал начать с «Software Architecture in Practice, Second Edition» от SEI,

затем более практическая — «Application Architecture Guide v2» от MS Patterns & Practices, — достаточно хорошо отделена от реализации, будет полезна для инженеров специализирующися как в .Net так и в Java или других средах разработки.

Дальше можно углубляться в конкретный домен — SaaS/Clouds, SOA, etc. — в зависимости от выбраной специализации.

Из онлайн ресурсов:
The Architecture Journal — msdn.microsoft.com/...ecture/bb410935
Известный ресурс InfoQ — www.infoq.com/...tecture-design

High level вещи по архитектруре — www.iasaglobal.org/...asa/default.asp

Спасибо! И за статью, и за этот комментарий :)

Ну и Фаулера с Эвансом почитать не помешает.

Спасибо. Тема действительно интересная. Стать архитектором — реальная возможность карьерного роста для девелопера не годного в менеджеры.
Для архитектора важно быть на переднем крае технологий. Т.е. как минимум половину времени он должен посвящать самообучению и разработке Proof of Concept проектов (не на заказ). Иначе при старте нового проекта он не будет готов сходу предлагать надежные технические решения.
Возникает ряд организационных вопросов:
— Кто оплачивает обучение архитектора? Или он учится во время работы над архитектурой?
— Работает ли архитект как член комманды на проекте постоянно? Или он может участвовать одновременно в нескольких проектах?
— «Ведет» ли он проект от начала до конца или участвует только на начальном этапе (скажем, первые полгода)?
— Специализируется ли архитект на узкой области (например, только веб-сайты) или он должен знать и уметь разные типы приложений и разные (конкурирующие) технологии?
— Работает ли архитект как фул-тайм сотрудник (на «ставке») или как консультант? Как его «продают» клиенту?
— Что делать если у архитекта временно нет оплаченной заказчиком работы?

— Ведет ли архитект обучение команды? Кто оплачивает обучение?

Beaver, менеджериал скилс желательно иметь, разве что не в таком объеме как для PM. Все таки контроль архитектруры и решение технических споров между учасниками проекта падает на плечи архитектора.
Спасибо за вопросы! Хватит на следующую статью :)
Если коротко, то:
— Как правило компания берет на себя траты по обучению + риск недоутилизации специалиста — что по плечу не каждой организации.
— Много-проектость часто отличительная черта Solutions Architect от Application Architect

— Степень участия архитектора в проекте достаточно гибкая величина, все зависит от величины проекта, степени рисков и мачурности команды. Правило здесь простое: «То что не решает архитектор, решает команда» — если в начале проекта требуется принятия многих архитектрурных решений, то лучше использовать фокус архитектора на 100%, затем принятие локальных решений можно делегировать команде, уменьшая занятость архитектора до 10-50%.

годная статья. но мачурность команды это 5! )))

Как раз в разрезе поднятых вопросов (которые, между прочим, очень по существу), сейчас прибежит толпа и будет вам рассказывать о том, что, дескать, архитектор — это роль (с чем я в корне не согласен), а не позиция! Ведь разработка архитектуры системы — это эпизодическая задача, возникающая на начальной стадии проекта и отнимает ~5% вовлеченных ресурсов. Готовы вы дать толпе отпор?

Вопрос калибра проекта, абсолютно нормальная практика если кто-то из тима 10-и человек возмет на себя роль архитектора, но этот же маневр не пройдет в командах из 30 и более человек. Сложность и величина проектов требует кого-то, кто занимается архитектурой на професиональной основе, т.е. горизонтальная черточка в модели «T» должна быть достаточно широкой, чтоб охватить множество разноплановых вещей — подходы, технологии, опыт практического применения и т.п.
И факты говорят, что есть и те для кого это роль, и те для кого это позиция.
В поддержку первых появляются методологии типа — www.codingthearchitecture.com
В поддержку вторых — SEI, IASA, TOGAF и прочие организации.
Ну и что самое интересное, в одной организации могут спокойно уживаться оба подхода :)

Спасибо. Ваши идеи я теперь буду использовать для того, чтобы отбиваться от «толпы», можно? :)

Вот поэтому у нас и нет архитектов. Члены команды, способные разработать приличную архитектуру проекта (зачастую методом проб и ошибок) — есть, а вот специалистов, которые могут предложить новому заказчику продуманное техническое решение — нет. Помнится недавно искали, кстати: http://dou.ua/forums/topic/5405/

— Как правило компания берет на себя траты по обучению + риск недоутилизации специалиста — что по плечу не каждой организации.

Вот и ответ — архитекты есть у тех, кто понимает их пользу и умеет их продавать.

Проект еще нужно удержать в архитектуре. Когда нагонят стадо папуасов на проект — они превратят его в .....

Немного юмора:

Еще вчера «23х летний сеньор» был пиковый тайтл на dou, еще несколько статей про архитекторов ПО и в этой стране появятся «24х летние аркитекты» =)

А були інші статті про архітекторів? Можна посилання? Я вже починаю навчання :)

Статья отличная, все по полочкам разложено! Кстати если у Архитектора есть команда как описано в Бруксе: помощник архитектора, лингвист, оператор и т.д, то он вполне может перейти от разработки ПО в области машиностроения к биоинформатике, но только со своей командой добавив или равноценнозаменив прикладную должность...имхо

Спасибо, Максим. Хотелось бы верить, что портабилити Архитектора выходит за рамки его индустрии, но к сожалению без инженерных знаний в целевом домене сильно снижается еффективность. Хотя судя по всему Бруксу (в «Design of Design») удалось построить загородный домик, правда не без помощи констракшин-архитектора :)

какая одна из высоких позиций в IT-компаниях все еще непосредственно связана с решением технических задач?

Chief Software Engineer например

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

Архитектура — это все решения, которые, сделав однажды, затем трудно изменить [Grady Booch, Martin Fowler]

Кроме всего прочего, архитектура — это набор соглашений (conventions), которые участники проекта либо принимают и следуют им, либо не участвуют в проекте вовсе.

Контроль целостности архитектруры и атрибутов качества системы (quality attributes — e.g. scalability, maintainability, etc)

Стоит отметить, что помимо scalability и maintainability само наличие архитектуры в разрабатываемом решении — это очень важная составляющая, напрямую влияющая на качество результата.

Chief Software Engineer например

Конечно, так же бывают и CTO, Distingushed Software Engineer, Chief Scientist, вопрос скорее количества, т.е. как себя именует наиболее многочисленная група топ технарей в индустрии.

Кроме всего прочего, архитектура — это набор соглашений (conventions), которые участники проекта либо принимают и следуют им, либо не участвуют в проекте вовсе.

Хорошая дефиниция, спасибо.

А насколько, кстати, ваша группа многочисленна? Я так понимаю архитекторских позиций в целом на порядок меньше чем Тим-лидских или ПМ-ских, и даже чем м.. кто там следующий в управленчиской иерархии?

И что всё-таки надо что б технарю попасть на такую позицию? В какую сторону делать первый шаг?

И что всё-таки надо что б технарю попасть на такую позицию? В какую сторону делать первый шаг?

Наверное обрести soft skills, которых недостаточно для people management, но достаточных для донесения своей позиции, организации и фасилитации технических обсуждений с целью выработки решения, умелой аргументации/критики предложенных решений и в последствии отстаивания архитектурных решений на разных уровнях.

Еще есть Fellow (как IBM Fellow Grady Booch, например). Лично для меня круче такой роли ничего быть не может.

Это же обычный «научный сотрудник», не?

Сори, исправил. Это был не Кнут и не research fellow, а Буч и IBM fellow :)

Дословно «АйБиЭм дружбан» или «братиша». Вообще fellow сродни advocate, откуда берутся эти тайтлы непонятно, да и если б Буч работал в стартапе, а не корпорации мыслей и взглядов это б его не поменяло.

Еще бывают всякие «евангелисты», притом это реальные позиции в структурах солидных компаний

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

Думаю, такому человеку просто приятно, при чем мы говорим о людях заслуживших свой статус делом. Взять ,например, Цкерберга, вот вроде с нуля писал фейсбук, да и крутой тайтл себе в 20 лет мог нацепить типа «I’m CEO, bitch», но вне фейсбука он будет не ахти.Если б у нас был Буч или Макконел, то в 35 они свалили в бизнес аналитики или прожект менеджеры ибо семья и еще 3000 причин. А вот оставаться в технической отрасли более чем 20 лет и быть на уровне с молодежью, это заслуживает уважения. Это как гугл перехватил себе папу Гослинга, а ему там неинтересно и ложил он на гугл, сейчас в Liquid Robotics и ему там нравится судя по блогу )))

Fellow — это не только «дружбан», в научной среде это еще и именно что «научный сотрудник»

Эта фишка, если я не ошибаюсь, сохранилась только в Великобритании, и больше означает что-то типа «член-корреспондент», например, академии наук или научного сообщества. В USA «research scientist», а в UK может быть «research fellow», которые впринципе могут обозначаться как «научный сотрудник», но в их понимании это больше «ученый, занимающийся исследованиями», в отличии от theoretical scientist или md. который перестал практиковать. В англоязычном мире в этой области намного больше разных регалий чем у нас.

Насчет научного мира не скажу, а вот в IT регалия «fellow» в смысле «самый грамотный специалист, возглавляющий research & development и/или ответственный за техническую стратегию компании» в последние годы начинает, наоборот, приобретать популярность именно в США.

в крупных комерческих коорпорациях, это последняя ступенька в технической лестнице. Уровень VP или SVP в компаниях которые не занимаются финансами.

CTO это уже сильно в сторону people management, а Fellow может себе кодить что хочет и вообще делать что считает нужным.

Кстати, ваш technical lead — это Applications Architect по определению из википедии (en.wikipedia.org/...ware_architect, тогда как Software Architect — на самом деле Solutions Architect.

По большей части так и есть, в большинстве проектов роль Applications Architect исполняют Technical Leads.
Интересно, что до сих пор индустрия не пришла к единой таблице «архитектурных рангов» :) Разброс достаточно большой, таким же образом можно выделить Systems Architect (en.wikipedia.org/...stems_architect) — ответственный не только за софтварную часть, но и системную — напр. хостинг и все вытекающие последствия — scalability, performance, deployability, etc.
Поэтому читая титл человека, хорошо бы спросить чем реально он занимается в своей компании.

Так как Software Architect наиболее общий термин, поэтому я использовал его в статье, иначе пришлось бы еще увеличить материал :)

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

Это очень правильное замечание. Именно поэтому я думаю, что правильное место этой статьи — в разделе персональных колонок, как частное мнение.

На самом деле, Сергей, мы валидировали этот подход с SEI (как традиционной методикой) и достаточно свежим Coding the Architecture (www.codingthearchitecture.com) — удалось встретиться с автором методики в рамках QCon коференции. Уверен что 80% активностей может быть использовано и в реалиях других организаций.

Я не к тому, что архитекторы не нужны — это, как бы, очевидно, и в том или ином виде на любом крупном проекте есть свои design committee, community of practice и т.п.

Просто ролей может быть больше/меньше, и распределение обязанностей может варьироваться (например, на бизнес-аналитиках и product owner(s) может быть бОльшая часть ответственности по scope проекта, а PM выполнять организационную роль и заниматься стаффингом/тимбилдингом и т.п.).

Я не сомневаюсь, что вышеприведенная схема работоспособна, но это даже не 50% случаев. А если выделить общие принципы, то все сводится к очевидным вещам типа: «у дизайна сложных систем должен быть owner», «системное мышление — это хорошо», «вода — мокрая», «смерть неизбежна» и т.п.

Или я живу в мире эльфов, а на самом деле в наше время кто-то еще разрабатывает системы с хотя бы семизначным бюджетом без какого-либо архитектурного контроля?

А как по мне книжка ничего особенно из себя не представляет. Вода водой, прочитал и ничего для себя не вынес. $9.99 на ветер )

Вероятно речь идет о Coding the Architecture? Книжка расчитана на начальные уровень, личный опыт автора — работа в небольших командах, так что не удивительно :)

Если интересуетесь Архитектурой процессов — хорошая литература которая попадалась за последнее время — «The Art of Scalability» (theartofscalability.com) — фундаментальная как в масштабировании процессов разработки, так и технических решений, чувствуется большой опыт авторов который они вынесли из eBay и PayPal.

В таблице сильно не хватает бизнес-аналитика.

Спасибо! Makes sense. Обязательно добавим в след. версию статьи (скоро выйдет на английском в одном из технических блогов)

Мені здається, що бізнес-аналітика, як позиції, не вистачає у вашій компанії, Віктор :)

Ну по-перше не все так погано, як ви кажете. По-друге, ми зараз активно працюємо в напрямку процесів бізнес-аналізу і картина вимальовується досить цікава.

Радий чути, що є якісь зміни в цьому напрямку.

Підписатись на коментарі