Хто такий Solution Architect в телекомі: потрібні навички, стек технологій, кар’єрні перспективи

Мене звати Сергій. Я працюю Solution Architect в сфері телекомунікацій. Мій досвід нараховує 17 років і включає як роботу на операторів зв’язку, так і на виробників обладнання для мереж, а також виробників програмного забезпечення для керування підприємствами операторів зв’язку.

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

Треба уточнити, що під Solution Architect в телекомі я маю на увазі того архітектора, якій має справу з рішеннями на базі програмного забезпечення для оператора зв’язку, але не мережі оператора. Хоча мережі і програмне забезпечення підприємства зв’язку — дуже пов’язані речі в деяких точках, і це буде розглянуто нижче. Посади такого роду можуть мати різні назви BSS (або OSS) Solution Architect, Telecom (або Telco) Solution Architect, або просто Solution Architect (тут треба дивиться на опис посади). В цій статті я буду використовувати назву Telecom Solution Architect, щоб постійно нагадувати в якому контексті іде розповідь.

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

Цю статтю вважаю цікавою для «світчерів»; початківців в сфері Software Architecture; тих, хто вже підступився до цієї ролі на кар’єрному шляху, але трошки застряг, не розуміючи, як зробити перехід. Також цікаво буде тим, хто пов’язаний з пошуком та наймом спеціалістів. Допоможе розібратись у особливостях та ефективніше шукати кандидатів і релевантно пропонувати вакансії. IT-компанії (аутсорс, аутстаф, інтегратори), які мають Центри Компетенції (Center of Excellence), а також систему оцінювання і розвитку співробітників, і працюють з проєктами у сфері телекому, також мають гарну нагоду зрозуміти, що Solution Architect в телекомі треба оцінювати трохи інакше ніж тих Solution Architect до яких вони звикли. Та і досвідченим архітекторам з інших сфер теж, напевно, буде цікаво глянути на колег по архітектурному цеху.

Хто є Хто

В галузі програмного забезпечення є багато різних типів архітекторів. Кожна компанія має своє розуміння щодо архітекторів, їх градації і назви. Насправді не існує якогось стандарту, який б однозначно описував всі можливі варіанти архітекторів, але є більш менш прийнята в спільноті класифікація. Обговорення цих класифікацій не є метою цієї статті. Головне, що я хочу показати тут — це те, що Solution Architect в телекомі працює над створенням архітектури рішення рівня підприємство, використовуючи готові програмні продукти, застосунки, системи одного або різних вендорів. Telecom Solution Architect не пише код, не робить ревью коду, не робить конфігурації будь-чого, не розробляє архітектуру додатків. Програмування для такого фахівця не є обов’язковою вимогою, хоча є хорошою додатковою навичкою. В той час як Solution Architect (до якого звикла більшість IT-спільноти) пов’язаний з програмуванням і працює над створенням саме програмного продукту, використовуючи різні мови програмування, бази даних, бібліотеки і фреймворки, як елементи архітектури.

Коробочні рішення (OOTB — Out-of-the-Box) в телекомі не впроваджуються як є. Завжди треба щось допрацювати для задоволення бізнес вимог. Тому коли Telecom Solution Architect проєктує рішення, зазвичай виникають ситуації які, вимагають написання кастомних компонентів для «узгодження» різнотипних інтерфейсів між системами. Або треба зробити кастомізацію в продукті. І для цього Telecom Solution Architect використовує співпрацю з відповідним Software Architect, або Application Architect, або Integration Architect та іншими.

Можна сказати, що Telecom Solution Architect являє собою роль, діяльність якої сфокусована на області перетину індустрії телекомунікації і інформаційних технології (IT). Зазвичай, ця область фокусу більше ніж сам перетин індустрій, і переходить в сторону телекомунікації та/або інформаційних технологій в залежності від особливостей проєкту, зацікавленості людини і т.і.

Де працює

Роль Telecom Solution Architect потрібна на боці вендорів програмних продуктів, інтеграторів та самих операторів зв’язку. Також можуть бути різні консалтингові компанії, аудитори тощо.

Telecom Solution Architect може брати участь

