Путь разработчика долог и порой тернист. Но когда ты идёшь от junior к middle, всё понятно — есть задачи, старшие наставники, миллионы курсов. Движение от middle к senior уже сложнее. Теперь не ты обращаешься к коллегам за советами, а всё чаще они приходят к тебе. Но вот ты senior. Дальше можно менять предметную область или язык.

Но я предложу ещё несколько вариантов. Если есть желание (и умение) организовывать работу других, это прямая дорога к управлению командами. А если нет? И вот на этой развилке возникает вариант для тех, кто хочет максимально закопаться в свою сферу. Это путь архитектора: системы, решений, кластера и так далее.

В этой статье я расскажу про суть работы архитектора решений. Перейдём к знакомству?

Привет, Хабр. Меня зовут Владимир Воловиков, я архитектор решений в компании МТС в кластере «Телеком» в группе solution-архитектуры. Всего я работаю в IT более 25 лет.

Я и руководил отделами разработки ПО, и был системным архитектором (об этом опыте я писал ранее).

Начнём с терминологии

Архитектор решений проектирует, что логично, IT-решения — совокупность технических средств (программных и аппаратных), необходимых для удовлетворения определенных бизнес-потребностей.

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

Теперь на примере я расскажу о сути работы такого архитектора.

Сразу скажу, что названия услуг, указанные в этой статье, весьма условны. Как и деление на системы и слои. В реальном МТС решение получается несколько сложнее. Эта статья — не техническая документация. Я просто хочу показать, какие процессы могут происходить при проектировании разных технических решений.

Описание бизнес-потребностей

Давайте мысленно перенесёмся в Калугу и заглянем на улицу Ленина в произвольную квартиру дома № 1. У нашего абонента проводной интернет и мобильная связь от МТС.

Теперь мы можем предложить ему подключиться к цифровому телевидению. Но абонент не спешит этого делать. И даже реклама не помогает. Почему? Каждая из услуг по отдельности не может соперничать с аналогичными предложениями конкурентов. К тому же они подключаются разными договорами, у них отдельные счета и даты списания денег — неудобно.

Возникает прекрасная идея — предложить абоненту набор услуг: все три услуги сложить в одну корзинку, оформить один счёт и продать разом. А чтобы абонент точно-точно захотел купить, надо его заинтересовать. Что насчёт скидки? Например, первый месяц бесплатно, а потом — со скидкой в 20%. Очень даже конкурентно!

Теперь бизнес-заказчик оформляет эту прекрасную идею на бумаге. Итак, нам необходимо:

• дать абоненту возможность сформировать под себя пакет услуг, состоящий из:
  ○ мобильной связи
  ○ широкополосного интернета
  ○ кабельного телевидения

• сделать так, чтобы деньги за все услуги, входящие в пакет, списывались единовременно

• оформить 100% скидки на первый месяц пользования пакетом

• оформить 20% скидки на услуги во второй и последующие месяцы

Всё придумали и описали. Далее в игру вступает бизнес-аналитик. Его задачи таковы:

• максимально точно описать все бизнес-требования (правила)

• выявить и зафиксировать все функциональные требования

• грамотно и точно описать все варианты использования

Предположим, что всё написанное устраивает бизнес-заказчика. Настал этап работы архитектора решений. Заглянем вместе с этим человеком «под капот» МТС и скажем, реально ли сделать то, что хочет бизнес.

Что мы имеем: архитектура и информационные системы

В разделе описывается ситуация AS IS.

Пусть у нас будут операторская и абонентская витрины, то есть вход для администраторов и, соответственно, для клиентов. А также по минимальному набору информационных систем для всех услуг:

• CRM для работы с информацией: добавить, удалить, назначить цену и т. д.

• расчёт стоимости и выставление счетов абоненту

• работа с абонентами: добавить, удалить, изменить абонента. Добавить, удалить счёт, связать счёт с абонентом, сменить тарифный план, отключить или подключить услугу

