Мій шлях від Front-end розробника до Solution Architect

💡 Усі статті, обговорення, новини про Front-end — в одному місці. Приєднуйтесь до Front-end спільноти!

Вітаю, друзі. Моє ім’я Павлин, я Solution Architect у компанії Valtech, хочу поділитися своїм шляхом від Front-end Developer до Solution Architect.

Моя кар’єра в ІТ почалась з того, що я хотів спробувати себе у веброзробці, але не був певен, який саме сегмент ІТ мені цікавий. Маючи освіту за фахом «Програмна інженерія», вирішив рухатися в сторону Front-end, тому що робота на клієнті та взаємодія з юзером мені більше подобалась, ніж серверна частина та бази даних.

Спочатку працював над landing pages та простими e-commerce проєктами, потім брав участь у створенні стартапу з командою з п’яти людей. Думаю, багато хто згадує свої перші кроки в IT із вдячністю за набутий досвід. Так я отримав свої перші навички і вдячний своїм менторам. У малій команді сам обирав технологічний стек, будував архітектуру для Front-end застосунку й навчився враховувати технологічне рішення загалом: Back-end, Front-end, DevOps, QA, etc.

Набравшись досвіду, зрештою, я перейшов у Valtech, де працюю вже шість років.

Професійний ріст та основні майлстоуни

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

З переходом на позицію Senior я був залучений у повний цикл планування проєкту. Командою оцінювали весь скоуп, розбитий на фічі. Ми використовували planning poker, і новим для мене було те, що ми мали дати оцінку в сторіпойнтах, враховуючи зусилля на розробку не тільки Front-end, а також Back-end та QA. Тобто треба було подумати наскільки складна буде реалізація з точки зору Back-end розробника та скільки часу витратити на тестування загального функціоналу.

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

За декілька років роботи на подібних програмах, здобув багато корисного досвіду і отримав позицію Team Lead. Я був залученим до архітектурної частини проєктів, відвідував зустрічі з клієнтами та вивчав, як ухвалюються рішення, які в подальшому вплинуть на побудову архітектури. Тісно співпрацював з архітекторами і вчився в них.

Cамоосвіта

Практичного досвіду на проєктах не завжди вистачає. На мою думку, гарний спеціаліст повинен слідкувати за трендами розробки та сучасного вебу. Я використовую різні ресурси, але з основних можу виділити: web.dev, medium, hackernoon, YouTube.

Також треба отримувати нові знання у різних площинах, таких як soft skills та hard skills.

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

З особистого досвіду можу виділити такі:

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

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

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

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

Гарні комунікаційні навички допоможуть вам краще доносити свої ідеї, дадуть інструменти для розуміння людей та пошуку компромісів. Що я використовую:

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

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

Мені, як Front-end розробнику, цікаво вивчати нові фреймворки і бібліотеки, тому це було перше, на що я звертав увагу. Переважно це React, Vue та екосистема, що їх оточує. Також стежу за Astro, метафреймворками, загальними темами з application performance та infrastructure.

Та зрозумівши, що я хочу розширити свої технічні знання та зрости до архітектора, я почав вивчати Back-end Node.js, основи DevOps та QA.

Більшість матеріалів я знаходив на YouTube та різних технічних блогах, але основною платформою для навчання стала Udemy. У нас у в компанії є Udemy Business, тому матеріалів для навчання було достатньо, треба було знайти тільки час.

Тут я зібрав основні матеріали, які я взяв для самоосвіти, і які допомогли мені зрости до позиції Solution Architect.

• Mastering Data Modeling Fundamentals;
• Advanced Business Writing Skills;
• The Complete DISC Personality Masterclass — You & Them;
• Cross-Cultural Communication: How To Flex Your Style;
• Cypress: Web Automation Testing from Zero to Hero;
• The Complete GitHub Actions & Workflows Guide;
• DevOps, CI/CD (Continuous Integration/Delivery);
• NodeJS — The Complete Guide (MVC, REST APIs, GraphQL, Deno);
• Pragmatic System Design;
• Storytelling Fundamentals for All;
• Data Warehouse Fundamentals for Beginners;
• Docker & Kubernetes: The Practical Guide.

MACH and Сomposable: зміна трендів у веброзробці

MACH (Microservices, API-first, Cloud-native, Headless) та Composable — тренди, які значно вплинули на веброзробку. Ці підходи дають розробникам більше гнучкості, швидкості та масштабованості, і роблять вебзастосунки більш ефективними та сучасними.

MACH — це архітектурний стиль, який базується на чотирьох принципах:

1. Мікросервіси: розбиття вебзастосунків на невеликі, незалежні служби.
2. API-first: використання API для зв’язку між службами та з клієнтськими застосунками.
3. Cloud-native: розміщення вебзастосунків у хмарі для забезпечення гнучкості та масштабованості.
4. Headless: відділення Front-end та Back-end частин вебзастосунків.
5. Composable — це методологія розробки, яка фокусується на створенні вебзастосунків з багаторазових компонентів. Ці компоненти можуть бути візуальними (кнопки, картки) і функціональними (авторизація, корзини покупок, тощо).

