Як дорости до Solution Architect — і що в цій ролі доведеться робити

Привіт, мене звати Юрій Панайотов. Разом із командою розробників та інших технічних спеціалістів ми створюємо маркетплейс MAUDAU, де я займаю позицію Chief Technology Officer.

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

У статті хочу поділитися власними відкриттями та досвідом з тими, хто розмірковує щодо кар’єри Solution Architect.

Хто такий Solution Architect

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

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

З іншого боку — Solution Architect має «продати» свою ідею команді розробки так, щоб спеціалісти повірили, що це можливо й рішення буде працювати.

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

При створенні архітектури SA враховує, як система буде працювати (який буде perfomance), яке навантаження конкретна фіча зможе тримати, як буде відбуватися взаємодія різних елементів системи, взаємодія з third-party системами, безпекою тощо.

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

Він дивиться і аналізує весь продукт загальним планом — «helicopter view»:

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

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

Артефакт — це будь-який документ, чи інший метод донесення інформації від архітектора до технічних працівників. Це може бути будь-що: тексти, описи, діаграми (особисто мені підходить набір діаграм С-4). Це щось, на що команда розробки може подивитися і сказати «о, нам це зрозуміло, ми пішли робити».

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

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

Ще одна важлива функція Solution Architect в проєкті — підтримання та оновлення існуючої архітектури. Майже щодня потрібно актуалізувати дані: на проєкт «заїжджають» нові фічі, поточні з реальним навантаженням можуть перформити не так, як планувалось (таке теж буває).

Щоб робити підтримку архітектури якісно, потрібно поставити собі просте питання: «Якби до нас прийшов новий розробник і ознайомився з нашою архітектурою, чи зрозумів би він усе, чи побачив би реальний стан проєкту?»

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

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

Підсумую все, про що йшлося вище. Що має робити Solution Architect:

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

Створити архітектуру проєкту/ продукту. В ІТ будь-яка архітектура — це жива сутність, вона завжди змінюється і еволюціонує, поки продукт розвивається. SA не має змоги зазирнути в майбутнє (але має пробувати це зробити) і дізнатися, що саме ось таку штуку потрібно буде додати до його архітектури.

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

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

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

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

Як у компанії з’являється архітектор

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

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

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

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

Великому холдингу оптимально брати окремих спеціалістів на кожен продукт. Там можуть бути цілі відділи SA зі своїми лідами. У нас, наприклад, зараз чотири команди — для цього поки що достатньо одного архітектора.

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

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

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

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

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

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

Як архітектор шукає рішення

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

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

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

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

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

Якщо архітектор знаходить якісь ідеї, він робить POC — proof of concept. Це прототип. Грубо кажучи: зроблений на колінці код, який підтверджує, що ідею можливо реалізувати. Він дуже простий, з мінімальним функціоналом, але потрібен для того, щоби протестувати рішення і показати технічній команді.

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

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

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

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

Шлях до архітектора в IT

Хто може стати архітектором рішень

Як на мене, ти не зможеш продавати рішення, які не зможеш сам написати. Тому особисто я вважаю, що архітектором може стати той, хто пройшов усі етапи кар’єри розробника.

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

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

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

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

У нього ширший кругозір. Він дивиться не тільки на свій код, а на проєкт у цілому. Йому цікаво, як усе влаштовано. Такі люди можуть стати хорошими архітекторами.

Кому точно не варто бути архітектором

  • Тим, хто любить писати код — від цього доведеться відмовитися частково або повністю. Тож якщо ти любиш займатися цим щоденно по 6–7 годин, то бути SA тобі не сподобається.
  • Якщо ти не любиш, або не вмієш і не хочеш вчитися спілкуватися з людьми — ця позиція теж не для тебе. Комунікувати доведеться дуже багато.

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

  • Якщо людина не хоче або не вміє брати на себе велику відповідальність. Тут вона дуже велика. Неправильне рішення на етапі архітектури буде коштувати дуже багато грошей.

Деякі SA роблять архітектуру, приходять до команди й кажуть: «Я зробив — ви втілюйте». Я не люблю такий підхід, мені він не подобається.

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

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

Скільки заробляє Solution Architect

Архітектор має вищу зарплатню, ніж будь-який розробник. Рівень його оплати — десь такий, як у техліда, інколи вищий. $6500 — це нижня планка по ринку. Досвідчений архітектор може стабільно заробляти $7000–8000 на місяць.

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

