Лк5_Архитектура_ИС_и_стандарты_документирования

1.

2.

?

3.

Архитектура какой-либо системы представляет собой
основные понятия или существенные свойства системы
в окружающей среде в условиях связанных процессов
жизненного цикла системы, воплощенные в ее
элементах, отношениях и конкретных принципах ее
разработки, эксплуатации, сопровождения,
модернизации и развития
Главное - ориентация на достижение целей системы

4.

Архитектура ИС — это...
Принципиальная
организация
Решение бизнес-задач
Баланс ограничений
Создание технологического
Оптимальное соотношение
Структурированное представление
фундамента для достижения
производительности, стоимости,
системы через взаимосвязанные
стратегических целей с учётом
безопасности и масштабируемости
компоненты, определяющие их
функциональных и
системы
взаимодействие и зависимости
нефункциональных требований
Архитектура – это фундаментальная структура системы, определяющая её ключевые свойства, которые со временем
сложно изменять

5.

Почему архитектура важна?
Плохая архитектура приводит к:
Хорошая архитектура обеспечивает:
Системным сбоям и незапланированным простоям
Высокую надёжность и доступность системы
Экспоненциальному росту затрат на поддержку
Горизонтальное и вертикальное масштабирование
Невозможности масштабирования под нагрузкой
Гибкость при изменении требований бизнеса
Технологическому долгу и устаревшим решениям
Предсказуемость затрат и сроков разработки

6.

Почему архитектура важна?
Неправильно выработанная архитектура обусловливает нестабильность ПО, невозможность поддерживать существующие
или будущие бизнес-требования, сложности при развертывании или управлении в среде производственной эксплуатации.
Проектирование систем должно осуществляться с учетом потребностей пользователя, системы (ИТ-инфраструктуры) и
бизнес-целей
Основное назначение архитектуры — описание использования или взаимодействия основных элементов и компонентов
приложения
Часто вопросы архитектуры и проектирования пересекаются. Приступая к работе над архитектурой приложения,
необходимо помнить об основных принципах проектирования.
В информационных технологиях архитектура также включает в себя принципы построения системы и действующие в её
рамках стандарты, а также элементы системы и их взаимосвязи между собой и внешней средой

7.

Архитектурные принципы
Архитектурный принцип — это
сильное утверждение, которое должно
быть выполнено в любой архитектуре
в рамках организации
Формулировка принципов - это первый шаг,
с которого стоит начинать создавать
корпоративную архитектуру
Архитектура во всех отраслях нужна, чтобы избежать рисков:
1.Несогласованности частей целого.
2.Выбора устаревших или непроверенных технологий.
3.Заплаточных или слишком сложных решений.
4.Предотвращения технического долга последующих исправлений.
5.Ликвидация максимума лазеек для злоумышленников.
6.Несоответствия замысла и результата.
7.Противоречий с заказчиком при создании продукта.

8.

Основные принципы проектирования
1. Разделение функций. Разделите приложение на отдельные компоненты, по возможности, минимальным перекрытием
функциональности. Важным фактором является предельное уменьшение количества точек соприкосновения, что обеспечит высокую
связность (high cohesion) и слабую связанность (low coupling). Неверное разграничение функциональности может привести к высокой
связанности и сложностям взаимодействия, даже несмотря на слабое перекрытие функциональности отдельных компонентов.
2. Принцип единственности ответственности. Каждый отдельно взятый компонент или модуль должен отвечать только за одно
конкретное свойство/функцию или совокупность связанных функций.
3. Принцип минимального знания (также известный как Закон Деметера (Law of Demeter, LoD)). Компоненту или объекту не должны
быть известны внутренние детали других компонентов или объектов.
4. Не повторяйтесь. Намерение должно быть обозначено только один раз. В применении к проектированию приложения это означает,
что определенная функциональность должна быть реализована только в одном компоненте и не должна дублироваться ни в одном другом
компоненте.
5. Минимизируйте проектирование наперед. Проектируйте только то, что необходимо. В некоторых случаях, когда стоимость
разработки или издержки в случае неудачного дизайна очень высоки, может потребоваться полное предварительное проектирование и
тестирование. В других случаях, особенно при гибкой разработке, можно избежать масштабного проектирования. Если требования к
приложению четко не определены, или существует вероятность изменения дизайна со временем, старайтесь не тратить много сил на
проектирование раньше времени

9.

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

10.

Архитектура ИС — часть архитектуры предприятия
1
2
3
Стратегия
Бизнес-архитектура
Архитектура приложений
4
Технологическая архитектура
5
Реализация и внедрение
Каждый уровень проектирования строится на основе вышестоящего, обеспечивая согласованность между бизнес-целями и
технологическими решениями. Архитектура информационных систем интегрируется в общий ИТ-ландшафт организации

11.

Цель архитектора ПО при проектировании приложения или системы — максимальное упрощение дизайна через его
разбиение на функциональные области. Например разные функциональные области:
пользовательский интерфейс (user interface, UI)
выполнение бизнес-процессов или доступ к данным
Компоненты в каждой из этих областей должны реализовывать данную конкретную функциональность и не должны
смешивать в себе код разных функциональных областей.
Архитектура программного обеспечения заключает в себе ряд важных решений об организации программной
системы, среди которых выбор структурных элементов и их интерфейсов, составляющих и объединяющих систему в
единое целое; поведение, обеспечиваемое совместной работой этих элементов; организацию этих структурных и
поведенческих элементов в более крупные подсистемы, а также архитектурный стиль, которого придерживается
данная организация
Архитектура программной системы практически никогда не ограничена лишь одним архитектурным стилем,
зачастую она является сочетанием архитектурных стилей, образующих полную систему