Здебільшого я працював з монолітними платформами для створення вебсайтів у різних доменах: DXP Sitecore, e-commerce Salesforce та Magento. Але згодом майже кожна платформа намагалась відповідати трендам, і всі почали рухатись у Headless Composable stack.

Так я почав вивчати Headless CMS типу Contentstack та Contentful, знайомитись з e-commerce Headless рішеннями, такими як Commercetools. Salesforce та Magento також мають своє Headless API та Front-end фреймворки для розробки.

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

Становлення архітектором

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

Наша Upskilling програма тривала шість місяців, ми запартнерились з IASA, перші вісім тижнів я проходив курс Architect Core. Далі у був період, де я брав участь в пітчах і розробляв свій солюшин, який в кінці презентував для колег.

IASA (International Association for Software Architects) Global — це організація, що об’єднує професіоналів у сфері архітектури програмного забезпечення з усього світу. Вони займаються підвищення кваліфікації та розвитком спільноти архітекторів, а також просуванням цієї професії в ІТ-галузі.

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

Architect Core від IASA — метою цього курсу було надати необхідні знання та інструменти для розробки архітектури бізнес-технологій (BT), що відповідають вимогам сучасного бізнесу.

Курс містить такі теми:

• архітектурне мислення: формування основи та заохочення архітекторів до системного мислення;
• залученість в архітектуру: розуміння ролі та методів залучення архітекторів;
• вимоги до архітектури: з’ясування потреб бізнесу;
• забезпечення архітектури: задоволення потреб бізнесу та реалізація архітектури;
• практика архітектури: оптимальне впровадження архітектури в організації або бізнесі.

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

Щоб краще зрозуміти задачу та знайти підходяще рішення IASA пропонує використовувати набір різноманітних канвасів (canvas), які допоможуть візуалізувати проблему, створити артефакти та допоможуть прийняти рішення. Ці канваси та іншу інформацію можна знайти на сайті BTABoK.

BTABoK

BTABoK (Business Technology Architecture Body of Knowledge) — ресурс, що надає знання та інструменти для створення і реалізації успішної стратегії бізнес-технологій (BT). Фактично це база знань, розроблена IASA Global з найкращими практиками, концепціями та моделями, які необхідні для ефективного проєктування, розробки та впровадження BT-архітектури.

BTABoK охоплює широкий спектр тем, зокрема:

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

Практичне завдання у межах компанії

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

Задачі: визначити тему, розробити архітектурні діаграми, провести експерименти, реалізувати архітектуру та створити робочий прототип, який потім можна буде презентувати клієнту. Додатковою умовою було те, що культурний профайл клієнта, вибраний випадковим чином. Мені попався Dutch cultural profile.

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

Для побудови канвасів я використовую Miro Board. Ось так це в мене виглядає:

Спочатку я визначив мету: розробити акселератор, який поєднає декілька технологій у єдине рішення, що допоможе швидше стартувати проєкти і матиме шаблон та структуру коду, стандартизувати підходи до розробки. Вигодою для клієнта буде: faster time to market, costs saving, scalability, maintainability.

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

Моє схематичне зображення процесу проєктування архітектурного рішення:

Канвас Canvas Flow Map із сайту BTABоК

Мені було цікаво, як архітектор має бути залученим у потреби бізнесу. Це не про запропонувати технологічне рішення. Найважливіша частина роботи архітектора — визначити проблему клієнта, його бажання, цілі та потреби.

Початковою точкою планування може бути SWOT-аналіз та заповнення відповідної канви.

SWOT — це абревіатура, що розшифровується як Strengths (Сильні сторони), Weaknesses (Слабкі сторони), Opportunities (Можливості) та Threats (Загрози). Це метод аналізу, який використовується для оцінки сильних та слабких сторін організації, а також можливостей та загроз, з якими вона стикається.

Ось так це виглядає в мене:

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

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

Структура мого експерименту базувалася на стандартній схемі:
Action: What are you going to do.
Reason: Problem you face.
Expectations: what outcomes do you expect.
Duration: hours/days/weeks.

У своїй роботі я використав декілька типів шаблонів для проведення експерименту, а саме:

• OKR Card (Objectives and Key Results);
• NABC Card (Need, Approach, Benefits, Competition);
• experiment Card.

Приклад канвасу для одного з моїх експериментів:

Канвас OKR CARD із сайту BTABоК

Канвас NABC CARD із сайту BTABоК

Канвас EXPERIMENT CARD із сайту BTABоК

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

Нагадаю, що моєю метою було розробити акселератор, який поєднає декілька технологій у єдине рішення, що допоможе швидше стартувати проєкти і матиме шаблон та структуру коду, стандартизувати підходи до розробки. Вигодою для клієнта буде: faster time to market, costs saving, scalability, maintainability.

The purpose of a business is to get and keep a customer. Without customers, no amount of engineering wizardry, clever financing, or operations expertise can keep a company going. Prof. Theodore Levitt