• в передпродажних (pre-sale) активностях — в створенні або відповіді на RFI (Request for Information)/RFP (Request for Proposal) запити;
• в аналізі існуючого рішення;
• в розробці архітектури нового рішення і його впровадженні, тестуванні, і передачі в експлуатацію;
• в розробці нового функціоналу в існуючому продукті, або розробці нового продукту.

Це все спрямовано на впровадження рішень для операторів зв’язку. Що собою являє оператор зв’язку з точки зору програмних продуктів? Це великий набір різних за призначенням, різних за виробником, різних за поколінням програмних продуктів, систем, які допомагають керувати підприємством зв’язку. Вони включають як продукти, зроблені професійними виробниками, так і ті, які зроблені самими співробітниками оператора (так звані in-house developed додатки).

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

Різні виробники і різні покоління систем додають складнощів і обмежень для їх інтегрування, яке треба для забезпечення роботи End-to-End процесів.

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

Масштаби проєктів

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

Бюджети варіюються від сотень тисяч доларів до мільярд+ доларів.

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

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

Вплив проєкту на користувачів і ризики можна описати так: іноді проєкти зачіпають так званні mission critical системи і процеси (наприклад, нарахування плати), а іноді ризики можна вважати мінімальними (наприклад, інтеграція з системою валідації адреси абонента).

Щодо складності проєктів. Найпростіші проєкти — PoC (Proof of Concept — підтвердження концепції) або точкове розширення якогось функціонала. Це назвемо нульовим рівнем складності і залишимо за рамками обговорення.

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

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

З чим працює

Маю попередити, що тут буде трохи нудної, але важливої теорії.

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

BSS (Business Support System, Система підтримки бізнесу) — це той прошарок програмного забезпечення, який дозволяє оператору взаємодіяти з абонентами, і навпаки. А також має доступ до прошарку OSS (дивись далі) для можливості керування обладнанням мережі. Основні функції, для прикладу, такі: Channel Sales Management (керування каналом продажів), Customer Information Management (керування інформацією про клієнтів), Customer Order Management (керування замовленнями клієнтів), Case Management (керування зверненнями клієнтів), велика група Billing and Revenue Management (керування рахунками і прибутками), Contract Management (керування контрактами), Product Catalog Management (керування каталогом продуктів — тобто, послуг і тарифних планів) і т.і.

OSS (Operation Support System, Система підтримки операції) — це той прошарок програмного забезпечення, який дозволяє взаємодіяти з обладнанням мереж оператора зв’язку. Він розташований між рівнем BSS та мережею оператора. Основні функції, для прикладу, такі: Resource Inventory Management (керування обліком ресурсів, тобто обладнанням і т.і.), Service/Resource Order Management (керування ордерами сервісів/ресурсів), Resource Domain Management (керування доменом ресурсів, сюди входить, наприклад, функція активації ресурсів/обладнання), Fault Management (керування несправностями) тощо.

Все це керується так званим TMForum (TeleManagement Forum, або скорочено TMF), який є глобальною асоціацією телеком-операторів всіх видів, постачальників рішень для телеком-сфери (включаючи виробників обладнання, програмних продуктів, хмарних рішень), інтеграторів, консультантів та інші організації, які працюють в телеком-бізнесі. На сьогодні рахується, що в TMForum входять 850+ компаній.

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

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

Бути «compliance» (відповідним) до TMF — значить, що рішення або окремий продукт будуть легко зрозумілі багатьом спеціалістам. Також це значить, що інтеграція між програмними продуктами різних виробників буде швидкою і легкою. Авжеж в реальному світі трохи не так гладко, але цього багато хто прагне.

Не існує виробника, якій би мав найкращий продукт для всіх функціональних областей. Тому оператор може обирати найкращий продукт під кожний функціональний домен від різних виробників. В той самий час оператор хоче мати деяку свободу і не залежати від конкретного виробника. Тобто мати можливість в будь-який час замінити продукт одного виробника на продукт іншого виробника без зайвих складнощів і витрат. Це іноді потрібно оператору, якщо продукт більше не в змозі задовольнити нові бізнес-вимоги, або вартість підтримки зростає, або виробник просто «викручує руки». Така незалежність називається vendor agnostic. Це досягається через застосування в архітектурі продуктів, які мають стандартизовані інтерфейси, моделі даних, процеси і т.і. Тому відповідність до TMF та інших профільних організацій має свою цінність для самих операторів. А якщо є попит, то постачальники в свою чергу намагаються відповідати.

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

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