12.

Архитектура решения (Solution Architecture) – это архитектура определенной функциональной области или
отдельной автоматизированной системы
Корпоративная архитектура (Enterprise Architecture) – это архитектура организации или группы в целом
Архитектурная функция, в
общем случае, предполагает
выполнение следующих
задач:
•владение актуальной
информацией о текущем
состоянии компонент,
•формирование видения
будущего,
•разработку генерального
плана,
•контроль построения систем
и эксплуатации всех
коммуникаций,
•непрерывное
совершенствование
стандартов и принципов,
•мониторинг обратной связи
от пользователей,
•выявление потребностей
завтрашнего дня.

13.

Важной характеристикой хорошей архитектуры является проработанная возможность горизонтального и вертикального
масштабирования. Именно возможность улучшения или масштабирования системы в обозримом будущем без
необходимости полного реинжиниринга и является признаком хорошей архитектуры
Вертикальное масштабирование – заложенная способность наращивания возможностей системы за счет
увеличения мощности технической платформы, которые система способна полностью использовать для полезной
работы.
Горизонтальное масштабирование – достигается за счет возможности системы работать, как единое целое
при увеличении количества установок, например, на дополнительных серверах, объединенных в единую сеть.
Хорошая архитектура — оптимальный баланс между временем выхода на рынок, простотой изменения,
пропускной способностью, временем отклика на запрос пользователя, инновациями, сопровождением,
надёжностью решения, безопасностью и его стоимостью

14.

Для определения шагов по стандартизации можно воспользоваться международными стандартами, которые отражают
лучший опыт. Самым известным является международный индустриальный стандарт управления архитектурой: The
Open Group Architecture Framework, или сокращённо TOGAF.
Примеры архитектурных принципов из стандарта TOGAF, которые выбраны нами, как хороший пример для
развивающейся организации:
1.Отдавать предпочтение приложениям для экосистемы в целом, а не частным решениям.
2.Использовать общий словарь ключевых данных.
3.Контролировать техническое разнообразие, держать его в приемлемых рамках.
4.Создавать приложения, которые могут просто взаимодействовать друг с другом.
Архитектурный стандарт — это конкретная спецификация проверяемых требований, которым должна
соответствовать каждая архитектура.
1.Управление информацией о клиентах — это общая
функция группы. Она реализуется на уровне группы.
Никто не заводит у себя отдельную функцию
2.Все должны использовать общую клиентскую базу
3.Идентификатор клиента должен присутствовать во
всех операциях и должен быть представлен в
числовом виде
4.Мы все используем системы управления базами

15.

Вызовы современной бизнес-среды в скорости создания и изменения продуктов и сервисов, улучшении потребительских
качеств, снижении стоимости при сохранении надежности, безопасности, доступности. Именно улучшение этих
показателей и преследуется созданием и поддержанием архитектуры предприятия.
Основные показатели эффективности, которым обычно
следуют при проектировании ИТ-Архитектуры, это:
•Время вывода новых продуктов на рынок (Time to
market)
•Простота изменения
•Время отклика
•Пропускная способность
•Безопасность
•Стоимость владения решением
•Возможность поддержки инновационных изменений
•Надежность
•Сопровождаемость
Кроме того, современный тренд развития экосистемной бизнес-модели организаций предполагает формирование новой
сущности: Архитектуры экосистемы. Архитектура экосистемы может быть представлена как объединение архитектур
её участников плюс архитектура общих для экосистемы решений и сквозных процессов. При этом целое в данном случае
однозначно больше суммы его частей, так как именно для получения выгод от синергии и выбирают экосистемную
бизнес-модель

16.

Логика следования слоев архитектуры объясняется последовательностью создания продуктов и сервисов с цифровой составляющей: от
бизнес-идеи, клиентского пути, бизнес-модели к описанию потоков данных, группировки функций и объектов в приложения,
проектирования интеграции автоматизированных процессов и технологического стэка, обеспечивающего работу автоматизированных
систем
Слои
описания
архитектуры
•Бизнес-архитектура: как устроено предприятие, какие бизнес-процессы есть и для каких потребностей нужны те или иные
данные, или автоматизированные системы.
•Информационная архитектура: какие данные используются в организациях, процессах, системах, информационных потоках.
•Архитектура приложений: какая структура и функции приложений, которые требуются для обеспечения потребностей
бизнеса.
•Интеграционная архитектура: как технологически взаимодействуют приложения.
•Техническая архитектура: какая инфраструктура и технологии используются для построения среды функционирования
приложений и размещения данных.

17.

Бизнес-архитектура (business architecture, BA) – это совокупность продуктов, каналов, сегментов, процессов и других
объектов управления, определяющих деятельность организации, а также связей между ними.
К организационной модели относятся бизнес-цели, организационные
единицы, сотрудники и роли, которые связывают организационную модель с
процессной.
К продуктовой модели относятся такие объекты как: Продукт, Канал,
Клиентский сегмент и Клиентский путь, который представляет собой точки
контакта Клиента с процессной моделью.
К объектам управления процессной модели относим компетенции
и процессы, детализированные до технологической карты.
Для ведения вышеперечисленных объектов управления вводятся правила, определяющие их жизненный цикл. Эти правила
фиксируются в Стандарте проектирования, а все процессы в книге или реестре процессов. За каждым разделом реестра
процессов определен свой владелец, эксперт от владельца и группа пользователей процесса, которые могут инициировать
(предлагать) изменения
В современном мире бизнес-архитектура любого предприятия не может существовать в отрыве от ИТ

