Хто такий Solution Architect

Привіт, друзі!

З вами Rist і сьогодні поговоримо про те, хто такий Solution Architect.

Це друга стаття з серії «Who is who in IT?», а першу, про DevOps можете переглянути тут.

В нас побував Олексій Зеленюк — Software Engineer. В Олексія понад 12 років досвіду роботи в ІТ на десятках різних проектах та компаніях (великих, маленьких і середніх). Зараз працює Solutions Architect’том, в основному як консультант, в різних, продуктових та аутсорсингових компаніях.

То почнемо?

Хто такий Solution Architect?

Отже, щоб розібратися хто такий Architect, треба почати з питання, що є архітектурою:

Як каже біблія Архітекторів — Software Architecture in Practice:

Архітектура системи — це набір структур, що потрібні для міркування про неї, який містить програмні елементи і зв’язки між ними, та їхні властивості.

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

Хто такий Архітектор?

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

Але це швидше стереотипне бачення, бо різних архітектур в індустрії дуже багато:

  • Infrastructure Architecture
  • Security Architecture
  • Technical Architecture
  • Solution Architecture
  • Network Architecture
  • Database Architecture
  • Hardware Architecture
  • Enterprise Architecture
  • Application Architecture
  • Business Architecture
  • Software Architecture

і є ще біля десятка інших визначень і розгалужень архітектури.

Отже, поняття «Архітектор» — настільки ж розгалужене як і поняття «програміст», або навіть інженер.

Проте в більшості випадків, під архітектурою мають на увазі такі речі:

  1. Application Architecture
  2. System Architecture
  3. Software Architecture
  4. Enterprise Architecture

Почнемо з того, хто такий Application Architect.

Архітектура аплікації

Це організація коду програми та даних, якими вона оперує. Це програмний дизайн на рівні класів, об’єктів, модулів, структур даних і таке інше. Зазвичай, це пов’язано із однією технологією.

Це те чим зазвичай займається техлід на проекті, і це є перша сходинка для програміста, якщо він хоче рухатися в Архітектори.

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

В більших компаніях, до техлідерської діяльності, також додається вимога «soft-skill» — можливість поспілкуватися з клієнтом та топ-менеджером на зрозумілій їм мові, публічні виступи, ну і звісно навички малювання діаграмок на дошці з розумним виглядом, куди без цього.

Системна архітектура

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

Enterprise архітектура

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

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

Solution архітектура

Якщо коротко, то це такий собі гібрид між попередніми трьома.

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

Щоб стати Solution Архітектором інженер має трохи відійти від улюблених технологій та ідеалізму в написанні коду вище до потреб бізнесу і зрозуміти, що якість і підтримуваність самого коду є тільки часткою із властивостей продукту, яких насправді дуже багато.

Тут потрібно брати до уваги бізнес-цілі та обмеження: час, бюджет, всілякі відповідності, SLA, якісні властивості про те як швидко має працювати програма, наскільки вона має бути захищеною і в яких місцях, скільки часу вона може бути недоступною впродовж усього часу виконання, і багато іншого.

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

Про Soft Skill і життєві складнощі

Комунікація — це велика, і часом найбільша частина роботи Архітектора. Мітинги, воркшопи, презентації, написання документації — це все інструменти донесення інформації до людей. А результатом цього має стати програмний продукт.

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

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

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

Можна зробити ідеальну архітектуру, але вона може виявитися занадто дорогою у виконанні.

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

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

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

Чи потрібен Архітектор на проекті?

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

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

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

Коли ваш продукт не доступний більшість часу, а весь ваш бізнес онлайн — ви з цього бізнесу вилітаєте.

Тому так, Архітектор потрібен. Як би він при цьому не називався, потрібна людина яка розуміє куди рухається проект і як його далі ростити і підтримувати.

Outsource vs Product

Різниця між аутсорсинговими і продуктовими компаніями вже досить затерта тема.

Різниця справді є, і чим далі по кар’єрній драбині — тим вона більше відчувається.

Outsource

Ключова відмінність Outsource в тому, що це є сервіс. Ви робите сервіс клієнтові — вам потрібно мати більше навичок комунікації із ним.

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

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

Product

В продуктових компаніях ви більше присвячуєте себе доменній галузі вашого продукту. Між продуктом і вами зазвичай менше зайвого менеджменту і політики. Ви більше залучені в сам бізнес і займаєтеся безпосередньо архітектурою. Проте, Архітектор в чистому вигляді (якщо такий взагалі існує) в продуктовій компанії зустрічається рідше. Зазвичай у ваші обов’язки як Архітектора ще входить солідна частина ролі тімліда, що саме по собі доволі рутинна справа.

З ким в основному комунікує Архітектор?

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

Таким чином Архітектор являється живим мостиком між бізнесом і технологіями.

