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

Питання знавцям: яка одна з високих позицій в 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. На сьогоднішній день в ходу два формулювання (представлені у вільному перекладі):

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

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

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

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

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

Все так само, якщо проект не виходить з рамок однієї програми і в команді достатньо зрілі розробники. Але якщо ця система або рішення об'єднує в собі декілька команд, то без виділеного професіонала (або декількох професіоналів) не обійтися. В іншому випадку проект ризикує потонути в смоляний ямі переробок і заплаток або перенесенням термінів релізу на все більш віддалену перспективу. У традиційному будівництві подібні ризики знімаються якраз архітекторами, і розробка більш-менш великих програмних рішень також дотримується цього принципу.

Ще одне поширене упередження свідчить про те, що «Архітектурний Дизайн - це чистої води Waterfall» - мабуть, його апологети згадують досвід IBM в побудові мейнфремів в 60-х або проекти NASA з висадки людини на Місяць. Але те, що це не так, наочно демонструють ті ж Agile і архітектурні методології. В кінцевому рахунку, процес розробки не повинен впливати на головні цілі архітектури - відповідність продукту вимогам бізнесу, цілісність і системну якість.

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

Software Architect

Project Manager

Technical Leaders

Аналіз вимог

Акцент на архітектурних драйверах проекту, тобто на тих вимогах, які формують або впливають на архітектуру:

Бізнес домен і основні функції системи

Обмеження (наприклад, планована дата релізу)

Системні вимоги (наприклад, масштабованість, хостинг-модель, відмовостійкість)

Технологічні ризики та їх можливі рішення

Обсяг робіт;

план проекту (календарний план і проміжні релізи);

Комунікаційний план;

Проектні ризики.

Аналіз вимог, що знаходяться в межах відповідальності однієї команди (тобто тих вимог, які не впливають на інші команди проекту);

Підготовка до дизайну і реалізації.

Оцінка проекту

Декомпозиція робіт (WBS);

оцінка трудовитрат (людино-місяці);

Перевірка оцінки з використанням альтернативних методик (історична, function point, пр.)

Декомпозиція робіт (WBS);

Перерахунок людино-місяці на реальну структуру команди;

Формування бюджету проекту, враховуючи ризики, вихідні, відпустки і т.п.

Участь в декомпозиції робіт та оцінки трудовитрат.

Технічне рішення

Вибір референс-архітектури;

компроміс альтернативних рішень (Trade-off);

Вибір технологій;

документування архітектури

Пошук «ресурсів»;

формування команд

Дизайн підсистеми;

Прототипування

Комунікація рішення

Презентація та «продаж» рішення;

можливі зміни в ході переговорів з командою замовника;

Обмін знаннями та

зворотній зв'язок з командами.

Затвердження плану робіт і проектних ризиків

Зворотній зв'язок з архітектури рішення;

Вплив технічних рішень прийнятих на рівні команди на загальну архітектуру рішення.

Підтримка розробників

Консолідація повної картини (Big Picture) проекту;

Інтеграція команд в площині технічних рішень;

Триваючий обмін знаннями;

Допомога командам в архітектурі і дизайні;

Рішення конфліктів у технічному спектрі.

Мотивація;

Контроль виконання робіт;

Рішення конфліктів;

Пиво і піца :)

Мотивація розробників команди;

Допомога членам команди в дизайні та реалізації.

Перевірка архітектурного якості

Контроль цілісності архітектрури і атрибутів якості системи (quality attributes - eg 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 та інші. Група зростає, і ми завжди раді поспілкуватися з фахівцями, які вирішили для себе продовжувати кар'єру в напрямку архітектури програмних рішень.

. Top25-table {border: 1px solid # 333;}. Top25-table thead th {padding-top: 5px; padding-bottom: 5px; background: # eeece0! Important; border: 1px solid # 333! Important; vertical- align: middle! important; line-height: 1.3! important; font-size: 13px! important;}. top25-table tbody th {padding-top: 10px; text-align: left! important; vertical-align: middle! important; line-height: 1.3! important; font-size: 13px! important; border: none! important;}. top25-table tbody td {color: # 333; font-size: 13px! important; vertical-align: middle ! important;}. top25-table tbody tr: nth-child (2n +1) {background: # eeece0! important;}. top25-table. pos {color: green;}. top25-table. neg {color: red ;}. top25-table. l {text-align: left! important;}. top25-table tr: first-child td,. top25-table td: first-child {font-weight: bold;}. top25-table td p {padding: 5px 0;}

Опубліковано: 27/03/12 @ 01:09
Розділ Різне

Рекомендуємо:

« Класний» , « Прибутковий» , « Успішний », одним словом - Boffo
Education 3.0
Історія успіху - Андрій Круз
Чому інвестування - це добре?
успішний бізнес