18.

19.

20.

Карта компетенций также может дать ответы на другие вопросы:
1.Как каждая компетенция способствует достижению целей (шкала критичности компетенций)
2.Как распределен баланс инвестиций в ту или иную компетенцию бизнеса
3.Шкала удовлетворенности — здесь мы можем показать, насколько бизнес удовлетворён автоматизацией
Основные стейкхолдеры - владельцы бизнес-компетенций предприятия с помощью карты могут увидеть взаимосвязи и
контролировать влияние своих решений на связанные бизнес-компетенции и корпоративную архитектуру в целом.
Развитию организации, а особенно, экосистемы чрезвычайно способствуют знания, унификация и переиспользование
уже созданных, лучших бизнес-компетенций внутри холдинга или экосистемы. Примерами таких компетенций может быть
логистика, кадровый учет, финансы и другие операционные и производственные функции.
В общем случае для реализации бизнес-компетенции должен быть организован некий процесс. Вспомним, что обычно под
этим термином понимается.
Процесс — это совокупность действий, выполняемых в заданном порядке для повторяемого достижения
требуемого результата
Итак, процессы разделяют на:
•бизнес-процессы, которые создают ценность для внешнего Клиента;
•поддерживающие процессы, которые создают ценность для внутреннего Клиента;
•управляющие процессы, которые создают ценность для организации в целом и не имеют явно выраженного Клиента;

21.

22.

Процессы имеют следующие характеристики:
•повторяемость - возможность предоставления клиенту воспроизводимого результата. Процесс предоставляет Клиенту
услугу повторяемым, а не уникальным образом. Разовое создание уникального результата не является процессом;
•фактические границы - т.е. процесс имеет начало и конец. У процесса есть событие старта и событие окончания. Есть
определённые события или действия, инициирующие первое и заключительное действие организации — например, Банка,
связанное с предоставлением услуги Клиенту;
•переиспользование результатов - процесс может включать в себя (переиспользовать) другие процессы (между
владельцами возможно заключение SLA, то есть соглашение об уровне сервиса)
•владение собственными данными - процесс должен использовать только те данные, которыми он владеет;
•сквозной характер - процесс может проходить сквозь границы ответственности различных подразделений для получения
результата;
•владелец и метрики - за владельцем процесса закреплен контроль его реализации.

23.

24.

Информационная архитектура - второй слой
проектирования цифровых процессов, в котором
происходит определение информации,
обрабатываемой в процессах, и проектирование
функций по хранению и обработке данных.
Корпоративная модель данных (КМД) –
инструмент стандартизации описания данных,
объединяющий концептуальный, логический и
физический уровень
На концептуальном уровне выделяют такие объекты управления,
как Сущность (DataEntity в Сбер или BusinessObject по TOGAF).
Это уровень взаимодействия организаций в рамках выполнения
процессов.
На логическом уровне к объектам управления относят Элементы
данных (DataElement – в Сбер, Business Data по TOGAF). Это
уровень Автоматизированных Систем и их взаимодействия.
На физическом уровне к объектам управления относят Набор данных. Это
уже уровень Баз данных и Систем Управления Базами Данных. То есть этот
уровень про то, где физически «живут» данные.

25.

К

26.

27.

28.

29.

Правило трёх C
КМД применяется в следующих сценариях/задачах/ситуациях:
•Организации обмена данными между АС.
•Проектирование процессов (референс).
•Контроль доступа к данным.
•Категоризация конфиденциальной информации (К1-К4) для
безопасности данных.
•Определение метрик и контрактов для контроля качества данных
(Правило 3-х С).
•Правила, стандарты и требования к физической реализации в
Фабрике данных.

30.

Фабрика данных — корпоративная аналитическая платформа и связанные с ней сервисы

31.

Домены в управлении данными, которые входят в Фабрику
данных:
•Сервисы загрузки / обработки / выгрузки данных.
•Витрина данных.
•Аналитика.
•Отчетность (управленческая / аналитическая).
•Разделяемое хранилище данных.
•Управление нормативно-справочной информацией.
•Управление жизненным циклом данных.
•Контроль качества данных.
•Защита данных.
•Сервисы доступа и сертификации данных.
•Супермаркет данных.
•Лаборатории данных.
Задачи, решаемые Фабрикой данных:
•Управленческая отчетность в режиме реального времени.
•Регуляторная и налоговая отчетность.
•Массовая персонализация, вторичные продажи, AML.
•Транзакционный скоринг AI в потребительском кредитовании.
•Принятие решений в режиме близком к реальному времени
(K7M).
•Пакетное исполнение моделей, (data mining, bigdata).
•Получение единой картины качества данных на уровне Группы.
•Возможности для Data Scientist.

32.

Архитектура приложений — это совокупность приложений или автоматизированных
систем компании, существующих для поддержки её бизнес-процессов, а также набор
стандартов и инструментов.
Приложение — это набор программных модулей, обеспечивающий выполнение взаимосвязанных функций.
Приложение состоит из функциональных подсистем (ФП), а каждая ФП - из компонент.
Часто приложение, ключевой объект архитектуры приложений, называют автоматизированной системой или используют
устоявшееся сокращение - АС.
В Архитектуре приложений, как правило, выделяют три основных уровня управления, характеризуемых используемыми
инструментами:
1.Карта приложений (АС).
2.Реестр приложений (АС).
3.Архитектура АС (Software Architecture).

