When we get chosen by the gods, they're choosing us for death.
Situation
Для одного из ведущих операторов мобильной связи СНГ система контрактного биллинга для услуг фиксированной телефонии, домашнего интернета и ТВ, а также услуг мобильной связи была построена на основе системы биллинга БИС (BIS). Важно учитывать, что система исторически внедрялась и мигрировала для различных сервисов в единую систему биллинга на протяжении многих лет не только силами самого поставщика, но и внутренними командами разработчиков, тем самым обрастая множеством интеграций с другими системами оператора, как разработанных самостоятельно, так и различных вендоров, например такими как платежные шлюзы, хранилище DWH, системы HelpDesk, CRM и WorkForce, системы медиации, провижининга и нотификаций, ERP система и финансовые блоки (налоговый учет, расчет штрафных санкций и списание задолженности).
Target
Согласно планам компании, система BIS подлежала оперативной замене в течении 6 месяцев с целью обеспечить новое биллинговое ядро для быстро меняющихся потребностей бизнеса, при этом общий объем базы миграции насчитывал около 5 миллионов активных абонентов в условиях периодического изменения тарифов (репрайса) на ежеквартальной основе. Одним из важных требований к проекту являлась длительность запуска маркетинговых активностей, которая не должно было превышать 1 недели для простых активностей и 3-х недель – для сложных запусков. Еще одним из обязательных требований проекта являлось полная совместимость после миграции legacy-систем, уже интегрированных с системой биллинга BIS, с целью минимизации доработки старых систем, так как некоторые из них либо нельзя было доработать, либо на их доработку не было времени.
Action
Так как BSS-система оператора связи является SOX-критичной системой (т.е. подлежащей аудит на основе SOX контролей), перед руководством проекта стояла задача создать программное решение не только под этот конкретный проект, но и способное успешно решать будущие задачи компании на пути цифровой трансформации. Рабочий процесс в компании был построен на основе стандартного SDLC процесса, и я хотел бы рассказать о особенностях практической реализации этого процесса в нашем проекте, который предполагал участие нескольких команд разработчиков и применение Agile подхода вместо Waterfall.
Итак, для формирования плана и учитывая нереально сжатые сроки реализации проекта, руководством проекта было приняты следующие решения для его успешной реализации:
привлечь три различных команды для реализации проекта – команду бизнес-аналитиков, внутреннюю команду разработчиков и внешнюю команду разработчиков
организовать cбор и анализ требований по принципу «Reverse Engineering». Сам подход не предполагает ничего инновационного, кроме сроков реализации данного этапа, что для успешной реализации проекта было критически необходимо – на практике была использована общедоступная рекламная документация продукта, сделаны детальные срезы точек интеграции и опросы фактических пользователей системы BIS и интегрированных с ней систем. Важно понимать, что данный подход потребовал от команды NATEC R&D не только уверенных навыков проектирования систем BSS, но и понимания общей архитектуры и принципов работы системы BIS компании Петер-Сервис.
выполнить планирование по методу «Критического пути» - способ, основанный на выделении критических задач с нулевым резервом времени выполнения. Сам по себе метод хорошо подходит для управления проектом, но не менее важно и само наполнение списка критических задач, сформированного по принципу «Лучшее враг хорошего» или иными словами - несмотря на все усилия, «лучшего» можно и не достичь, а потерять при этом уже достигнутое «хорошее» – вполне реально (по словам автора данного афоризма, звучащего на французском как «Le mieux est I'enneini du bien»). Следует понимать, что в компании уже несколько лет шли различные проекты по трансформации бизнеса, поэтому фактический объём сервисов и конечные требования для взаимодействия с BSS-системой во многом были еще неизвестны. Как следствие, было принято решение ориентироваться на быстро адаптирующее ядро системы BSS (на уровне медиации, абонентского учета, тарифных конфигураций, конфигурации финансового учета и провижининга сервисов). Данное решение должно было обеспечить быстрый рост и успех при запуске изменений существующих или новых сервисов, а стандартизированный подход к планированию запуска активностей на основе domain-driven design - упростить проектирование и дизайн услуг. Фактически, большая часть времени фазы планирования ушла на ретроспективу запуска активностей и анализ требований roadmap-проектов с целью выделения общих черт и закономерностей - как процесса, так и дизайна. Кроме того, отдельно руководством проекта были выделены процессы, которые планировать и контролировать в рамках этого проекта было невозможно, а результат нашего проекта от них зависел непосредственно – для нас таким артефактом стал затянувшийся процесс параллельного внедрения системы препейд биллинга от другой компании, взаимодействие с которой либо предполагалось, либо часть функционала которой требовалось реализовать. По итогу запуска можно с уверенностью сказать, что проект стал успешным только благодаря тому, что руководство проекта посмотрело на шаг вперед и подумало о будущей роли проектных изменений как основополагающей для его реализации.
Проектирование и дизайн организовать на основе Референсной модели с учетом существующей конвергентной инфраструктуры предприятия. Я не буду останавливаться на описании конвергентной инфраструктуры в нашем проекте, так как она не есть предметом статьи, но хотел бы рассказать о Референсной архитектуре, которая дает возможность повысить эффективность моделирования – об этом подробнее ниже в статье.
Разработку ПО выполнить на основе Agile подхода – здесь для нас критически важным было обеспечить независимость внутренних рабочих процессов каждой отдельной команды, чтобы минимизировать задержки при поставках на различные среды.
Организовать процесс Тестирования с применением автоматизации (Automated Testing) – для чего были использованы скрипты для интеграционных тестов и BDD фреймворк SpecFlow для UI automation за счет его ориентированности на behaviour.
Построить процессы Развертывания продукта на основе DevOps практик, адаптированных под требования существующего ITIL процесса. Среди основных задач перед командой проекта стояли Автоматизация развертывания, мониторинг производительности (Application Performance Monitoring) и управление конфигурацией (Configuration Management) – решения всех этих задач мы постарались заложить непосредственно в Референсную архитектуру, для чего пришлось построить платформу хостинга IoC-контейнеров, выделяя отдельно задачи версионирования и конфигурации в соответствии с утвержденными у Заказчика процессами управление изменениями и релизами в системе HPSM.
Референсная архитектура
Само понятие Референсной архитектуры определено стандартом ISO 15704 "Enterprise modelling and architecture", который указывает, что архитектура предприятия, основанная на моделях, должна поддерживать идею «многократно применимых референсных моделей» (reusable reference models). Также указывается, что референсные модели требуют адаптации к конкретному предприятию, и при необходимости могут быть применены специфические (particular) модели, которые описывают отдельную сущность конкретного предприятия или его части.
Важно понимать, что общеупотребимый термин «Архитектура ИТ-систем» это важная, но только лишь часть понятия «Архитектура предприятия», которая является набором взаимосвязанных архитектур, отражающих структуру и процессы предприятия. Иными словами, архитектура предприятия должна:
позволять моделировать жизненный цикл проекта от первоначальной концепции до функционального дизайна или спецификации, детального проектирования, реализации, внедрения, эксплуатации и заканчивая выводом из эксплуатации;
охватывать людей, процессы и инфраструктуру, задействованные в выполнении, управлении и контроле бизнеса предприятия
Таким образом, с прикладной точки зрения и в контексте данной статьи, архитектуры можно поделить на архитектуры систем и архитектуры предприятий. Я специально не стал приводить стройное определение архитектуры и ее классификации, чтобы не вызывать излишней дискуссии из-за различий с устаревшей версией стандарта IEEE/ISO/IEC 42010-2011 "Systems and software engineering -- Architecture description".
Возвращаясь к фазе Проектирования и Дизайна, так как ИТ-стратегия компании была в том числе ориентирована на рекомендации TM Forum, то требовалось создать открытую Референсную архитектуру (Reference Architecture), ориентированную на модель предметной области биллинговой системы BIS, но адаптированную под текущие нужды компании и обеспечивающую эффективную цифровую трансформацию продуктов и услуг в будущем. С практической точки зрения Референсная архитектура основана на совокупности шаблонов решений и подходов, что делает её многократно-применимой для запуска новых услуг и сервисов в масштабах Enterprise-предприятия – иными словами «из коробки». Со стороны руководства проекта оставалось только выбрать шаблоны подходов и решений - с одной стороны, для внедрения и развития нового биллингового ядра BSS, а со второй стороны – для простой интеграции с огромным количеством Legacy-систем, устаревших процессов, и где-то -инфраструктур. Важно отметить, что выбор подходов и шаблонов решений был делегирован команде реализации проекта, что в конечном счете показало высокую эффективность Agile-методологии управления проектом, без которой реализация проекта была бы невозможна в поставленные сроки. Фактическое наполнение Референсной архитектуры не могло не учитывать локальную специфику предприятия, поэтому она больше содержала в себе ИТ-составляющих, но команда проекта постаралась учесть требования и пожелания всех участников бизнес-процессов компании Заказчика, в том числе департаментов запуска маркетинговых активностей, управления проектами, финансовой дирекции и департамента эксплуатации – тем самым создав Референсную архитектуру MEF.DEV, объединяющую бизнес-процессы, информационные потоки, а также поддерживающую их организационно-штатную структуру, вместе с системной архитектурой (архитектурой приложений, архитектурой данных, сетевой архитектуры и архитектуры платформ).
С практической точки зрения работа по Референсной архитектуре MEF.DEV включает 4 обязательных этапа:
Сначала требуется провести декомпозицию на основе DDD-подхода с целью выделения и стандартизации услуг или продуктов конкретной предметной области (домена).
На основе сделанной декомпозиции следуют разработать модели сущностей (Entities) и действий (Action) над ними. К ним относятся общие типы и поведение в отношении всех услуг/продуктов для дальнейшего описания. Для каждой услуги/продукта создаются конкретные ресурсы, взаимодействие и модели. Некоторые из этих моделей относятся к нескольким сущностям (например, есть значительное пересечение для моделей Клиентов и их Ассоциаций). В результате данного этапа требуется сформировать Единую информационную модель SID (Shared Information and Data Model) для домена, в нашем случае доменом были телеком услуги оператора. Сама идея модели не является новшеством, для телеком-провайдеров она даже является обязательной частью концепции NGOSS (рекомендации ITUT M.3050 организации TM Forum) и служит основой для интеграции систем класса OSS/BSS.
Далее начинается привычный этап формирования Бизнес-требований (BR) и вариантов использования (UseCases), специфичных для отельного сервиса/продукта и определения функциональных требований, вариантов использования, маппинг на бизнес-процессы и т.д., относящиеся к конкретным сущностям (например, действие Активации для услуг FTTB или подключения PSTN-сервиса).
После этого начинается итеративный процесс разработки, результатом которого являются IoC-контейнеры (Nuget-пакет с инверсией управления) – это необходимо для того, чтобы сопоставить модели сущностей и действий с нативными схемами данных, доступными к использованию через внедрение зависимостей (Dependency Injection), автоматически сгенерировать реализацию REST-интерфейсов и документацию для разработчиков.
Стоит еще упомянуть важную роль SID-модели – она улучшает процесс бизнес-анализа и дает возможность повысить эффективность взаимодействия с разработчиками в SDLC процессе, так как позволяет идентифицировать и стандартизировать процессы в отношении продуктов и услуг (Actions - атомарная часть потока процессов) – на картинке ниже приведена часть модели BSS.Entities для домена Telecom в нашем проекте:
Непосредственно сам процесс разработки согласно Референсной архитектуры MEF.DEV состоял из следующих этапов:
Создать новое пакетное решение или автоматически сгенерировать на основе концепции Database-First или Model-First подхода.
Запустить пакетное решение в локальной среде для проведения первоначального теста.
Зарегистрировать первую версию пакета в песочнице на платформе mef.dev.
Создать конфигурацию для пакета на платформе mef.dev.
Опубликовать версию пакета в песочнице на платформе mef.dev (каждый раз, когда публикуется новая версия пакета, платформа автоматически собирает пакет и развертывает для его использования «на лету»). Этот процесс также генерирует фактическую спецификацию конкретной версии пакета. (CI/CD опционально)
Для задач интеграционного тестирования пакет публикуется в E2E среде (CI/CD опционально), с отдельной конфигурацией. Этот процесс также генерирует фактическую спецификацию.
С целью выхода на продуктив ITOps публикует пакет в производственной среде (CI/CD опционально).
В процессе эксплуатации ITOps осуществляет управление версиями и конфигурацией пакетов, опубликованных ранее, с учетом информации о производительности той или иной версии.
Далее стоит упомянуть, что Автоматизация развертывания достигалась за счет написания слабосвязанного кода приложений на основе IoC-контейнеров – тем самым Nuget-пакеты разных команд разработчиков собирались «на лету» и независимо друг от друга (естественно при соблюдении обратной совместимости), предоставляя возможность переключения версий, в том числе для отката на предыдущую версию приложения.
Решение задачи Application Performance Monitoring было основано на применении протоколирования на уровне платформы хостинга IoC-контейнеров, что позволило отслеживать изменения производительности отдельных версий.
Процесс управления конфигурацией Заказчика фактически потребовал при решении задачи Configuration Management добавить поддержку ролей и различные типы конфигураций для хостинга IoC-контейнеров, а именно конфигурации разработчика, администратора и пользователя – тем самым исключив из поставок environment- или right-зависимых конфигураций.
Переходя к вопросу масштабирования и реализации самой платформы, то нами было принято решение поддержать горизонтальное масштабирование за счет Stateless-реализации каждой ноды и применения Distributed Cache на основе кластера MS SQL Always ON
Results
Реализация проекта согласно текущего плана заняла 8 месяцев, в которые пришлось добавить 2 месяца на согласование организационных моментов, в процессе реализации проекта ряд существенных требований были ожидаемо пересмотрены и успешно внедрены, в частности онлайн интеграция с высоконагруженными интерфейсами платежного шлюза и огромное кол-во UI изменений по обратной связи пользователей, при этом данные изменения не повлияли на сроки запуска проекта, в первую очередь за счет готовности проекта к изменениям. Целевая архитектура системы представлена на рисунке ниже:
