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

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

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.