33.

Карта приложений (АС) — это инструмент, позволяющий анализировать зрелость ИТ в организации
(текущее состояние — As Is), планировать целевое состояние (To Be) и управлять изменениями (план
перехода — Roadmap).
Карта в своих
координатах
отражает
бизнескомпетенции
(по вертикали),
организационн
ые единицы (по
горизонтали), а
на пересечении
– АС, в которых
реализуются
бизнескомпетенции
компании.
Важным
применением
такого
инструмента
считается
оценка
соответствия
стратегии
утверждённым
решениям или
корпоративным
стандартам
•Синий цвет общекорпоративны
й продукт, который
реализован на
платформе и
удовлетворяет
стандартам
•Зелёный цвет локальное
решение,
реализованное не
на платформе, но
удовлетворяющее
стандартам
•Жёлтый цвет локальное
решение,
реализованное не
на платформе и не
удовлетворяющее
стандартам
•Красный цвет функция не
автоматизирована
или
автоматизирована
неудовлетворитель
но —
информационная
система не
удовлетворяет
стандартам
•Серый цвет - нет
необходимости в
автоматизации
функции
•Белый цвет - нет
информации об
автоматизации
бизнес-

34.

Эволюция архитектуры приложений
Эволюция архитектуры приложений также происходит с точки зрения современных трендов реализации архитектуры и
использования инструментов реализации в различных технических и программных средах функционирования программного
обеспечения и хранения данных.
Функциональная эволюция
Данная градация состоит прежде всего в уровне использования
современных подходов к реализации и среды функционирования,
например, облачных (Cloud) вычислений.
Legacy-система – это АС, которая перестала удовлетворять
требованиям бизнеса или соответствовать архитектурным
критериям. Устаревшие системы, обеспечивающие работу
бизнеса в текущий момент, часто называют Legacy. Они часто
требуют реинжиниринга или замены, если вообще у владельцев
есть желание оставить этот бизнес-сервис.
Platform-ready приложение максимально приспособлено для существования и развития на основе ИТ-платформы
организации, т.е. использует стандартные компоненты, объекты, подсистемы платформы, может быть безболезненно
пересобрано из улучшенных компонент из указанных. Более того, это приложение само может быть составной частью
платформы, т.е. нести функциональность, которую можно переиспользовать в других системах путем интеграции, о которой
мы поговорим в следующем разделе.

35.

36.

37.

Интеграционная архитектура — это совокупность взаимодействий между приложениями (автоматизированными
системами в нашей терминологии), а также соответствующих стандартов и инструментов

38.

39.

40.

41.

API (Application Programming Interface) – это
способ организации взаимодействия
приложений, путем фиксации контракта
между двумя сторонами

42.

Синхронная интеграция также известная как интеграция "запрос-ответ". В этом случае источник и получатель всегда на связи.
Система-потребитель, отослав запрос, блокируется и может продолжать работу только после получения ответа от сервера. По
этой причине такой вид взаимодействия часто называют блокирующим (blocking). Примером такого взаимодействия в реальной
жизни можно назвать телефонный звонок. Когда вы разговариваете по телефону, вы не сможете эффективно заниматься другими
делами

43.

44.

Асинхронная интеграция также известна, как интеграция по событиям. При этом способе взаимодействия источник и
получатель информации выходят на связь при необходимости. Система A отправляет сообщение системе B и продолжает
работать, не дожидаясь ответа

45.

46.

47.

Существует несколько паттернов, или шаблонов интеграции, в эволюционном развитии. Развитие интеграции напрямую
связано с числом взаимодействующих систем в реальных процессах, а также с их структурой
В начале эволюции интеграции, а также сегодня, в простых системах, использовалась интеграция "точка-точка". Подход прямого
вызова другой системы или подсистемы понятен, легко реализуем и достаточно устойчив, когда систем в интеграции немного и
процессы не требуют постоянной модификации и развития.
Сервисная шина предприятия (англ. enterprise service bus, ESB) — связующее программное обеспечение,
обеспечивающее централизованный и унифицированный событийно-ориентированный обмен сообщениями между
различными информационными системами на принципах сервис-ориентированной архитектуры
Service Mesh может включать в себя элементы как для реализации синхронных, так и асинхронных взаимодействий, в соответствии с задачами,
для которых системы, микросервисы, другие компоненты платформы связываются в процесс.

48.

49.

50.

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

51.

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

52.

Виртуализация — это предоставление вычислительных ресурсов на одном физическом сервере для
изолированной работы набора приложений в рамках разных операционных систем
На одном сервере для каждого пользователя или для функционирования одного
набора АС кроме операционной системы самого сервера, запускается еще столько
операционных систем в изолированных сегментах памяти, сколько у нас будет
виртуальных машин/виртуальных серверов.
Это позволяет подключиться к виртуальному серверу и иметь на рабочем столе
полностью рабочую привычную оболочку индивидуальной операционной системы и
использовать ее изолированно или как физическую сетевую машину.
Разворачивается виртуальная машина известных провайдеров за минуты и
позволяет полноценно использовать выделенное провайдером рабочее
пространство: выделенное количество процессоров и объем памяти.

53.

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

54.

Использовались физические серверы, на их
развёртывание уходили месяцы, принятие решений
занимало годы
Технологии виртуализации
Основные объекты –
виртуальные машины –
развёртывание – минуты
Контейнеризация возникла по причине того, что возросли требования
пользователей систем к скорости разворачивания и гибкости используемой
инфраструктуры. С другой стороны, поставщики сервисов понимали, что есть
возможность, с одной стороны сэкономить, вычислительные ресурсы, а с другой
стороны, улучшить показатель времени вывода на рынок новых продуктов
Технологии контейнеризации
Развёртывание за секунды
Время на обновление измеряется часами

55.

Стандартизация компонентов технической архитектуры осуществляется с помощью технологических стеков
Технологический стек — это стандартизированный набор связанных технологий, используемый при
создании автоматизированных систем определённого уровня критичности

56.

57.

Технологический домен — это логическое объединение
компонентов технической архитектуры по их типам для их
классификации и совместного анализа
Примерами доменов
являются различные
центры обработки
данных - основные
Центры обработки
данных (ЦОД)

58.

59.

60.

Облачные вычисления (или по-английски — cloud
computing) — это технология распределённой
обработки данных, в которой вычислительные
ресурсы и бизнес-функциональность
предоставляются пользователю как сервис.
Можно утверждать, что всё дальнейшее развитие ИТ будет в облаках.
Технические и программные компоненты разрабатываются с учетом
именно такого применения. Такой подход в мире ИТ назвали cloud-native,
т.е. подход максимального приспособления к жизни в облаках, без
привязки к конкретному «железу» или среде функционирования, с
возможностью быстрого разворачивания и восстановления в предыдущее
состояние, масштабирования и так далее.

61.

Основные ГОСТы по архитектуре ИС
ГОСТ Р 59793–2021
ГОСТ 34.602–2020
ГОСТ 34.201-2020
Автоматизированные системы.
Стадии создания
Техническое задание на
создание АС
Виды, комплектность и
обозначение документов
Определяет жизненный цикл АС
Включает стадию разработки
архитектуры
Определяет состав проектной
документации
Регламентирует
документирование архитектуры
Раздел "Требования к системе"
включает архитектурные
требования
ГОСТ Р ИСО 15704-2022
ГОСТ Р ИСО/МЭК 12207
ГОСТ Р 57100-2025
Р ИСО 15704-2022:
Моделирование и архитектура
предприятия
Процессы жизненного цикла
программного обеспечения
Системная и программная
инженерия
Требования к документации
Введён в действие с 2021 года,
обновлён в 2025 году с учётом
современных технологических
тенденций и лучших практик
индустрии
Устанавливает требования к
стандартным архитектурам и
методологиям моделирования
предприятия
Международный стандарт,
адаптированный для РФ
Включает процессы
архитектурного проектирования

62.

Architecture)
-
-
Architecture)
Architecture)

63.

-2020
1
2
-
3
4

64.

Структура архитектурной документации по ГОСТ
Р 57100-2025
01
02
03
Описание компонентов
Принципы проектирования
Форматы и требования
Детальное описание всех компонентов
Документирование ключевых
Определение стандартных форматов
системы и характера их
принципов проектирования, реализации
представления информации и
взаимодействий, включая интерфейсы,
и эксплуатации системы для
требований к полноте содержания
протоколы и форматы данных
обеспечения согласованности решений
архитектурной документации

65.

2021
01
04
02
03
05

66.

-
-
-tier)
-

67.

Основные типы архитектуры программного обеспечения
Архитектурный стиль/парадигма
Описание
Монолитная архитектура
Единый исполняемый блок кода, объединяющий все функциональные модули
системы в одном развёртываемом артефакте
Многослойная архитектура
Функциональные области приложения разделяются на многослойные группы (уровни)
Микросервисная архитектура
Каждый микросервис представляет собой автономное приложение со своей базой
данных, бизнес-логикой и API
Клиент-серверная архитектура
Система разделяется на два приложения, где клиент выполняет запросы к серверу. Во
многих случаях в роли сервера выступает база данных, а логика приложения представлена
процедурами хранения
Дизайн приложения разлагается на функциональные или логические компоненты с
возможностью повторного использования, предоставляющие тщательно проработанные
интерфейсы связи
Компонентная архитектура
Сервисно-ориентированная
архитектура (SOA)
Описывает приложения, предоставляющие и потребляющие функциональность в виде
сервисов с помощью контрактов и сообщений
Объектно-ориентированная
Парадигма проектирования, основанная на распределении ответственности приложения
или системы между отдельными многократно используемыми и самостоятельными
объектами, содержащими данные и поведение

68.

SOA (Service-Oriented
Architecture)
Event-Driven Architecture
Pipe-and-
-

69.