На цьому етапі я продумував наступні пункти:

• сегменти клієнтів;
• ціннісні пропозиції;
• канали;
• взаємовідносини з клієнтами.

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

Наприклад, ціннісна пропозиція мого акселератора: faster time to market, costs saving, scalability, maintainability. Якщо переносити це на бізнес клієнта, на канві його бізнес-моделі впровадження акселератора впливає на costs, customer segments, customer relationships, key partners.

Канвас Business Model із сайту BTABоК

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

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

Ось приклад з точки зору Developer Experience:

Канвас PERSONA CARD із сайту BTABоК

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

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

Фінальний етап підготовки — це створення презентації. Це саме та частина коли ти можеш «продати» своє рішення клієнту. Я сконцентрувався на сторітелінгу, підготував слайди та діаграми. Усе це було на моїй Міро дошці.

Це план моєї презентації:

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

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

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

Звісно треба бути готовим до Q&A сесії або прямих питань відразу під час презентації.

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

Для оцінки культурного профайлу використовував теорію культурних вимірів Хофстеда за допомогою ресурсу Hofstede Insights, а також Gemini by Google (Bard) та ChatGTP. Решту аналізу я робив згідно з висновками курсу, який я зазначав вище у секції самоосвіти.

Картинка з сайту Hofstede Insights

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

Важливо:

• демонструйте свою експертність;
• будуйте довіру та партнерські відносини;
• відкрито обговорюйте ціни та умови.

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

Коротка самопрезентація:

• хто я і мій досвід у вирішенні бізнес-проблем.

• яка проблема і на кого вона впливає?
• чому вирішення цієї проблеми є важливим?

• які методи та інструменти ви використовували для аналізу та вирішення проблеми?
• чому ви обрали саме ці методи?

• у чому полягає рішення?
• які ключові особливості та переваги вашого рішення?
• наочне демонстрування рішення (слайди, відео, прототип).

• чому ваше рішення краще за альтернативні варіанти?
• які критерії порівняння ви використовували?
• порівняння з існуючими рішеннями на ринку.

• де та як вже застосовується ваше рішення?
• які позитивні результати досягнуто завдяки його впровадженню?

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

• які технічні, інші ресурси необхідні для інтеграції рішення?
• навчання персоналу, технічна підтримка, супутні інструменти;
• наступні кроки після впровадження рішення.

• зробіть презентацію візуально привабливою та легкою для сприйняття;
• використовуйте факти, цифри та приклади для підтвердження ваших тверджень.

Presales and RFP

У Valtech в обов’язки архітектора входить участь у Presales- та RFP-процесах.

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

RFP (Request for Proposal) — це запит на пропозицію, який використовується компаніями для пошуку постачальників продуктів або послуг.

Над Presales та RFP працює команда. Треба оцінити вимоги та потреби клієнта, запропонувати декілька варіантів технічних рішень. З MACH архітектурою існує багато варіантів, які технології можна поєднати для досягнення бізнес цілей. В основному, моя робота полягає у тому щоб вибрати e-commerce provider, Headless CMS, search engine, infrastructure, та інші потенційні інтеграції.

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

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

Growth Framework

У нас в компанії є Growth Framework, який допомагає спеціалістам з self assesment зрозуміти свій поточний рівень та визначити цілі для росту. Це рішення базується на SFIA та SMART-цілях.

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

SMART — це абревіатура, що розшифровується як Specific (конкретні), Measurable (вимірні), Achievable (досяжні), Relevant (актуальні), Time-bound (обмежені за часом). Ця методика допомагає чітко сформулювати цілі, щоб ви могли їх ефективно досягати.

Наприклад, моя ціль звучала так Fundamentals of Data Modeling. А по SMART:

Specific: Я отримаю розуміння основних принципів і практики моделювання даних, охоплюючи такі аспекти, як концептуальне моделювання, логічне моделювання та фізичне моделювання.

Measurable: Я досягну цього, виконавши наступне:

• проходження онлайн-курсу «Основи моделювання даних»;
• створення моделі даних для особистого проєкту, використовуючи обрану методологію моделювання (наприклад, діаграми ER для реляційних баз даних);
• чітке пояснення ключових концепцій моделювання даних, таких як нормалізація, первинні/зовнішні ключі та типи даних, колезі.

Achievable: 16 годин по дві на тиждень впродовж восьми тижнів для вивчення та проходження онлайн-курсу.

• вісім годин: по чотири на тиждень впродовж двох тижнів на розробку моделі даних особистого проєкту;
• планування обговорення з колегою для демонстрації розуміння впродовж тижня після закінчення курсу.

Relevant:

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

Time-bound: Я досягну цієї мети впродовж другого кварталу.

Висновки та поради

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

Головне про що треба пам’ятати:

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

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

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

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

The ideal architect should be a man of letters, a skilful draftsman, a mathematician, familiar with historical studies, a diligent student of philosophy, acquainted with music, not ignorant of medicine, learned in the responses of jurisconsults, familiar with astronomy and astronomical calculations. Vitruvius Roman Military Enginee.