требования
к архитектуре
Приведенные архитектурные требования направлены на решение задач цифровой трансформации
АРХИТЕКТУРНЫЕ ПРИНЦИПЫ
01. АРХИТЕКТУРНЫЕ ПРИНЦИПЫ
Фундаментальные правила, которые используются для принятия архитектурных решений и раскрывают способ их реализации на практике.
ЦЕННОСТЬ
  • Принятие правильных архитектурных решений
  • Снижение общей стоимости решений
  • Соответствие заданным эксплуатационным характеристикам
двухскоростная архитектура
02. двухскоростная архитектура
Единое, адаптивное цифровое пространство для каждого сотрудника, ориентированное на работу с процессами организации и обеспечение эффективного и качественного их исполнения.
ЦЕННОСТЬ
  • Создать единое рабочее место для каждого сотрудника
  • Организовать работу с процессами, а не с отдельными функциями
  • Ускорить цифровую трансформацию за счет развития процессов
  • Обеспечить управляемость организации за счет контроля сроков и качества исполнения процессов
  • Сохранить инвестиции в существующие приложения
  • Реализовать постепенный переход на приложения, соответствующие архитектурным требованиям
КОМПОНУЕМАЯ АРХИТЕКТУРА
03. КОМПОНУЕМАЯ АРХИТЕКТУРА
Использование независимых по коду и данным приложений с понятной бизнесу функциональностью, состоящих из независимо обновляемых микросервисов.
Приложение - PBC (packaged business capabilities):
  • Ориентировано на закрытие конкретной потребности бизнеса
  • Автономно и дает полную информацию о себе
  • Легко включается в новые бизнес-процессы
ЦЕННОСТЬ:
  • Используя комбинации приложений, пользователь может создавать свои собственные приложения для решения новых задач
  • Высокая скорость запуска в работу новых приложений
  • Легкая адаптация приложений к новым задачам путем рекомбинации компонентов
  • Свобода выбора поставщиков компонентов
  • Упрощение многократного использования кода и значительное сокращение сроков создания новых программных решений
НЕПРЕРЫВНОСТЬ БИЗНЕСА
04. НЕПРЕРЫВНОСТЬ БИЗНЕСА

Готовность продолжить выполнение важнейших процессов в случае возникновения экстренной ситуации:

  1. стихийные бедствия;
  2. отключение электроснабжения;
  3. сбои оборудования;
  4. потеря связи.
ЦЕННОСТЬ
  • Наличие геораспределенного кластера. Такое решение позволяет обеспечить высокую надежность системы, которая будет сохранять работоспособность даже в случае выхода из строя одного из ЦОД
  • Наличие гибридной инфраструктуры, совмещающей общее и частное облака. В случае отключения или потери связи с общим облаком процессы компании должны продолжить выполняться в частном облаке
  • Дублирование каналов связи с внешними ЦОД. Связь с внешним ЦОД должна быть даже в случае физического разрыва одного из каналов или выхода из строя оборудования одного из провайдеров
  • Кластеризация всех элементов инфраструктуры позволяет продолжать работу в случае выхода из строя одной из ЦОД кластера
КОНТРАКТНОЕ ПРОЕКТИРОВАНИЕ
05. КОНТРАКТНОЕ ПРОЕКТИРОВАНИЕ (CONTRACTFIRST)
Приложения должны предоставлять документированные API и события для доступа к своей функциональности. Сначала создаются контракты, а затем под ними пишется код.
ЦЕННОСТЬ
  • Для поддержки компонуемой архитектуры
  • Для поддержки двухскоростной архитектуры
  • При достижении консенсуса по контракту команды оказываются в едином информационном поле. Это позволяет одновременно начинать разработку как со стороны поставщика, так и со стороны потребителя.
  • Для обеспечения обратной совместимости новых версий приложений. Задекларированный контракт API и событий должен поддерживаться в новых версиях приложения
ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК УСЛУГА
06. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ КАК УСЛУГА (SAAS)
Использование прикладного программного обеспечения, работающего в облачной инфраструктуре и доступного из различных клиентских устройств, как правило, посредством мобильного приложения или браузера.
ЦЕННОСТЬ
  • Развертывается в центре обработки данных в виде единого программного ядра, с которым работают все заказчики (приложение коммунально)
  • Модернизация и обновление приложения происходит оперативно и прозрачно для заказчиков
  • Заказчики платят не за владение программным обеспечением как таковым, а за его аренду (фактически потребленные услуги)