Базовые типы приложений:
1. Мобильные приложения. Приложения этого типа могут разрабатываться как тонкий клиент или насыщенное клиентское приложение.
Насыщенные клиентские мобильные приложения могут поддерживать сценарии без постоянного подключения или без подключения
вообще. Веб-приложения или тонкие клиентские приложения поддерживают только сценарии с подключением
2. Насыщенные клиентские приложения. Приложения этого типа обычно разрабатываются как самодостаточные приложения с
графическим пользовательским интерфейсом, который обеспечивает отображение данных с помощью набора элементов управления.
Насыщенные клиентские приложения могут поддерживать сценарии без подключения или без постоянного подключения, если должны
выполнять доступ к удаленным данным или функциональности.
3. Насыщенные Интернет-приложения. Приложения этого типа могут поддерживать множество платформ и браузеров. Насыщенные
Интернет-приложения выполняются в изолированной программной среде браузера, которая ограничивает доступ к некоторым
возможностям клиента. Принцип работы RIA заключается в том, что пользовательский интерфейс приложения обновляется частично, без
необходимости полной перезагрузки страницы. Это создает впечатление быстродействия и отзывчивости, что особенно важно для
современных веб-приложений.
4. Сервисные приложения. Сервисное приложение – это приложение, которое представляет собой одно целое и предоставляет определенный
функционал пользователям. Сервисы предоставляют бизнес-функциональность для совместного использования и позволяют клиентам
доступ к ней из локальной или удаленной системы. Вызов операций сервиса осуществляется с помощью сообщений, соответствующих
XML-схемам и передаваемых по транспортным каналам. Целью данного типа приложений является обеспечение слабой связанности между
клиентом и сервером. Каждый из этих сервисов может быть разработан, развернут и масштабирован независимо от остальных, что делает
систему более гибкой и масштабируемой. Такая архитектура позволяет быстро адаптироваться к изменениям и улучшать отдельные
компоненты системы без значительных воздействий на другие части.
5. Веб-приложения. Приложения этого типа, как правило, поддерживают сценарии с постоянным подключением и различные браузеры,
выполняющиеся в разнообразнейших операционных системах и на разных платформах.
6. Микросервисная архитектура. Способ создания программных продуктов, предполагающий разработку независимых друг от друга
модулей. Каждая часть отвечает за определенную задачу и может быть изменена или расширена без перемен в других. При этом сервисы
взаимодействуют между собой с помощью обмена сообщениями.

70.

Тип приложения
Преимущества
Насыщенные
Возможность
клиентские
использования ресурсов
приложения
клиента. Лучшее время
отклика, насыщенная
функциональность UI и
улучшенное
взаимодействие с
пользователем. Очень
динамичное
взаимодействие с
коротким временем
отклика. Поддержка
сценариев без
подключения и
сценариев без
постоянного
подключения
Недостатки
Пример
Сложность
Примером архитектуры
развертывания; при этом насыщенных клиентских
широкий выбор
приложений может быть
вариантов установки,
современный вебтаких как ClickOnce,
приложение, построенное с
Windows Installer и XCOPY. использованием
Сложности обеспечения фреймворков, таких как React,
совместимости версий.
Angular или Vue.js. В этой
Зависимость от
архитектуре большая часть
платформы
бизнес-логики выполняется на
стороне клиента, в браузере
пользователя, что позволяет
создавать интерактивные и
отзывчивые интерфейсы без
необходимости постоянного
обращения к серверу.

71.

Тип приложения
Преимущества
Недостатки
Мобильные
Поддержка портативных Ограниченные
приложения
устройств. Доступность и возможности ввода и
простота использования навигации. Ограниченная
для мобильных
область отображения
пользователей.
экрана
Поддержка сценариев без
подключения и сценариев
без постоянного
подключения
Пример
В случае мобильных
приложений, часто
используется архитектурный
подход MVP (Model-ViewPresenter) или MVVM (ModelView-ViewModel). В этих
архитектурах основной упор
делается на разделение
бизнес-логики от
пользовательского
интерфейса, что упрощает
разработку, тестирование и
поддержку приложения.

72.

Тип приложения
Насыщенные
Интернетприложения
(RIA)
Преимущества
Недостатки
Такие же насыщенные
Больший объем памяти,
возможности
занимаемый на клиенте,
пользовательского
по сравнению с Вебинтерфейса, как и для
приложением
насыщенных клиентов.
Ограниченное
Поддержка насыщенных использование ресурсов
и потоковых мультимедиа клиента по сравнению с
и графики
насыщенным клиентским
Простота развертывания
с возможностями
распределения
(насыщенными) такими
же, как и для Вебклиентов. Простота
обновления и смены
версий. Поддержка
различных платформ и
браузеров
Пример
В архитектуре RIA обычно
используются клиентские
технологии, такие как HTML,
CSS, JavaScript, а также
серверные технологии для
обработки запросов и
предоставления данных. При
этом данные могут
передаваться между клиентом
приложением.
и сервером в формате JSON
Необходимость
развертывания на клиенте или XML.
подходящей среды
выполнения
RIA-приложения часто
строятся на базе фреймворков
и библиотек, таких как
Angular, React, Vue.js и других,
которые облегчают разработку
интерактивного
пользовательского интерфейса
и управление данными.

73.

Тип приложения
Преимущества
Сервисные
Слабо связанное
приложения
взаимодействие между
клиентом и сервером.
Могут использоваться
различными и
невзаимосвязанными
приложениями.
Поддержка для
обеспечения
возможности
взаимодействия
Недостатки
Отсутствие поддержки
UI. Зависимость от
возможности сетевого
подключения
Пример
Пример сервисной
архитектуры можно
представить на примере
интернет-магазина:
1. Сервис каталога товаров,
который отвечает за хранение
и предоставление информации
о товарах.
2. Сервис корзины,
отвечающий за управление
товарами, добавленными в
корзину покупателя.
3. Сервис оформления заказа,
который обрабатывает заказы,
собранные в корзине, и
осуществляет процесс
оформления покупки.
4. Сервис уведомлений,
который отправляет
уведомления покупателям о
статусе их заказов.

74.

Тип приложения
Преимущества
Веб-приложения Широкодоступный и
основанный на
стандартах UI,
поддерживаемый на
многих платформах.
Простота развертывания
и внесения изменений
Недостатки
Необходимость
устойчивого сетевого
подключения. Сложно
обеспечить насыщенный
пользовательский
интерфейс
Пример
Пример архитектуры вебприложения на React
базируется на компонентах,
управлении состоянием,
жизненном цикле
компонентов и
маршрутизации, что позволяет
создавать интерактивные и
масштабируемые приложения

