Хто такий 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
і є ще біля десятка інших визначень і розгалужень архітектури.
Отже, поняття «Архітектор» — настільки ж розгалужене як і поняття «програміст», або навіть інженер.
Проте в більшості випадків, під архітектурою мають на увазі такі речі:
- Application Architecture
- System Architecture
- Software Architecture
- 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 менеджер, бізнес аналітик, дизайнер інтерфейсів. Також багато комунікації відбувається із бізнес стейкхолдерами та командою розробників.
Таким чином Архітектор являється живим мостиком між бізнесом і технологіями.
Які поради для менеджерів, розробників, тестерів...
- Думати над архітектурою потрібно раніше, ніж проект «приїхав». Саме по собі залучення Архітектора на проект може не вирішити проблему. Є навіть така абревіатура — DOA — dead on arrival. Це коли приходиш на проект і розумієш що його потрібно переписувати з нуля із детальним аналізом вимог — функціональних і нефункціональних, і далі тільки думаєш, як це правильно пояснити клієнтові.
- Брати до уваги нефункціональні вимоги з не меншим пріоритетом ніж функціональні. Те, ЯК програма буде працювати в «бойових» умовах реального світу не менш важливе того, ЩО вона буде там робити. Якщо ви героїчно побудуєте MVP в стислі терміни, а потім ваші користувачі розчаруються в ній як в повільному, ненадійному і небезпечному «непорозумінні» — вважайте ваш героїзм марним.
- Залучати Архітекторів до зустрічей, де обговорюються ключові технологічні рішення. Часом буває що Архітекторові просто дають список фіч, що описані одним реченням, і просять оцінити в часі, або навіть зробити на базі того якісь архітектурні рішення. Є золоте правило — Shit in — Shit out! Отже, Архітектор, як представник технічного світу, має бути якнайближче до бізнесу і володіти максимальним контекстом.
- Архітектор — не супермен-вікінг. Він не перепише вам проект за тиждень, який робився півроку. Архітектор це T-shaped спеціаліст, а це означає, що заради широкого охоплення різних знань, він з часто стає менш заглибленим спеціалістом, навіть в своїх профільних задачах. Архітектор може вказати вам шлях в майбутнє вашого продукту (звичайно якщо це майбутнє у нього є). А йти цим шляхом вже доведеться вам самим.
Відео з Олексієм можете переглянути тут. А в коментарях написати, про яких ще спеціалістів хотіли б дізнатись.
21 коментар
Додати коментар Підписатись на коментаріВідписатись від коментарів