• TAM (Telecom Application Map — Application Framework) — це довідкова, уніфікована мапа додатків, які необхідні для оператора зв’язку;
• eTOM (Enhanced Telecom Operations Map — Business Process Framework) — це довідкова, уніфікована модель процесів, які необхідні для оператора зв’язку;
• SID (Shared Information and Data Model — Information Framework) — це довідкова, уніфікована дата-модель об’єктів, які необхідні для оператора зв’язку.

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

Для наочності, опублікую тут, як виглядає TAM, зображення звідси:

Подивімось на те, як BSS/OSS, мережа та елементи TAM виглядають разом. Додаю дуже спрощену схему:

Мережа може бути будь-яка за типом: провідна, безпровідна, мобільна, супутникова або їх різноманітні комбінації.

Обов’язки

Обов’язки Telecom Solution Architect дуже схожі на обов’язки інших архітекторів в області програмного забезпечення:

• виявляти і аналізувати бізнес-цілі;
• проводити As-Is Analysis (аналіз поточного стану), Impact Analysis (аналіз впливу), Gap Analysis (аналіз прогалин);
• проєктувати рішення, створювати To-Be View (вигляд майбутнього стану) на основі бізнес-вимог, поточного стану існуючого рішення, обмежень, вимог місцевого законодавства тощо;
• описувати рішення з усіма необхідними деталями, які треба команді впровадження;
• створювати інтеграційну специфікацію, модель даних, процес;
• робити порівняння декількох варіантів архітектури, виявляти найоптимальніший, з різних точок зору;
• комунікувати із замовником, підрядниками та іншими учасниками проєкту;
• презентувати і обґрунтовувати пропоновану архітектуру рішення;
• вести перемовини і знаходити компроміс;
• підтримувати, консультувати проєктну команду в ході розробки, тестування, запуску і передачі нового працюючого рішення в експлуатацію;
• підтримувати проєктну документацію в актуальному стані аж до передачі рішення в експлуатацію;
• брати участь в presale або procurement активностях.

Коло спілкування

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

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

Навички

Hard Skills

В роботі Telecom Solution Architect знадобляться знання та інструменти з Business Analysis, Business Process Management, Project Management, Software Architecture, Enterprise Architecture.

Хард-навички Telecom Solution Architect включають наступне:

• знання процесів, які характерні телеком сфері;
• знання особливостей роботи телеком-оператора;
• поглиблені знання одного або декількох функціональних доменів телеком сфери (наприклад, Order Management, Product Catalog, Billing, Provisioning, Service Assurance і т.і.);
• знання одного або декількох програмних продуктів і рішень на їх базі (наприклад, продукти від Amdocs, Ericsson, Matrixx, Hansen, Tibco, Adobe, Salesforce, Comviva, Ciena тощо);
• знання, пов’язані з роботою мереж (якщо архітектор працює на рівні OSS, тобто пряма взаємодія програмних продуктів з обладнанням мережі);
• знання програмних інтерфейсів та інтеграції;
• вміти робити As-Is Analysis, проєктувати To-Be View, робити Gap та Impact Analysis, описувати Transition Path;
• вміти робити оцінку витрат, необхідних на впровадження рішення;
• бачити, як кажуть, «ширше»;
• вміти знаходити оптимальне рішення, яке задовольняє бізнес-вимоги (включаючи пошук компромісу);
• вміти описувати архітектуру рішення;
• мати навички проєктного керування.

В залежності від бекграунду людини, зацікавленості і бажання розвитку, в пригоді будуть знання:

• програмування (навіть базові знання, будь-яка мова);
• тестування (навіть базові знання);
• хмарних технологій (в залежності від вашого основного фокуса);
• мережевих технологій, протоколів (в залежності від вашого основного фокуса);
• міграції (навіть базові знання);
• безпеки (навіть базові знання);
• продуктивності (performance, non-functional requirements) (навіть базові знання).