• авторизация

• интеграция

Через интеграционный модуль отправляются запросы из витрины в другие части решения. У интеграционного модуля единый вход и правила маршрутизации (или карта). Например, приходит запрос «Получить список тарифных планов» — модуль отправляет его в нужную систему. Карту маршрутизации загружают в модуль с конфигурационными файлами или, например, через специальный пользовательский интерфейс.

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

Всё из-за того, что информационные модули мобильной связи, интернета и телевидения развивались отдельно и независимо друг от друга. И у них разные модели хранения данных и бизнес-процессы.

Как их объединить? Нужно решение. Так начинается следующий этап работы архитектора.

Моделирование интерфейса

Для начала поймём, какие функции должны быть у системы. Для этого архитектор описывает логику взаимодействия пользователя и системы, а также систем между собой.

Итак, абстрактно представим себе будущий пользовательский интерфейс и попробуем смоделировать процессы. Внутри компании в целом и отдельных команд есть свои стандарты. Я предпочитаю использовать диаграмму переходов, так как считаю её удобной.

Читается диаграмма переходов так: простыми прямоугольниками обозначаются конкретные страницы, стрелочками и текстом на них — действия, которые вызвал пользователь, нажав на кнопки или ссылки на этих страницах. Прямоугольники с боковыми полями — ответные действия системы.

Что в итоге у нас получилось? А вот такие возможные действия пользователя:

1. Получить список продуктов абонента.

2. Получить список продуктов, доступных для включения в пакет.

3. Добавить в пакет продукт.

4. Удалить из пакета продукт.

5. Рассчитать стоимость пакета.

6. Запустить процесс создания пакета.

Для реализации UI в витрине потребуется новый API.

Отлично! С функциональностью определились, методы описали. Теперь нужно понять, а как эти методы вообще реализуются.

Представим следующий сценарий. У клиента есть мобильный телефон с SIM-картой от МТС. Он зашёл в пользовательский кабинет. Интерфейс запросил у системы список продуктов абонента и получил ответ, что подключена мобильная связь. Клиент решил добавить ещё один продукт. Выбрал из списка доступных для включения в пакет «Широкополосный интернет» (ШПД) и подключил.

Прошло какое-то время, и абонент снова заходит в свой кабинет. Интерфейс заново запрашивает список продуктов. Что должно вернуться? Правильно! «Мобильная связь» и ШПД.

А теперь ещё раз посмотрим на составляющие нашего решения (см. рис. 1). С помощью чего мы соберём «Список продуктов абонента»? Кто получит списки от «Модуля настройки мобильной связи» и «Модуля настройки фиксированной связи» и приведёт всё это к какому-то общему знаменателю?

Сейчас такой системы нет, а значит, нам нужна система-оркестратор. Давайте добавим её на схему.

Что делает система-оркестратор?

Оркестратор должен рассчитать итоговую стоимость пакета и учесть все скидки. Что ему для этого нужно сделать?

1. Получить список продуктов «Мобильной связи» абонента и рассчитать их стоимость.

2. Получить список продуктов «Фиксированной связи» абонента и рассчитать их стоимость.

3. Суммировать стоимость продуктов.

4. Вычислить скидку от итоговой стоимости.

И вот так архитектор расписывает и отрисовывает все процессы. Для каждого он указывает целевые системы, входные параметры и структуры передаваемых данных.

А теперь вернёмся на минуту к схеме № 4 (см. рис. 4) и посмотрим на созданный список интерфейсов и функций. Кажется, чего-то всё ещё не хватает. Бинго! Пакет-то мы и не создали.

«Пакет нужен? — Я со своим». Процесс создания пакета

Сперва нам нужно понять, что может входить в состав пакета. Он может быть как с мобильной связью, так и без неё. Может включать все услуги разом, как на схеме ниже. Знаем ли мы заранее, как он будет выглядеть у разных людей? Нет.

