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

В компаниях, нацеленных на постоянное развитие, процессы и продукты постоянно эволюционируют. Это осложняет создание и обновление документации. Документация необходима как для понимания текущего состояния продукта, так и для принятия решения о способе развития его функциональности.

Ведение документации в машиночитаемом виде позволяет:

• Вносить информацию один раз
• Проводить автоматический анализ полноты и непротиворечивости
• Увеличивать скорость проектирования технических решений и скорость принятия управленческих решений
• Уменьшать трудозатраты на создание и верификацию документации
• Уменьшать время поиска необходимой документации

В командах выстраиваются процессы по созданию и поддержанию документации в актуальном состоянии с помощью принятых в компании инструментов.

При выборе форматов ведения документов предпочтение отдается форматам, допускающим машинную интерпретацию.

• Формирование проектной и аналитической документации в системах моделирования (например, в Sparx Enterprise Architect/Visual Paradigm)
• Ведение диаграмм в машинночитаемом формате (например, в PlantUML)

• Архитектурно значимые решения фиксируются вместе с программным кодом и позволяют понимать, почему программный код именно так развивается или работает, какие альтернативы были рассмотрены, какие последствия решений были учтены
• критерий архитектурно значимого решения
• формат ADR (шаблоны ADR)

• Стандартизация машиночитаемого формата описания архитектуры
• Формирование единой модели ИТ-ландшафта экосистемы
• Автоматизация проверок на соответствие стандартам и принципам
• Автогенерация диаграмм с учетом требований ТК, ИБ

• Поддержка правил Domain Driven Design при создании структуры программного кода (в части именования переменных/функций/классов/компонент в терминах предметной области)
• Комментирование кода согласно форматам, интерпретируемым системами генерации документации (например, Doxygen)
• Поддержка правил кодирования и применения языка, принятых для применяемых языков:

1. Google Style Guides
2. Правило форматирования (IDE0055)
3. C++ Core Guidelines

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

Использование в решениях встроенного горизонтального масштабирования:

• Позволяет обеспечить непрерывность ведения деятельности, что в свою очередь влияет на лояльность и увеличение CLV
• Снижает риски деградации сервиса вследствие непредвиденного роста нагрузки
• Предоставляет возможность оперативного удовлетворения повышенного спроса пользователей

• Команды должны иметь сформулированные и измеримые требования к производительности (включая прогнозы по росту нагрузки)
• Должны создаваться методики нагрузочного тестирования и проводиться проверки
• Должен осуществляться мониторинг производительности системы
• Должны применяться архитектурные стили, которые позволяют масштабировать все части программной системы

• Применение распределенных архитектурных стилей при разработке систем:

1. Service-Based Architecture
2. Event-Driven Architecture
3. Space-Based Architecture
4. Service-Oriented Architecture
5. Microservices Architecture

• Применение балансировщиков нагрузки и систем класса API Management
• Предпочтение должно отдаваться асинхронному взаимодействию между компонентами системы
• Применение тактик масштабирования данных
• шардирование
• репликация (Write-Only Master – Read-Only Slaves)
• Применение архитектурного паттерна CQRS
• Применение контейнерных технологий совместно с системами автоматического развертывания, масштабирования и управления (таких, как Kubernetes)
• Технологический принцип «Микросервисы»

Реализуемые решения и продукты для всех типовых задач управления, разработки, доставки и эксплуатации используют XaaS-платформы категорий: PaaS, Product Factory, ArchOps, Integration, SRE/Monitoring Data, DataOps/MLOps, Security.

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

Без использования производственных платформ:

• Унификация производственных процессов и инструментов для ряда продуктов будет вести к снижению их производительности
• Требования к соблюдению параметров качества и безопасности потребуют большего количества HW-ресурсов и трудозатрат
• Требования к соблюдению параметров качества и безопасности для ряда продуктов в краткосрочной перспективе могут удлинять T2M
• Контроль выхода в промэксплуатацию потребует более четкого сетевого зонирования
• Переход на производственную платформу потребует переобучения разработчиков

• Переход на единый производственный процесс в системе управления разработкой
• Стандартизированные практики DevOps с внедренными автоматизированными QG
• Внедрение единого процесса управления инцидентами и проблемами
• Встраивание Security-практик в процесс разработки: от построения архитектуры и требований до поставки в пром
• Контейнеризация сборочного конвейера
• Единый механизм развертывания всех изменений в промышленной среде