Компанії частіше намагаються вирощувати власних архітекторів, бо окрім знань розробки, інструментів та комунікативних навичок, потрібно ще добре розбиратися в специфіці сфери — добре знати домен, business flow. Тобто якщо архітектор, який, наприклад, працював у Gamedev, прийде в E-comm, йому потрібен буде час, щоб розібратись.

Що потрібно вивчити, щоб стати архітектором

Із чого можна почати:

  • робити архітектуру на рішення, що вже існують на проєкті (фічі, невеликі модулі системи);
  • створювати архітектуру для нових фічей (навіть діаграми намальовані на аркуші або на вайт-борді будуть плюсом).

Коли спеціаліст робитиме це вперше, то отримає знання, які будуть критично важливими в майбутньому на позиції SA. Дуже круто, коли таку вправу робить не потенційний архітектор, а той, який недавно долучився до проєкту. Так він може побачити купу проблемних місць і таких, які потрібно змінити.

Потенційний архітектор повинен знати інструменти, які будуть для нього ефективними в створенні артефактів. У першу чергу UML-діаграми, бо з них усе починається.

Зараз ще є концепт С-4 — ми використовуємо їх у нашому проєкті. Це чотирирівневі діаграми з підходом як в Google-картах: на першому рівні ти ніби дивишся на всю земну кулю згори (System context diagram), на другому — трішки наближаєш, бачиш країни (Container diagram), на третьому — це ближче, бачиш міста (Component diagram), а ще на четвертому — вулиці та будинки (Code).

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

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

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

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

Які курси можуть допомогти людині, що хоче стати SA

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

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

Деякі курси створюють спеціально для архітекторів чи СТО: там не заглиблюються в деталі, але розповідають найважливіші поїнти, які дозволять на етапі архітектури зрозуміти, підходить це вам чи ні. Завдяки таким курсам на знайомство із певною технологією ти витрачаєш не 100 годин часу, а, наприклад, вісім.

Що почитати людині, яка хоче бути хорошим Solution Architect

Мені дуже сподобався Роберт Мартін «Чиста архітектура. Мистецтво розробки програмного забезпечення». Ще одна з моїх улюблених — «97 Things Every Software Architect Should Know». Коротко й по суті.

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

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

👍ПодобаєтьсяСподобалось15
До обраногоВ обраному11
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

Було б корисно, напевно, поділитися ще ресурсами, крім названих 2 книжок, одна з яких це просто вода яка вас архітектури не навчить (я про онкл Боба).

Є хороший курс від fwdays — fwdays.com/...​/architecture-course-2021
Крутий курс Developer to Architect від Марка річардса: developertoarchitect.com/lessons

Мій топ книг:
— Fundamentals of Software Architecture
— Software Architecture: The Hard Parts
— Software Architecture in Practice
— Designing Data-Intensive Applications
— Building Evolutionary Architectures
— Building Microservices
— Designing Software Architectures: A Practical Approach
— Domain-Driven Design
— Implementing Domain-Driven Design
— Microservices Patterns
— The Software Architect Elevator

A ще є Well architected frameworkи під різні клауди та ціла купа reference architectures під кожний домен

У цій професії важливіше володіти меншим скопом, але дуже глибоко

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

Архітекту якраз важливо мати великий technical breadth для того щоб можна було вирішувати проблеми підходящими інструментами а не все за допомогою шруповерта (бо я його знаю дуже «глибоко»).

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

Якщо архітектор знає дуже багато технологій, скоріше за все його знання поверхневі

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

Панове — читайте Clean Architecture дядька Боба (Роберт Мартин) , воно трохи розуміння додасть за сам дизайн. Та і взагалі читайте, джуніори не люблять що їм коштує багато-багато часів на повторення помилок які вже хтось до них робив.

Панове — читайте Clean Architecture дядька Боба (Роберт Мартин) , воно трохи розуміння додасть за сам дизайн.

Пнове, не читайте Дядю Боба, читайте SEI

Software Architecture in Practice SEI series, це власне книга не для програміста, а для DevOps. Та всеодно це теж прочитати добре. Та не треба починати з вищої математики, тим хто на знає базову арифметику.

Це власне дуже добрий приклад хорошого контенту для архітекторів, а не DevOps. Що там «девопсного»? Сценарії для формулювання quality attributes, які вони не роблять, або тактики для їх адресування?
Стилі і дезайн також до девопсів нічого не має.

Можете пояснити з чого Ви взяли що Software Architecture in Practice це книга для DevOps? Здається Ви її не читали або сплутали з чимусь іншим

Мені дуже сподобався Мартін Пауер «Чиста архітектура. Мистецтво розробки програмного забезпечення».