Стосовно інтеграцій пораджу сайт автора Gregor Hohpe та його книгу Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions (Gregor Hohpe and Bobby Woolf). Вони дуже допомагають опанувати знання про інтеграції. На проєктах роботи з інтеграціями чимало, особливо там де є багато різних продуктів від різних вендорів.

Інструменти

Можна сформувати такий список інструментів, які стануть в пригоді Telecom Solution Architect:

• Діаграми:
  • Component Diagram (діаграма компонент);
  • Sequence Diagram (діаграма послідовності);
  • Activity, Process Diagram (діаграма активності, процесу);
  • Object Diagram (діаграма об’єкта);
  • ERD — Entity-Relationship Diagram (діаграма сутність-зв’язок).
• Моделювання:
  • UML (Unified Modeling Language);
  • BPMN (Business Process Model and Notation).
• Додатки:
  • Enterprise Architect;
  • Confluence (з плагінами: Gliffy, PlantUML, BPMN.io, draw.io та інші);
  • Microsoft Word, Excel, Visio, PowerPoint;
  • Google Docs, Sheets, Drawing, Slides;
  • Swagger.
• Фреймворки і організації:
  • TMForum (TAM, eTOM, SID та інші) (лінк на клікабельні моделі від TMForum);
  • TOGAF (The Open Group Architecture Forum);
  • SEI (Software Engineering Institute);
  • NFV MANO (Network Functions Virtualisation, Management and Orchestration);
  • MEF (Metro Ethernet Forum).

Додам кілька коментарів до списку інструментів. Enterprise Architect використовують на дуже великих проєктах в компаніях з дуже зрілими підходами до роботи над архітектурою. Зазвичай використовують Confluence з різними плагінами (навіть ті великі компанії, яких я щойно згадував). Опис архітектури рішення також зручно робити (або експортувати з Confluence) в офісних додатках від Microsoft, або Google. З моделлю даних зручно працювати в будь-якому графічному додатку, але вести детальний опис об’єктів і атрибутів зручно в Excel, або Sheets. Для презентації зручно використовувати PowerPoint, Slides.

TMF — це основа основ для Telecom Solution Architect.

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

TOGAF — стане в пригоді для росту в сторону Enterprise Architect. Він дуже узагальнений і може застосовуватись в будь-якому домені.

NFV MANO та MEF — про архітектуру рішень для керування ресурсами мережі (включаючи віртуальні ресурси), тобто OSS рівень.

Сертифікації

Декілька слів про сертифікації специфічні для Telecom Solution Architect. Наприклад, TMF пропонує і курси, і екзамени. Але вони корпоративного рівня і коштують відповідно. Один базовий курс по eTOM (для людини з компанії, яка не є учасницею TMF) буде коштувати 649 USD. Екзамен входить в цю вартість.

Інший приклад: MEF має корпоративні курси, а також надає відкритий доступ до всіх своїх документів для самостійного навчання, а екзамен коштує 420 USD.

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

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

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

Soft Skills

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

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

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

Приклад

Подивімося, як виглядає робота Telecom Solution Architect з урахуванням всього того, що описано вище.

Розглянемо таку user story: Я, як абонент, хочу мати можливість самостійно замовити sim-карту з тарифним планом і активувати його для того, щоб мати змогу користуватись послугами включеними в цей тарифний план.

Щоб спроєктувати архітектуру рішення, яка відповідає вимогам, треба розуміти глобальні бізнес-цілі оператора. Треба розуміти архітектуру існуючого рішення (всі наявні системи і End-to-End процеси на підприємстві). Це As-Is аналіз або розуміння того, що є зараз. Знати, які існуючі системи оператор хоче перевикористати в новому рішенні. А також мати розуміння стосовно нових програмних продуктів, які оператор обрав для побудови нового рішення.

Telecom Solution Architect має знати, які програмні продукти (або їх компоненти) необхідно задіяти і в якій послідовності, щоб задовольнити потреби абонента. Якими даними ці програмні продукти мають володіти і обмінюватись. Тут в пригоді стануть фреймворки і рекомендації від TMForum, a також знання продуктів вендорів, які беруть участь в проєкті, авжеж, і власний накопичений досвід. На основі всього цього Telecom Solution Architect будує архітектуру майбутнього рішення — поєднує різні програмні продукти/компоненти так, щоб задовольнялись бізнес-вимоги. Це буде To-Be View. Тобто як буде виглядати нове рішення.