Решения встраивают поддержку релизов и обновлений без простоев и отказов, с автоматизацией откатов, обратной совместимостью, с применением практик и технологий Autonomous Ops, A/B, Canary Releases и др., не прерывающих клиентские пути и потоки ценности.

Надежные релизы и обновления позволяют клиентам не замечать сбои инфраструктуры и влияют на положительный клиентский опыт.

Удорожание разработки продукта за счет пересмотра архитектуры и встраивание этих возможностей в продукт.

• Обновление приложения осуществляется в фоновом режиме в резервную область и запускается только при следующей авторизации в приложение потребителем
• Пробная установка релиза выполняется в отдельной инфраструктуре на выделенную группу, как правило, лояльных, пользователей
• При проектировании и разработке системы учитывается потребность в автоматическом откате изменений в случае возникновения критических ошибок

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

• Стандартизованные, версионированные, технологически нейтральные API, предоставляющие возможности компонентов ИТ-ландшафта унифицированным образом, составляют основу для эффективного создания цифровых продуктов и объединения их в экосистему
• Проектирование компонента от API приводит к сокрытию деталей реализации и специфики технологий, использующихся в компонентах, уменьшает связность между компонентами, и, как следствие, дает возможность изменения реализации без влияния на потребителя при условии сохранения API
• Возможность простого поиска API в централизованном каталоге с элементами подключения в режиме самообслуживания позволяет уменьшить время на поиск необходимого API и создания продукта
• Гарантированные SLA по доступности и производительности повышают ценность API, позволяют потребителям оценивать его и планировать надежность своей системы в соответствии с описанными в контракте условиями

• Реализация принципа потребует дополнительных трудозатрат по проектированию контрактов API и разработке продукта
• При проектировании продукта необходимо будет обязательно учитывать принцип в части ухода от паттернов интеграции на основе СУБД: то есть реализация дополнительного слоя над СУБД
• Соблюдение принципа приоритизирует подход Design First для проектирования продукта с внешними потребителями API. Подход Code First желательно использовать для разработки сервисов внутри продукта, без внешних потребителей. При использовании подхода Design First должна учитываться корпоративная модель данных и технологический принцип «Владение данными»
• Для эффективного внедрения принципа потребуется обучение разработчиков и/или архитекторов продуктов. Обучение должно быть по:

1. Стандартам описания API
2. Подходам DevOps и DevSecOps
3. Компонентам и библиотекам интеграционной платформы
4. Корпоративной модели данных и ее применимости на продукт
5. Проектированию сервиса с интерфейсами (API), отделимыми от реализации

• Владельцам продукта необходимо будет выделять отдельные ресурсы на поддержание актуальности состояния продукта в SOL и состояния контракта API в Service Registry или Subscription Inventory
• В процесс DevOps должны быть внесены:

1. Шаг с публикацией контрактов в Service Registry или Subscription Inventory
2. Шаг проверки контракта на предмет соответствия единым стандартам API
3. Quality Gate на целостность и обратную совместимость API

• Командам необходимо закладывать дополнительные ресурсы на разработку и поддержания актуальности средств API Mock их продукта
• На ранних этапах внедрения принципа «API первично» владельцам продуктов и командам следует учитывать увеличение T2M и закладывать дополнительные ресурсы при планировании. На более поздних этапах внедрения принципа и при повышении зрелости команд T2M должно нормализоваться

• Единые стандарты описания API:

1. Swagger
2. AsyncAPI
3. GraphQL

• Учет концепции Технологической платформы Integration Platform в части инструментов и тактик
• Использование Service Registry (синхронные взаимодействия) или Subscription Inventory (асинхронные взаимодействия) для публикации контрактов API с целью упрощения поиска и подключения к API в режиме самообслуживания
• Применение средств класса API Mock
• Версионирование достигается за счет использования средств класса API Gateway (в случае синхронных взаимодействий) и подходов к разработке, поддерживающих обратную совместимость API
• Уход от паттернов связи на основе систем управления базами данных
• Использование корпоративной модели данных для описания контрактов API
• Отделение реализации от интерфейса с целью улучшения модифицируемости

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

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