А значит, оркестратор не может работать всегда по одному и тому же алгоритму. Ему нужна спецификация подключения или исполнения продуктов.

Оркестратор получил на входе список продуктов абонента и прочитал в их составе название спецификации подключения. После этого он должен где-то взять описание шагов.

То есть оркестратор должен узнать:

• в какие системы делать запросы (и какие именно запросы)

• что передавать в запросах к разным системам

• как действовать в зависимости от ответов

Чтобы было понятнее, объясню на примере.

В пакете абонента есть «Мобильная связь» и «Фиксированная связь» (это домашний интернет). А значит, нужно, условно говоря:

• сделать запрос в систему А

• сделать запрос в систему Б

• сделать запрос в систему С
  ○ если ответ от C был успешным, то
  ▪ сделать запрос в Д
  ○ если нет, то нужно
  ▪ сделать запрос в Е

Если в пакете ещё и «Телевидение», то нужно добавить также

• сделать запрос в системы С1 и С2

Конечно, эти настройки могут меняться. Бизнес не стоит на месте, у него появляются новые продукты, обновляются условия, запросы, целевые системы.

А значит, нам нужен отдельный модуль, в который оператор может вносить спецификации, создавать цепочки запросов. Назовём эту систему «Модуль хранения и исполнения заказа» и добавим на схему.

Нам нужно больше витрин!

На этом этапе появляются ещё и две новые витрины:

1. Для инженеров техподдержки, которые будут следить за процессом подключения продуктов и при необходимости вмешиваться.

2. Для настройки спецификаций подключения/исполнения продуктов. Эта витрина нужна инженерам, которые будут вносить все данные, необходимые для подключения продуктов.

Чтобы настроить эти спецификации, их нужно описать. И это тоже делает архитектор. Например, как на рисунке ниже (рис. 9).

Для этого архитектор рисует общий алгоритм исполнения шагов для каждого продукта в отдельности. Потом он детализирует каждый квадратик, расписывая порядок вызовов в виде диаграммы последовательностей (см. рис. 5).

А достаточно ли данных?

Представим, что в этой точке архитектор решений завершил свою работу.

Всё описано и готово. Кажется, пришло время ставить задачи? Команде А нужно сделать: первое, второе, третье. Реализовать методы А, Б, С и т. д.

А достаточно ли того материала, что подготовил архитектор? Внезапно — нет.

Любой системный архитектор задаст вопросы про нефункциональные требования (НФТ): как часто будет вызываться его система, какого количества запросов в секунду ожидать, сколько времени может его система не работать в год?

Без этой информации не получится спроектировать систему необходимой надёжности. Кроме того, невозможно выбрать оптимальную систему хранения данных, рассчитать количество необходимых ресурсов: CPU, HDD, Memory и прочих.

Если мы неверно оценим стоимость работ, то получим систему, не подходящую под наш запрос.

Поэтому архитектор решений задаёт уточняющие вопросы бизнесу. В целом, зная текущий объём клиентской базы, планы бизнеса на тиражирование решения, прогнозы продаж, можно сделать расчёты по значениям НФТ.

Предположим, что архитектор получил от бизнеса такой ответ: «В следующем году мы планируем делать по 125 000 продаж в месяц».

Маловато данных? Отнюдь. Мы можем узнать, сколько раз в месяц (а значит, в день, час и т. д.) будет вызываться система с запросом «Запустить процесс создания заказа».

Итак, в среднем в месяце 22 рабочих дня. Делим 125 000 (планируемые продажи) на 22, так мы получим количество вызовов в день. Обычный рабочий день — это 8-9 часов: делим количество вызовов в день на 8. Получили количество запросов в один час. Делим ещё разок — на 60 (минуты) и для верности ещё раз на 60 (секунды). Вуаля — количество запросов в секунду узнали.