Ви мали на увазі Роберта Мартіна(aka Uncle Bob)?

Так. Виправив, дякую за коментар

Як почитаєшь доу то у всіх зп від 8-15K а тут оказується архітектор стільки має 7-8К $ ))

Бо 7-8 сіньором то аутстаф або няпряму, з гарною англійською, в таку компанію архіткектором з вулиці дуже важко зайти, бо в продукті їх за звичай вирощують самі, здебільшого аріхтекти саме з галер, тому і зарплати відповідні.
Про 15К для сіньора то казочки.

Все залежить від контексту і компанії. Легко можу уявити Java Solution Architect з ЗП у 15к)))

вы шо, до сих пор не в курсе про Андрейку Никишаева с его 24к/мес?))
dev.ua/...​ioho-arhumenty-1691502545

Он теперь тикток-воен, может себе позволить

Це погано. Американські та Європейські компанії і так йдуть з Українського ринку через дорожнечу, неадекватність та війну.

Ну ващет запросы и правда жлобские, хотят СОЛЮШЕН архитекта, с 5 годами ахитектом,с опытом в блокчейне, за жлобские 350 евросов. Это ценник на синьора далеко не топ, на просторах ес.

о май гад, целый СОЛЮШЕН. Это его так в его текущей конторке обозвали небось? Или он сам себя? И вы сильно переоцениваете блокчейн, обычный it-сегмент со своим стеком технологий, остальное сущий хайп (это я вам как с опытом в одном только блокчейне ~4 лет говорю).
Слишком дохрена он хочет. Прям очень. Но наверное неспроста, потому что знает где и как искать лохов, ничем другим это не объяснить.

просто я уверен что кто-то люто пи.дит.
Хотя...Если работать например 6 часов в месяц по $800/час, то поверю)))

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

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

Віриш ти йому чи ні, це лише твоя проблема, для початку подивись стек його і досвід.

Ну власне принаймні сам DOU чесно пише, що народу у кого ЗП заходе за 10к — меньше за 1%. При цьому в тій же долині це така собі середня зарплатня, хоча звісно різні обізяни вихваляються 10 оферами на пів мільйона від яких вони відмовились, бо є набагато кращі пропозиції, що правда самі офери для свірки показати не хочуть. Це приблизно рівень спартака субботи. Реальність ЗП за 5к вже не так і багато народу має, та і 5 к теж дуже далеко не у всіх. А там і дійсно коли еполети надали та зірки — а гроші ні, ну і виглядаєш, що клоун у костюмі Наполеона, і як папуга повторюєш «Кєша СТО! Кєша архітектор!».

Колись назвава одному типу свою ЗП ))
За єтим последовало: «ооооо я знаю одного чєловєка, которій с твоими годами опыта получаєть 15000$»))

Він вміє зрозумілими словами пояснити бізнесу складні технологічні речі

Основна задача Solution Architect навішати «лапші» заказчику як йому зроблять «красіво».

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

Я таких знаю не мало. Щоправда знаю людей які справді відповідають тайтлу, справді в змозі вирішити технічні питання із командою клієнта. Зазвичай це народ на релокейті. Нажаль співвідношення нормальних людей до виїбщіків десь 1:3. Тобто переважна частина тих хто формально має тайтла, реально повний писець дніще, їм навіть юніт тести не можна доручити писати. Те саме «сініор менеджери». Та такий бізнес, вміти продавати та викручуватися задля грошей значно дорожче ніж реально щось робити.

Канешно, усе сінори роблять, топи лише в носі колупаються, звідки вони тільки гроші беруть :-)

Давайте розбирати :)

Як ви думаєте, люди які володіють бізнесом розумні чи ні?
Як ви думаєте за що бізнес готовий платити найманому робітнику?
Як ви думаєте кому бізнес готовий платити більше робітнику який зробив задачу і більше не конвертується в гроші або тому хто може створити потік грошей для компанії?
Як ви думаєте чи може людина яка просто вміє малювати красиві картинки приносити бізнесу гроші (в двогостроковій перспективі в об’ємі який компенсує витрати на співробітника)?
Як ви думаєте чи буде бізнес платити гроші співробітнику який не приносить прибуток?
Як ви думаєте чому бізнес просто не наймає команду розробників замість того щоб звертатись до outsorce компанії?

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

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