75.

Тип приложения
Микросервисная
архитектура
(MSA)
Преимущества
Недостатки
Пример
С точки зрения бизнеса Из недостатков
Каждый из этих
и чисто
микросервисной
микросервисов имеет свою
организационных задач, архитектуры можно
собственную базу данных и
преимущества
отметить такие, как:
API для взаимодействия с
микросервисов сводятся Сложная распределенная другими сервисами, например,
к трём основным:
система. Наличие
сервис авторизации, сервис
лёгкость обновления
множества отдельных
управления товарами, сервис
кода; разные команды
модулей влечет за собой обработки заказов, сервис
могут использовать
дополнительную
оплаты, сервис уведомлений
разные стеки для разных сложность в
модулей; компоненты
организационном и
могут масштабироваться архитектурном плане. То
независимо друг от
есть усложняется
друга, что снижает
контроль над различными
затраты и стоимость
командами
масштабирования всего разработчиков, а также
приложения в целом в
само развертывание
тех случаях, если узким программного продукта.
местом выступает лишь Усложненное
какая-то одна функция. тестирование.

76.

-2020

77.

-

78.

-

79.

(Component Diagram)
Diagram)
(Deployment Diagram)

80.

ArchiMate
ArchiMate:
-
(Enterprise Architecture)
-

81.

API Gateway
Service Mesh
CQRS (Command Query Responsibility
Segregation)

82.

DevOps
CI/CD (Jenkins, GitLab CI, GitHub Actions)

83.

25010)

84.

ATAM (Architecture Tradeoff Analysis Method)

85.

- Architecture Decision Records)
ADR
01
02
03
-
04
05

86.

"
"
2020:

87.

Enterprise Architect
Sparx Systems
Draw.io (diagrams.net)
-
Lucidchart
-
Microsoft Visio
-

88.

❌
❌
❌
❌
❌

89.

✅
✅
✅
UMLER-
✅
✅

90.

-

91.

-
Architecture Runway
(Just Enough
Architecture)
Spike
Definition of Done
(PlantUML, Mermaid)

92.

]
↓
-
]
↓
]
↓
Presentation: Web-
Business Logic: Application Server (Node.js, Django)
Data Access: ORM (Sequelize, Django ORM)
Database: PostgreSQL

93.

[API Gateway]
↓
[Service Mesh]
├── [User Service] → [User DB]
├── [Catalog Service] → [Catalog DB]
├── [Order Service] → [Order DB]
├── [Payment Service] → [Payment Gateway]
└── [Notification Service] → [Message Queue]
API Gateway: Kong, AWS API Gateway
Service Mesh: Istio, Linkerd
Message Queue: RabbitMQ, Kafka

94.

95.

Компоненты
Внутренние модули внутри контейнеров
Контейнеры
Основные приложения и их взаимодействия
Контекст
Общий взгляд на систему и внешние акторы

96.

C4-
Инструменты для C4-модели
Structurizr — специализированный инструмент для C4
PlantUML — текстовое описание диаграмм
Draw.io — ручное создание с использованием библиотек C
Mermaid — диаграммы "как код"
C4-модель — это подход к визуализации архитектуры программного обеспечения через четыре уровня абстракции:
Системный контекст (Context)
Компоненты (Components)
Пример Покупатель – Интернет-магазин – Платёжная система
|
Служба доставки
Контейнеры (Containers)
Код (Code)
Веб-сайт – API – Сервис книг
|
Сервис заказов – Сервис пользователей
|
|
БД заказов
БД пользователей
реализация на уровне классов

97.

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

98.

Пример диаграммы контекста: интернет-магазин
Покупатели
Администраторы
Просмотр товаров, заказы, оплата
Управление каталогом и заказами
Интернет-магазин
Центральная система
взаимодействия
Платежный шлюз
Аналитика / CRM
Обработка платежей и статусов
Сбор данных и управление клиентами
Пользователи
Внешние системы
Система
Покупатели
Платежные шлюзы
Центральный элемент, связывающий всех участников
Администраторы
Аналитика
Менеджеры
CRM

99.

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

100.

101.

Что такое контейнеры в C4?
Контейнеры — это исполняемые или развертываемые части системы, каждая из которых работает в отдельном процессе
Исполняемые части
Технологический стек
Взаимодействия
Веб-приложения, мобильные
Определяют используемые
Показывают протоколы и форматы
приложения, базы данных,
технологии и зоны технической
обмена данными между крупными
микросервисы, файловые
ответственности команд
блоками системы
хранилища
Важно: Контейнер — это не Docker-контейнер, а логическая единица развертывания с отдельным процессом
выполнения

102.

Пример диаграммы контейнеров: сервис заказа лекарств
Веб-клиент
Сервер приложений
React SPA, взаимодействие с API по HTTPS
Node.js, REST API, логика заказа по HTTPS
Контейнеры сервиса
заказа лекарств
База данных
Внешние API
PostgreSQL, хранение заказов и
пользователей
Платежи (HTTPS) и аналитика (HTTPS)
Фронтенд
Бэкенд
Хранилище
Интеграции
Веб-клиент (React)
Сервер приложений (Node.js)
База данных (PostgreSQL)
Внешние API
SPA приложение для взаимодействия с
REST API для обработки бизнес-логики
Реляционное хранилище данных о заказах
Платежи, аналитика, уведомления
пользователями

103.