• 1/22 рабочих дней — 5 681,818 продаж и вызовов системы с запросом «Запустить процесс создания заказа» за один рабочий день

• 1/9 часов — 631,313 за один час

• в минуту — 10,522

• в секунду — 0,175 продаж

Теперь мы знаем, сколько раз будет вызываться система с запросом «Запустить процесс создания заказа».

Запросы «Получить список продуктов абонента» и «Получить список доступных продуктов абонента» будут вызываться чаще, чем процесс создания заказа, добавления продукта в пакет или его удаления. Допустим, что на 50% чаще.

Для простоты счёта округлим полученную цифру 0,175 до 2-х запросов в секунду (RPS). И считаем по формуле 2 RPS × 1,50 (на 50% чаще). Так мы получаем следующие цифры:

• «Получить список продуктов абонента» — 3 RPS

• «Получить список продуктов, доступных для включения в пакет» — 3 RPS

А для услуг ниже цифры остаются те же, так как эти услуги вызываются с частотой 2 RPS:

• «Добавить продукт в пакет» — 2 RPS

• «Удалить продукт из пакета» — 2 RPS

• «Запустить процесс продажи» — 2 RPS

Но мы не учли ещё нагрузку от операторских витрин. Также предположим, что каждый заказ будет проходить через службу поддержки. А значит, будут вызваны те же методы в том же объёме. Поэтому предыдущие результаты умножаем на 2. Получаем:

• «Получить список продуктов абонента» — 6 RPS

• «Получить список продуктов, доступных для включения в пакет» — 6 RPS

• «Добавить продукт в пакет» — 4 RPS

• «Удалить продукт из пакета» — 4 RPS

• «Запустить процесс продажи» — 4 RPS

Ну а теперь достаточно информации?

Мы определили рубежные требования, но нужно посчитать и нагрузку, которую получат от нашего решения мастер-системы: модули «Мобильной связи», «Фиксированной связи» и «Цифрового телевидения».

Когда мы понимаем, как работает интеграция, сколько раз и какие системы в описанных выше процессах мы вызываем, посчитать это просто: процесс А состоит из двух вызовов системы Б и одного вызова системы С. Следовательно, если нас вызывали 5 раз в секунду, то мы вызовем систему Б 10 раз в секунду и систему С 1 раз в секунду.

Теперь о доступности решения. Она определяется по минимальной доступности элемента решения. Что это значит? Если в цепочке систем есть система с низким уровнем доступности, например 70-80%, то выше этого уровня доступность не поднять. В таком случае выставлять высокие требования попросту бессмысленно. Доступность систем — это вопрос денег, системы с уровнем 99,99% очень дорогие. Всё это, как правило, регламентируется корпоративной архитектурой и стандартами предприятия.

Все эти взаимодействия между разными системами должны быть надежными и соответствовать требованиям безопасности. Также важно, чтобы можно было легко переиспользовать эти интеграции и при построении других продуктов. Поэтому здорово, когда можно не писать эти интеграции с нуля, а использовать нашу внутреннюю интеграционную систему. Внутри неё разные продуктовые команды могут публиковать свои API, и задача разработчика — подписаться на эти API и переиспользовать их при построении новой системы.

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

Заключение

Как я и говорил в самом начале, названия услуг, указанные в этой статье, весьма условны. Так же, как и деление на системы и слои. В реальном МТС всё несколько сложнее.

Но такой тариф — с продуктами всех перечисленных категорий и возможностью группировки в пакет — в МТС действительно существует и называется «Тариф № 5». И я принимал участие в разработке этого решения более полутора лет, получив огромный опыт и колоссальное удовольствие от работы.

За помощь в подготовке материала хочу поблагодарить своих коллег Дмитрия Римова и Елену Пашинину, ведущего архитектора и ведущего аналитика проекта МТС-СЕТ (Тариф № 5).

Под спойлером немного ответов на самые часто встречающиеся вопросы.