• Данные, как и любой другой актив, инвентаризируются, размещаются в информационных системах и обслуживаются их владельцами
• Продукты должны иметь полномочия и средства для управления данными, за которые они несут ответственность
• Обеспечение качества данных является непосредственной задачей поставщика данных
• Институт администраторов данных берет на себя внедрение практик управления данными

• В продуктах, стримах, кластерах выделяются администраторы данных
• Администраторы ведут учет, описание, контроль качества данных в своей зоне ответственности
• Администраторы являются точкой знаний о данных продукта
• В продукте обеспечивается процесс управления инцидентами качества данных и описания данных
• Продукт управляет развитием сервисов поставки своих данных

Предпочтительна собственная разработка, нежели закупка технологий, использование Open Source или Inner Source. Ключевые технологии, которые обеспечивают основные конкурентные преимущества, являются собственными.

Open Source Software – программное обеспечение с открытым исходным кодом. Любой желающий может скачать этот исходный код для ознакомления, модификации или использования фрагментов кода в ином продукте, также любой желающий может распространять неизменное либо измененное приложение и/или его исходный код. Применение именно Open Source-решений позволяет снижать зависимость от внешних компаний и уменьшать риски, связанные с иностранными санкционными политиками.

Inner Source Software (a.k.a Internal Open Source) – приложение, разрабатываемое согласно принципам Open Source, но исходные коды не публикуются вне компании-разработчика.

• Переход к практикам Inner Source и Open Source повышает эффективность собственной разработки
• Улучшается распространение знаний между командами
• Команды устраняют узкие места и снимают ресурсные ограничения
• В командах появляются сотрудники с более глубоким знанием кодовой базы
• Способствует общему повышению качества кода и распространению практик более качественной разработки приложений в компании
• Способствует более интенсивному обучению и развитию разработчиков

• Код продукта хранится в репозитории, поддерживающем общий доступ к коду
• Продуктовая команда (владелец продукта) уделяет повышенное внимание документации по продукту, все обсуждения и решения документируются
• Для общения команды используются технические средства, позволяющие хранить дискуссии и осуществлять по ним поиск (владелец продукта, внешняя команда)
• Изменения от внешних команд поступают в виде Pull Request
• Требования к коду формализованы, весь код проходит процедуру Code Review выделенными специалистами (Trusted Committer) перед тем, как попасть в репозиторий
• Сам код системы становится продуктом. Изменяется стиль мышления разработчиков
• В процессе производства и адаптации программного обеспечения производится анализ внутренних разработок компании и рынка на предмет наличия готовых решений
• Команды проводят мероприятия по популяризации разрабатываемых технологий и сбор обратной связи

• При выборе новых технологий предпочтение отдается технологиям, поставляемых по модели Open Source
• Формируются внутренние команды по поддержке и развитию используемых Open Source-решений
• Внутренние разработчики могут публиковать свой код в Open Source (при условии, что это не противоречит лицензионным требованиям и требованиям безопасности)

Для облегчения переиспользования внутренних решений и/или технологий применяются:

• Единая «продуктовая фабрика» помогает облегчить доступ к коду Inner Source продуктов, упростить внесение изменений в продукты по модели Inner Source
• Единые стандарты кодирования помогают уменьшить порог вхождения других команд в код и упростить Code Review:

1. С# – стандарт Code Style
2. GoLang – стандарт Go, рекомендации по Code Review
3. Java – стандарт Code Style
4. Python – разработка кода, разработка тестов, работа с зависимостями
5. C++ – используется стандарт Google, рекомендуется учитывать гайдланы

• Автоматизация сборки и поставки Inner Source-продукта позволяет любой команде автоматически собрать продукт и начать его использовать
• чек-лист Inner Source позволяет оценить и повысить готовность команд к совместной разработке
• методологическая поддержка позволяет командам организовать эффективное взаимодействие

• Используются статические анализаторы кода для проверки лицензионной чистоты и контроля уязвимости продуктов Open Source (BlackDuck, Whitesource)
• технический радар компании используется для выбора предпочтительных технологий
• стандартный процесс вывода в Open Source позволяет проверить проект на соответствие требованиям и получить поддержку при публикации и продвижении