Все це виконується у вигляді HLD (High Level Design — високорівневий опис). HLD — це документ з набором діаграм і описом до них з поясненнями.

Порівняння As-Is та To-Be дають можливість зробити Gap аналіз. Тобто зрозуміти, що нового додати або що змінити, щоб досягти цільової архітектури. Зміни можуть стосуватись як архітектури в цілому, так і змін в окремих системах щодо їх функціональних можливостей. Impact аналіз покаже, як перехід від As-Is до To-Be вплине на роботу існуючого, працюючого рішення, які є ризики і які кроки треба зробити, щоб вплив був мінімальним і контрольованим. На базі цього можна описати Transition path (перехідний шлях) — як саме буде виконуватись перехід від існуючої архітектури до запланованої в To-Be.

Якщо треба узгодження інтеграційних інтерфейсів між елементами архітектури — треба вирішити, хто (на стороні якого вендора, функціонального домена) і як це буде робити.

Потім це треба узгодити з відповідальними особами на стороні оператора зв’язку (замовника) і на стороні вендорів окремих систем.

Після того як HLD та інші документи погодженні усіма зацікавленими особами, можна переходити до LLD (Low Level Design — низькорівневий, детальний опис), який стосується деталізації таких речей як, наприклад, моделі данних, моделі процесів, інтеграції (інтерфейси, мапінг даних) або конфігурації систем. LLD — це теж документ з діаграмами, таблицями і описом до них. Він оперує вже такими деталями, які достатні, щоб розробник, або системний інженер, або Application Architect та інші члени команди були здатні перейти до роботи над реалізацією рішення.

На етапі LLD можливі уточнення (точкові або глобальні) в To-Be View, Gap аналіз, Impact аналіз і Transition path. Також ці документи можуть формуватись на рівні окремих програмних продуктів/ компонент.

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

Повернемось до нашого прикладу. Вищезазначену user story можна вирішити за допомогою наступних функціональних додатків згідно TAM (дуже грубо): Channel Sales Management, Product Catalog Management, Customer Order Management, Customer Information Management, Service Catalog Management, Service Order Management, Service Inventory Management, Resource Catalog Management, Resource Order Management, Resource Inventory Management, Network Number Inventory Management, Billing Account Management, Charge Calculation, Fraud Management.

Також тут треба додати інтеграції з системою платежів та з провайдером логістичних послуг (щоб доставити sim карту).

Зазначимо, що різні виробники називають свої продукти і компоненти трохи по-різному, ніж в ТАМ. А також роблять об’єднання функціональних елементів в один компонент/ продукт. Наприклад, все, що стосується Product Catalog буде в одному компоненті. Або інший приклад: виробник може зробити Order Management, який буде придатний і для Customer Order Management, і для Service Order Management, і для Resource Order Management. Ще цікавий приклад, керування телефонними номерами і sim-картками може бути реалізовано як один спільний компонент, а іноді як цілком різні компоненти, та ще і від різних вендорів.

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

Подивімося, як може виглядати архітектура рішення для задоволення вище наведеної user story. Я буду моделювати за такою легендою: в проєкті беруть участь різні вендори, частину існуючих систем використовуємо повторно. Діаграма буде належати до рівня HLD. Ця діаграма відображає To-Be вигляд. Назви вендорів скорочені, щоб уникнути реклами або інших непорозумінь.

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

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

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

Так, все це також є бізнес-вимоги, які можуть бути описані, як окремі user story. Але це не завжди так. На багатьох проєктах такі «дрібниці» просто опускають за замовчуванням, якщо в них немає чогось особливого. І тут в пригоді буде загальний досвід Telecom Solution Architect, знання best practice і розуміння існуючих систем і процесів конкретного оператора. Це дає можливість без додаткових уточнень, економлячи час, додати в архітектуру саме ті елементи, які не були явно вказані, але є необхідними.

Кар’єрний шлях

Можливі опції росту до позиції Telecom Solution Architect і куди можна рухатись далі показані на діаграмі. Маємо на увазі, що всі ролі стосуються роботи в телеком-сфері і люди мають розуміння телеком-домену.