В аутсорсі це теж на сам перед сейлова позиція. Навіть формують цілі команди «архітекторів», які усім чим займаються — естімейтінгом та пресейлами. Доходе до маразму, коли в тих командах люди які крім «архітекторами» взагалі більше ніким не працювали, реільно команди з пацанів 23-24 років. Як вони естімейтять самі розумієте, потім поз’являються червоні проекти, які підписались за місяць зробити.

Ой я після таких розгрібав якось
Лебідь рак на щука

Звичайно не всім потрібна ця роль. А от знання system design для розробника це дуже важливий хард скіл.

Готуюся здавати сертифікацію AWS Solutions Archtect. Амазон — це українці?

не варто плутати сертифікаці

Solutions Archtect

з посадою. Це різні поняття

не варто плутати сертифікаці

Solutions Archtect
з посадою. Це різні поняття

Ржака це й у тому, що посада СА в Амазоні — це не СА, а скоріше присейлс.
Тому маємо принаймні 3 (а по факту 4) різних поняття з однією назвою :)

У моїй аутсорс-компанії СА це теж «скоріше присейлс». (Саму статтю я не читав, нецікаво.)

В Amazon є такий тайтл робочий ? BTW А взагалі то красива назва для сіс адміна, який тепер або DevOps або Claud Ops називають. Нічого особистого — лише комерція, люди роблять свій гішефт.

В Amazon є такий тайтл робочий ?

Так. www.amazon.jobs/...​query=Solutions Architect

А взагалі то красива назва для сіс адміна

Для сисадмінів інші типи сертифікацій, називаються SysOps і DevOps.

Sysops +devops =SRE

Девопс не посада а практика
Дба +девопс = DBRE
QA + DevOps = автоматизатор пайплайнів

В термінологіїй амазон сертифікатів SysOps
DevOps ceрьифікат є
Але це не зовсім посада
Швидше додаткові скіли і практики
Які с сисопса роблять SRE

для тих, хто стикався з «архітектами» з Амазону — не смішно.

Ні, це не типово українська фішка. Я працював як Enterprise Architecture Consultant для компаній по всьому світу (там більше 100 буде) і 80% з них мають Solution Architect. Від компаній як MTN, Philips, Pandora, Generali, до Starbucks і Thales.

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

А, ну так, це в категорію «дуже серйозний ентерпрайз». Я може не зовсім правильно розставив коми.
Так то дійсно, їхав менеджер через менеджер, бачить менеджер менеджер в менеджер :-)

А то в західних продуктових конторах / стартапах, я такого особливо не бачив

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

і команда може сама вирішувати що і як будує.

Хто несе відповідальність?
В РАСІ матриці у нас завжди 1 А. Якщо їх декілька, то буде бардак.
Власне тому часто в таких «горизонтальних командах» з’являється «технічни лід»

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

і вмінням малювати красиві високорівневі рішення.

... не в даючись в подробиці реалізації а тому абстрактно безглузді щось типу «а тут у нас база даних а тут у нас кеш» но на малюнку (power point) кросівоє ))

По нормальному це малюэться красівоє з однією метою — виманити у клієнта вимоги. Створюєш документацію по словах клієнта (бо в них її зазвичай просто нема) і питаєш — так воно ? Якщо ні — підмальовуєш, це такий базис пресейлу чи взагалі з’ясування вимог. Коли в продукті працював, теж допомагало вибити час з керівництва щоб зробити якісь необхідні речі. Бо як не поясниш як до гумової качки, що конкретно робитимеш, так щоб дійшло — скажуть не виєжуватись йти та робити сапорт потенційним клієнтам (лідам) а не віднімати час у їх величності керівництва. Бо твої проблеми то — то твої проблеми, а «конторі» (насправді керівникові) треба гроші — а не : нові фітчи, абгрейди фреймверків та рефакторінги щоб там щось. Коли пояснеш — що це скажімо такий от фікс чи фітча, це мінус 300 годин супорту на виході і відповідно більше лідів можна обробити тією самою командою за той самий час, то реально дають можливість робити, прикриють на сапорті тощо. Картинки різні діграми з графіками, мають властивість пояснювати абстракції значно краще за слова.

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

youtu.be/iDbyYGrswtg

youtu.be/Vywf48Dhyns

Ну може навіть і до такого youtu.be/yL_-1d9OSdk :)

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

Ви спочатку опишіть свої позиції в усіх компаніях в яких працювали щоб ми розуміли що це не просто суб’єктивна думка ноунейма який пропрацював 10 років в ноунейм компаніях.
Можливо варто зайти на indeed.com, вбити Solution Architect і пошукати по USA щоб казати чи це чисто укр фішка?

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