Які поради для менеджерів, розробників, тестерів...

  1. Думати над архітектурою потрібно раніше, ніж проект «приїхав». Саме по собі залучення Архітектора на проект може не вирішити проблему. Є навіть така абревіатура — DOA — dead on arrival. Це коли приходиш на проект і розумієш що його потрібно переписувати з нуля із детальним аналізом вимог — функціональних і нефункціональних, і далі тільки думаєш, як це правильно пояснити клієнтові.
  2. Брати до уваги нефункціональні вимоги з не меншим пріоритетом ніж функціональні. Те, ЯК програма буде працювати в «бойових» умовах реального світу не менш важливе того, ЩО вона буде там робити. Якщо ви героїчно побудуєте MVP в стислі терміни, а потім ваші користувачі розчаруються в ній як в повільному, ненадійному і небезпечному «непорозумінні» — вважайте ваш героїзм марним.
  3. Залучати Архітекторів до зустрічей, де обговорюються ключові технологічні рішення. Часом буває що Архітекторові просто дають список фіч, що описані одним реченням, і просять оцінити в часі, або навіть зробити на базі того якісь архітектурні рішення. Є золоте правило — Shit in — Shit out! Отже, Архітектор, як представник технічного світу, має бути якнайближче до бізнесу і володіти максимальним контекстом.
  4. Архітектор — не супермен-вікінг. Він не перепише вам проект за тиждень, який робився півроку. Архітектор це T-shaped спеціаліст, а це означає, що заради широкого охоплення різних знань, він з часто стає менш заглибленим спеціалістом, навіть в своїх профільних задачах. Архітектор може вказати вам шлях в майбутнє вашого продукту (звичайно якщо це майбутнє у нього є). А йти цим шляхом вже доведеться вам самим.

Відео з Олексієм можете переглянути тут. А в коментарях написати, про яких ще спеціалістів хотіли б дізнатись.

👍НравитсяПонравилось2
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Поясните лучше чем Principal Engineer отличаеться от Solution Architect?

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

, и плюс перед бизнес аналитиком — владеет языком технарей.

А так, да,

Архитектор который не работает с кодом за пару лет превращается в хуго архитектора.

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

Треба ще більше розбиратись, щоб розуміти як швидко з отої муті звалити, коли рахунки з чотирма нулями приходять

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

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

Архітектор Прототипів, або, інакше кажучи — creative & experienced Functional-Analyst..

* Звір нев’є***ний, якого ше ніхто ніколи не бачив 😄😆😁

А якщо коротко — то просто личка та багато пафосу. Бо зазвичай «архітект» схильний до тих солюшенів, до яких звик.
Справжній архітект може бути лише продуктом конкретної компанії, і рівно до тих пір, доки він представник конкретної компанії. І для більшості компаній вистачить 1 бойової одиниці такого звіра, ну може 2, щоб не створювати «незамінних» людей. І все.

А в Україні тих архітектів як в нашій армії генералів. І користі стільки ж.

Бо в Україні проектів українських для України рівно плюс-мінус один!

По свому досвіду можу сказати, що знайти/викувати люди яка вміє приймайти збалансовані рішення, знайти спільну мову з багатьма сторонами,... набагато складніше ніж знайти людину, яка вивчила 1-2 фреймоврки та й парочку бібліотек.
На практиці часто від Архітектора вимагають часткове виконня функцій DevOps, Developer (nodejs, python, powershell, bash, code review), Business Analytic i навіть PM. Ta й ще дуже бажано з близьким до досконалого знання різних клауд провайдерів. Ну і security. Ну і навіть виявляється, що рівень англійської, достатній для спілкування з багатьма іноземниви парнтерами є непідйомним для багатьох девів ) А так, особо нічого не треба вміти, достатньо мати багато пафосу :)

Я так і сказав. Менеджерська позиція по суті. А по поводу 1-2 фреймворків... 20-30 не хотів?

Не згідний на рахунок менеджерської. Чи прикрутка k8s, kafka, rabiitmq, vaults,github, azure devops, terraform, elasticsearch, grafana, load balancers, gateways, oauth,,,, azure, aws і прикрутка ще купи купи різних тулзів, це менеджераська позиція? :) що я не бачив прикладів, щоб хтось добре розбирався в 30 ФРЕймворках. 30 — то певно якщо рахувати dependencies в package.json :) А головне нехай кожен дев добре намалює domain boundaries і data flow....)

Чи прикрутка k8s, kafka,

а це часом не девопси роблять, у великих командах, а у маленьких самі программісти?

А головне нехай кожен дев добре намалює domain boundaries і data flow....)

сіньор — повинен це вміти. не дуже добре, але прийнятно
кожен так — не може, у кожного купа своєї роботи.

Тут питання, що таке прийнтятно і яка в ньому вартість помилки. Замітив, що в різних компаніях різні обовязки на тих самих ролях. Десь программіст має вміти абсолютно все, а десь один одному наступають на пятки Architect, DataOps, DevSecOps i DevOps.

прикрутка k8s, kafka, rabiitmq, vaults,github, azure devops, terraform, elasticsearch, grafana, load balancers, gateways, oauth,,,, azure, aws і прикрутка ще купи купи різних тулзів,

Architect таким не занимается. Ну, или под „прикрутить” вы имели ввиду deployment diagram с квадратиками.

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

Тут дивлячись який арїітект і де.

В посте речь про «Solution Architect», у которго

біблія Архітекторів — Software Architecture in Practice

можете открыть содержание и посмотреть там про

8s, kafka, rabiitmq, vaults,github, azure devops, terraform, elasticsearch, grafana, load balancers, gateways, oauth,
Просто подивіться на вимоги

требования часто не имеют отношения к реальности. Запрос should architect code выдает ~140 000 000 результатов, что нескольно намекает на то, что руками архитект, часто мало что делает.

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