Авжеж, людина, щоб мати можливість зайняти посаду Telecom Solution Architect має пройти весь кар’єрний шлях у своїй поточній ролі, тобто дорости до позиції Senior або Lead. Наприклад, бути Senior System Analyst або Lead Software Engineer.

Telecom Solution Architect теж має градації за зрілістю: Solution Architect (початковий рівень), Senior Solution Architect, Lead Solution Architect.

В залежності від того з якої сфери людина іде до позиції Telecom Solution Architect, її потрібно більше прокачувати слабкі сторони своїх навичок. Нариклад, якщо людина з сфери бізнес аналізу, то її треба прокачати знання з технічної сфери — програмування, інтеграції, знання щодо мереж (якщо працює з OSS). Якщо людина з ролі Software Engineer, то треба прокачувати навички щодо розуміння телеком бізнесу і софт скіли.

Декілька опції подальшого розвитку з позиції Telecom Solution Architect також показані на діаграмі. Узагальнено, варіанти кар’єрного шляху можуть бути в сторону керівництва людьми (іншими архітекторами), або стратегічного погляду на архітектуру, або в сторону технічного напряму з зануренням в домен, що цікавить. В будь-якому випадку зона відповідальності зростає, складність рішень, які треба приймати, і рівень їх впливу на підприємство оператора зв’язку теж зростає, авжеж, зростає і вартість помилки . Комусь це неприйнятно, а комусь цікаво.

Поради для початківців

Передумова: людина вже працює в сфері телекому:

• почніть дивиться на проєкти ширше, більш ніж ваша зона відповідальності;
• встановіть контакти з поточними архітекторами, попросіть брати участь в архітектурних обговореннях (внутрішніх, не офіційних) в ролі слухача;
• знайомтесь з TMF, MANO та іншою телеком специфічною літературою, в залежності від вашої спеціалізації і інтересів;
• знайомтесь з інтеграційними шаблонами;
• дізнайтесь, як мислять архітектори і виховуйте в собі такий спосіб мислення (розглядати питання з різних view points (точки, з яких дивляться на вимоги, архітектуру), критично думати над бізнес вимогами, думати про вартість рішення, про вартість експлуатації, про вартість ліцензії, про доцільність впровадження саме такого рішення, про продуктивність, про навантаження, про плани зростання навантаження, про плани розширення функціонала, про безпеку, про вплив на наступну ітерацію проєкту і т.п.);
• почніть практикувати використання різних інструментів, які треба для опису архітектури навіть для ваших поточних задач, навіть якщо це не є обов’язковим для вас зараз;
• з часом, запропонуйте допомогу колезі архітектору, наприклад, з малюванням діаграм (тут і розуміння End-to-End прокачаєте, і з діаграмами потренуєтесь), або з написанням інтеграційної специфікації;
• наскільки це можливо, знайомтесь з різними продуктами різних виробників, навіть із пресрелізів;
• з часом, запропонуйте свою кандидатуру для участі в ролі Solution Architect на Demo, PoC проєктах.

Роль Telecom Solution Architect передбачає багато спілкування, багато малювання різних діаграм і багато роботи над описом архітектури рішення — тобто треба буквально текстом описати, як все буде працювати. Тому, якщо ви з цього щось не любите, то працювати в цієї ролі буде деяк складно. Але є приємний момент — чим вище ви будете просуватись по кар’єрній драбині, тим більш високорівневими будуть ваші документи :-)

Дохід

Базуючись на відомих мені кейсах, можу сказати, що дохід Telecom Solution Architect дещо різниться в залежності від компанії, проєкту, навичок, вміння себе продати, але цілком лягає на графік зарплатного віджету на DOU по категорії «System Architect». На Djinni можна подивитись на статистику по категорії «Lead». Треба пам’ятати про останні зміни на IT ринку України і світу, тому рівень зарплат може деяк змінився.

Висновок

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

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

• TMForum (TeleManagement Forum);
• Фреймворкі від TMForum;
• TOGAF (The Open Group Architecture Forum);
• SEI (Software Engineering Institute);
• NFV MANO (Network Functions Virtualisation, Management and Orchestration);
• MEF (Metro Ethernet Forum);
• Сайт Enterprise Integration Patterns;
• Книга Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions.

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

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