МИКРОСЕРВИСНАЯ АРХИТЕКТУРА
07. МИКРОСЕРВИСНАЯ АРХИТЕКТУРА
Это вариант сервис-ориентированной архитектуры программных продуктов, направленный на взаимодействие небольших, слабо связанных и легко заменяемых модулей — микросервисов.
ЦЕННОСТЬ
  • Неограниченная масштабируемость – возможность обслуживать тысячи и даже миллионы клиентов
  • Высокая надежность и отказоустойчивость
  • Работа в режиме 24/7 и полное отсутствие технологических окон на модернизацию сервисов
  • Эластичное масштабирование (экономное использование имеющихся ресурсов) – в одно время экстремальные нагрузки может испытывать один сервис, в другое время – другой сервис. Сервисы должны при необходимости занимать свободные ресурсы и сразу их освобождать при снижении
  • Возможность быстро адаптировать бизнес-процессы к изменениям потребностей и ожиданий клиентов
ОМНИКАНАЛЬНОСТЬ
08. ОМНИКАНАЛЬНОСТЬ
Осуществление доступа к единым процессам (продуктам и услугам) через любые каналы, основными из которых являются: веб- и мобильное приложение, call-центр, личный кабинет сотрудника.
ЦЕННОСТЬ
  • Единые процессы для всех каналов
  • Единая логика реализации пользовательского опыта (UX) для всех каналов
  • Процессы могут инициироваться в одном канале, а продолжаться в другом канале
  • Нет огромных затрат на интеграцию приложений и синхронизацию процессов в разных каналах
КОНТЕЙНЕРИЗАЦИЯ
09. КОНТЕЙНЕРИЗАЦИЯ
Технология, которая помогает запускать приложения изолированно. Приложение упаковывается в специальную оболочку-контейнер, внутри которой — среда, необходимая для работы.
ЦЕННОСТЬ
  • Для быстрого перемещения настроенных приложений с одного стенда на другой
  • Для изолированного запуска приложений вне зависимости от системы и ПО, установленных на конкретном стенде
  • Обеспечение высокой надежности; можно одновременно исполнять несколько экземпляров одного сервиса
  • Обеспечение 24/7; можно одновременно исполнять несколько версий одного сервиса и плавно переводить пользователей со старой версии на новую без остановки обслуживания
  • Для легкого управления сложными приложениями, средами и системами
СОБЫТИЙНО-УПРАВЛЯЕМАЯ АРХИТЕКТУРА
10. СОБЫТИЙНО-УПРАВЛЯЕМАЯ АРХИТЕКТУРА
Обеспечивает слабую взаимозависимость между компонентами системы, что приводит к большей гибкости.
ЦЕННОСТЬ
  • Гарантированная доставка сообщений (устойчивость к сбоям) - сообщения сохраняются в очередь и не теряются при отключении обработчика, при восстановлении работы обработчика продолжают обрабатываться
  • Позволяет обрабатывать информацию в реальном времени
  • Легкая масштабируемость: при увеличении количества обработчиков сообщений, пропорционально увеличивается скорость обработки
  • Позволяет расширять возможности и добавлять функциональность, не затрагивая существующие компоненты системы. Будущие приложения могут легко интегрироваться в качестве потребителей событий без изменения существующего решения
НАЛИЧИЕ ПРОЦЕССА ПРОЕКТИРОВАНИЯ
11. НАЛИЧИЕ ПРОЦЕССА ПРОЕКТИРОВАНИЯ
Процесс проектирования структурированного решения, которое соответствует техническим и бизнес-требованиям.
ЦЕННОСТЬ
  • Соответствие техническим (эксплуатационным) требованиям
  • Реиспользование готовых компонентов
  • Соответствие функциональным требованиям
  • Fitness-функции — автоматизированный контроль соответствия архитектурным принципам и проекту
ОСТАЛИСЬ ВОПРОСЫ?
Напишите нам, и мы обязательно вам ответим

*поля обязательные к заполнению