Пʼять рекомендацій, щоб дорости до Solution Architect

Мене звати Максим Дябін, я співпрацюю з ЕРАМ Україна у ролі старшого архітектора рішень. Окрім роботи на проєктах для клієнтів, я займаюсь розвитком та навчанням майбутніх Solution Architects.

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

У 2004-2005 роках я працював адміністратором і навчався програмуванню в університеті та на курсах. Проте комерційне програмування та навички, які дають під час навчання більшість шкіл та ВНЗ, дуже відрізняються. У своїй першій компанії в Харкові я почав спілкуватись з колегами і старшими товаришами, заглиблюватись у тему, читати професійну літературу і прокачуватись практично.

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

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

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

Що відрізняє програміста від архітектора

На мою особисту думку різниця між Senior і Lead інженером не така й велика з точки зору технічних знань. Проте вона помітна у фокусі на людей, роботу з командою. Якщо це вам цікаво, то з рівня Senior уже можна долучатись до певних архітектурних задач. Наприклад:

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

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

Наприклад, колись я працював з клієнтом, який хотів швидко мігрувати одне з рішень з власного обладнання в хмари. Після першопочаткового спілкування ми зупинились на найпростішому методі з мінімальними змінами в коді — тобто на lift and shift. За декілька місяців після початку роботи ми дізнались, що команда інженерів безпеки з боку клієнта почала налаштовувати бібліотеку, яка була написана на іншій технології (рішення було на .NET, а запропонована бібліотека — на Java) і не була врахована в системі раніше.

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

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

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

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

Рекомендація 1. Читати якомога більше професійної літератури

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

Ось джерела, які подобаються особисто мені:

• Code Complete, Second Edition: A Practical Handbook of Software Construction (Developer Best Practices)
• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
• Software Architecture in Practice (SEI Series in Software Engineering) 4th Edition
• Release It! Design and Deploy Production-Ready Software (2nd Edition)
• Domain-Driven Design: Tackling Complexity in the Heart of Software (1st Edition)
• Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems 1st Edition

Ці та деякі інші, вже не настільки актуальні книги, допомогли мені справлятися з проєктами у різних доменах на C# і .NET-платформі, а за декілька років мого досвіду було достатньо для переїзду в Сполучені Штати.

Рекомендація 2. Розширюйте професійний обрій

Коли я переїхав до США, то швидко виявилося, що знати одну мову програмування не завжди добре. Тому в певний момент я почав розширювати свої професійні обрії і вивчати нові стеки технологій. Додалися Java, Closure і багато інших.

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

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

Вбирайте корисні знання, які є навколо вас. У період своєї закордонної роботи я певний час працював у американській компанії, яка є одним з засновників практики TDD. Також в ній активно застосовували парне програмування, CI/CD та всі Agile методології. Найцікавішим було те, що адепти і співзасновники цих методологій бачили їх трошки інакше, ніж ми звикли в офшорі.

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

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

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

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

Рекомендація 3. Занурюйтесь у те, як працює бізнес

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

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

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

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

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

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

Рекомендація 4. Опануйте пріоритизацію

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

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

Головне — розуміти, що все неможливо робити одночасно, тому необхідно свідомо обирати, що вас наближує до мети, а що — ні.

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

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

Рекомендація 5. Розширюйте технічний світогляд

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

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

Особисто я переконаний, що до певного рівня необхідні курси, книги, університетська освіта, сертифікації та обов’язково індивідуальна практика. Усе це створює фундаментальні знання і потрібний світогляд. Водночас не варто зупинятись: лише за останні роки з’явилась велика кількість технологій, наприклад, у Front-end, яка потребує знання фундаментальної науки та володіння навичками розробки алгоритмів, розуміння, як комп’ютери взаємодіють у розподілених системах, що саме і як роблять операційні системи. А ще навіть за умови використання систем на базі ШІ важливими і корисними залишаються Domain specific languages.

Поділюсь переліком книг, які були корисними для мене в кожній з тем:

• Algorithms (4th Edition)
• Distributed Systems: Principles and Paradigms 2nd Edition
• Windows Internals: System architecture, processes, threads, memory management, and more, Part 1 (Developer Reference) 7th Edition
• Domain-Specific Languages (Addison-Wesley Signature Series (Fowler)

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