Зачем нужны диаграммы контейнеров?
Планирование архитектуры
Помогают выбрать оптимальные технологии и распределить ответственность между компонентами до начала
разработки
Выявление проблем
Обнаруживают узкие места, точки отказа и сложные интеграции на ранних этапах проектирования
Техническое обсуждение
Упрощают дискуссии о технических решениях, DevOps-процессах и стратегии развертывания в команде

104.

105.

Что такое компоненты?
Определение
Назначение
Компоненты — это группы связанной функциональности,
Отражают внутреннюю логику и зависимости внутри
инкапсулированные за четко определенным интерфейсом
конкретного контейнера системы
Компоненты позволяют детально спроектировать и
Модули и сервисы
документировать сложные части системы без потери
Библиотеки и пакеты
общей картины
Контроллеры и обработчики
Репозитории и адаптеры

106.

Пример диаграммы компонентов: модуль обработки заказов
Внешние сервисы
Node.js сервер
Контейнер приложения
БД, платежи, почта, SMS
Авторизация (JWT)
Уведомления
Модуль обработки
заказов
Проверка прав доступа
Email, SMS, push
Корзина
Оплата
Авторизация
Корзина
JWT токены, проверка прав доступа
Управление товарами, расчет стоимости
Оплата
Интеграция с платежным шлюзом
Уведомления
Интеграция с платежным шлюзом
Управление товарами, расчёт
Email, SMS, push-уведомления

107.

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

108.

109.

Диаграммы кода в C4
Уровень детализации
Инструменты и практика
Самый глубокий уровень модели C4,
Часто используют существующие нотации:
показывающий:
UML диаграммы классов
Классы и интерфейсы
ERD для баз данных
Структуры данных
Встроенные инструменты IDE
Методы и их связи
Паттерны проектирования
На практике этот уровень применяется редко — только для
самых сложных алгоритмов или критичных деталей

110.

Пример диаграммы кода: класс авторизации
пользователя
class AuthenticationService { - userRepository: UserRepository - tokenService: TokenService - passwordHasher: PasswordHasher
+
authenticate(credentials): AuthToken + validateToken(token): boolean + refreshToken(refreshToken): AuthToken - hashPassword(password):
string - verifyPassword(password, hash): boolean}
Диаграммы кода помогают разработчикам понять внутреннюю логику и взаимосвязи между классами при работе со сложными компонентами
Часто эта информация генерируется автоматически из исходного кода с помощью инструментов документирования

111.

Популярные инструменты
Structurizr
Draw.io
Текстовое описание архитектуры на DSL с автоматической
Удобный графический редактор с библиотеками элементов C4 и
визуализацией и версионированием
экспортом в разные форматы
Код как источник истины
Интуитивный интерфейс
Множественные представления
Бесплатный и доступный
PlantUML + C4
Новые редакторы
Расширение PlantUML специально для C4 с поддержкой
IcePanel, Ilograph и другие с интерактивностью, коллаборацией и
текстового формата и интеграции в CI/CD
современным UX
Легкий синтаксис
Облачная работа
Автоматизация
Командное редактирование

112.

Service)
Eventual Consistency

113.

WAF (Web Application Firewall)
OAuth 2.0 / OpenID Connect
RBAC (Role-Based Access Control)

114.

→
→
→
→
→

115.

Современные архитектурные паттерны и практики
-
-
-
-

116.

AWS Well-Architected Framework: эталонные
облачные архитектуры
Набор проверенных практик и рекомендаций для проектирования надежных облачных решений.
Безопасность
Производительность
Защита данных, управление идентификацией,
Оптимальное использование ресурсов и
обнаружение угроз и соответствие стандартам
масштабирование под нагрузку
Надежность
Эффективность
Устойчивость к сбоям, резервное копирование и
Оптимизация затрат и рациональное управление
быстрое восстановление
облачными ресурсами

117.

Пример: бессерверный механизм повторных
попыток для очередей
Ключевые возможности
Бессерверная архитектура на базе Lambda функций обрабатывает
сообщения из очередей SQS, автоматически повторяя попытки при
Обработка ошибок без сохранения
возникновении ошибок. Это повышает надежность облачных
состояния
приложений без необходимости управления серверами.
Экспоненциальное замедление повторных
попыток
Автоматическое масштабирование под
нагрузку
Снижение затрат через оплату по факту
использования
Такой подход особенно эффективен для обработки событий,
интеграции систем и асинхронных операций

118.

Шаблон описания архитектуры ПО
Комплексная методология систематизации информации об архитектуре и функциональности информационных систем.
Требования
Компоненты
Функциональные и нефункциональные требования к
Описание модулей, сервисов и их взаимодействия
системе
Связи
Принципы
Интерфейсы, протоколы и потоки данных
Архитектурные решения и обоснования
Основан на международных стандартах ISO/IEC 42010 и методологии TOGAF для корпоративной архитектуры

119.

Тенденции 2025 года
Событийные и бессерверные
архитектуры
1
Рост популярности Event-Driven Architecture и
Serverless решений для повышения гибкости и
снижения затрат на инфраструктуру
2
Отечественные технологии
Активное внедрение российских СУБД, облачных
платформ и ПО в рамках импортозамещения и
Безопасность и управляемость
3
обеспечения технологической независимости
4
Искусственный интеллект
Усиление требований к защите данных,
соответствию регуляторным стандартам и
прозрачности архитектурных решений
Интеграция AI/ML в архитектуру ИС для
автоматизации принятия решений, предиктивной
аналитики и оптимизации процессов

120.

✅
✅
✅
✅

121.

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