Решения встраивают отказоустойчивость в свою реализацию, обеспечивают надежность функционирования и непрерывность клиентских путей, потоков ценности в условиях отказов инфраструктуры и исполняющей среды, исключают единые точки отказа, реализуя принципы и применяя технологии (Autonomous Ops, SRE, Chaos Engineering, High Availability/Disaster Recovery, Cloud Native и т.п.).

Обеспечение экономически обоснованного уровня надежности бизнес-сервисов за счет внедрения единых подходов и лучших практик обеспечения надежности.

Эффективная эксплуатация принципа потребует ресурсов продуктовых команд на обеспечение непрерывности работы продуктов, а также качества их работы.

• Применение практик SRE (SLO, Chaos Engineering, Postmortem, Error Budget)
• методики обеспечения надежности продуктов МТС
• PostMortem
• Observability Platform
• платформа Мониторинга и Наблюдаемости
• Mission Control Center (MCC)
• Incident& Problem Management
• управление инцидентами на сети и в ИТ-инфраструктуре
• управление проблемами
• Capacity Management
• Autonomous Ops
• High Availability/Disaster Recovery
• требования к системе обеспечения надежности продуктов и сервисов МТС
• методика разработки и условия применения плана аварийного восстановления (DPR)

Решения представляют собой наборы слабосвязанных, автономных, повторно используемых компонент-сервисов, размещаемые на производственных платформах и реализующие принципы и технологии: DDD/Bounded Contexts, Cloud Native, UI/Service/Data Mesh, Microservices и другие.

• Уменьшение T2M
• Эффективное масштабирование решения
• Повышение надежности и отказоустойчивости решения
• Увеличение автономии команд разработки
• Масштабирование разработки (увеличение количества команд и/или разработчиков)
• Возможность использования разных технологий для реализации микросервисов

Эффективное внедрение микросервисов потребует не только технических, но организационных изменений: переход от функциональных команд к продуктовым (см. также принцип «Партицируемость»), использование подходов DevOps и DevSecOps.

Для эффективной эксплуатации микросервисных решений необходимо наличие инфраструктурных платформ оркестрации, сервисов хранения данных, балансировки и очередей (см. также принцип «Производственные платформы»).

• Сервисы декомпозированы исходя из Business Capabilities
• Каждый сервис запускается в собственном окружении (компьютер/виртуальная машина/контейнер)
• Окружение содержит все необходимое для запуска сервиса и соответствует принципам повторяемости сборки
• Каждый сервис имеет выделенную базу данных (слой данных)
• Каждый сервис имеет версионируемый слой API, описанный через схему или контракт (OpenAPI, Swagger, etc.)
• Сервис может быть протестирован независимо
• Технология, выбранная для реализации сервиса, соответствует его функциональному предназначению
• Межсервисное взаимодействие происходит только через вызовы API
• Сложные вызовы цепочки сервисов соответствуют принципам оркестрации или хореографии
• Сервис должен обеспечивать полную функциональность в рамках своей декомпозированной бизнес-функциональности (High Cohesion)

Применение и реализация AI/ML в решениях централизовано управляется для применения лучших практик, результатов других решений и оптимизации обмена данными.

В среде распространяемых, доступных и достоверных данных технологии AI/ML представляют собой мощный инструмент создания добавленной стоимости потоков ценности компании и позволяют в значительной степени повысить скорость и эффективность решения сложных бизнес-задач. Высвобождение ценных человеческих ресурсов за счет применения AI/ML влечет за собой расширение научно-исследовательского и аналитического потенциала компании. Накопление совокупного опыта AI/ML позволяет использовать его для генерации и решения качественно новых видов бизнес-задач.

• Продукты и системы должны выделять время и ресурсы на оценку применимости AI/ML подходов на регулярной основе
• Все разрабатываемые подходы, модели и метрики в продукте должны быть доступны для переиспользования и аналитики в других продуктах
• Данные должны быть корректно размечены и категорированы с точки зрения норм ИБ и применимости к задачам AI/ML
• Для эффективной реализации потребуется качественно другой уровень данных, в том числе должны выполняться принципы «Владение данными», «Онлайн» и «Датацентричность»

• Рассмотрение возможности использования AI/ML в каждом проекте
• Использование единого репозитория AI/ML
• Обогащение репозитория AI/ML