Школа
системного анализа
и проектирования
системного анализа
и проектирования
Systems Education
Школа системного анализа
и проектирования
Школа системного анализа
и проектирования
Оглавление
Оглавление
Автор: АННА Вичугова
Что такое архитектура информационных систем и как её проектировать
Введение
Проектирование архитектуры — неотъемлемый этап разработки информационных систем (ИС) и один из самых важных. Всё больше работодателей ожидает от системных аналитиков понимания принципов архитектуры ИС и навыков проектирования.
В этой статье о том:
■ что такое архитектура и зачем она нужна;
■ какие уровни архитектурного проектирования существуют;
■ что входит в процесс проектирования архитектуры;
■ как принимать архитектурные решения.
Статья будет полезна системным и бизнес-аналитикам, которые хотят узнать нюансы архитектурного проектирования и начать говорить с архитекторами на одном языке.
В этой статье о том:
■ что такое архитектура и зачем она нужна;
■ какие уровни архитектурного проектирования существуют;
■ что входит в процесс проектирования архитектуры;
■ как принимать архитектурные решения.
Статья будет полезна системным и бизнес-аналитикам, которые хотят узнать нюансы архитектурного проектирования и начать говорить с архитекторами на одном языке.
Что такое архитектура информационных систем и зачем она нужна?
Архитектура — многозначный термин. Он используется в строительстве, инженерной деятельности, управлении, вычислительной технике и других областях. В общем смысле под архитектурой понимают описание принципов устройства любой системы: здания, организации, бизнеса, технического устройства, базы данных, программного обеспечения.
А что такое система?
Система — это совокупность взаимосвязанных элементов, вместе работающих на достижение общей цели.
В контексте ИТ и в широком смысле архитектура — это искусство и наука проектировать и строить комплексные системы, создающие организованную среду для решения бизнес-задач в соответствии с требованиями, техническими возможностями и ограничениями.
Архитектура ИС — более узкое понятие. Архитектура ИС — это принципиальная организация системы, то есть:
■ набор компонентов ИС;
■ связи компонентов друг с другом и окружающей средой;
■ принципы, определяющие проектирование, реализацию, развитие и эксплуатацию всей ИС.
Важно помнить, что любая ИС — это одновременно подсистема и надсистема для других систем.
А что такое система?
Система — это совокупность взаимосвязанных элементов, вместе работающих на достижение общей цели.
В контексте ИТ и в широком смысле архитектура — это искусство и наука проектировать и строить комплексные системы, создающие организованную среду для решения бизнес-задач в соответствии с требованиями, техническими возможностями и ограничениями.
Архитектура ИС — более узкое понятие. Архитектура ИС — это принципиальная организация системы, то есть:
■ набор компонентов ИС;
■ связи компонентов друг с другом и окружающей средой;
■ принципы, определяющие проектирование, реализацию, развитие и эксплуатацию всей ИС.
Важно помнить, что любая ИС — это одновременно подсистема и надсистема для других систем.
- ИС состоит из множества связанных компонентов, которые взаимодействуют друг с другом.
- ИС находится не в вакууме, а имеет окружение: другие системы и объекты реального мира.
- ИС необходимо взаимодействовать со своим окружением: отвечать на его вызовы и изменения.
Рис.1 — ИС всегда находятся в контексте окружающего мира
Для чего вообще нужно продумывать, проектировать и документировать архитектуру ИС? Почему нельзя просто разрабатывать так, как получится, не задумываясь об архитектуре?
Есть несколько причин, почему о проектировании архитектуры нужно подумать заранее. И, что важно, спроектировать архитектуру грамотно. Рассмотрим на практических примерах, как архитектура помогает бизнесу.
Есть несколько причин, почему о проектировании архитектуры нужно подумать заранее. И, что важно, спроектировать архитектуру грамотно. Рассмотрим на практических примерах, как архитектура помогает бизнесу.
Чем может обернуться плохая архитектура?
- Негативный пользовательский опыт. Для внутренних продуктов это может быть не так критично. Если вы продаёте продукт на рынке, это может принести серьёзные убытки.
- Простои в бизнес-процессах из-за снижения производительности или отказов.
- Проблемы в интеграции с внешними системами.
- Дороговизна поддержки и эксплуатации.
- Затраты на исправление или полную переделку ИС.
Уровни архитектурного проектирования
Уровни архитектурного проектирования различаются в зависимости от того, что выступает объектом проектирования.
Архитектура ИС тесно связана с архитектурой бизнеса и общего ИТ-ландшафта организации. Можно сказать, что архитектура ИС — составная часть всей архитектуры предприятия.
Архитектура ИС тесно связана с архитектурой бизнеса и общего ИТ-ландшафта организации. Можно сказать, что архитектура ИС — составная часть всей архитектуры предприятия.
Рис.2 — Место архитектуры ИС в архитектуре предприятия
В зависимости от уровня архитектуры отвечать за проектирование могут разные лица.
- Уровень стратегии и мотивации. На этом уровне проектируются стратегические цели, концепции развития и привлечения клиентов.
- Уровень бизнеса. Здесь проектируются бизнес-процессы, роли и функции, оргструктура предприятия.
- Уровень приложений, БД. На этом уровне формируется ИТ-ландшафт предприятия, совокупность платформ и систем, обеспечивающих бизнес.
- Уровень технологий. Здесь проектируется используемые в компании инфраструктурные и технологические подходы, решения и концепции.
- Уровень реализации и внедрения изменений. На этом уровне проектируется архитектура конечных систем предприятия, выбираются прикладные решения.
Рис.3 — Лица, принимающие решения на разных уровнях архитектуры предприятия
Разделение архитектуры на уровни хорошо отражает нотация моделирования ArchiMate. Основные (но не все), уровни проектирования этой нотации:
- Уровень бизнес-архитектуры. Здесь отображаются бизнес-процессы, бизнес-роли, продукты и услуги, а также взаимосвязи между ними.
- Уровень архитектуры приложений. Позволяет визуализировать состав и структуру приложений, обеспечивающих достижение бизнес-целей и работу бизнес-пользователей.
- Уровень архитектуры технологий. На этом уровне находятся конечные объекты инфраструктуры, сервера, базы данных и так далее.
Рис.4 — Элементы нотации и пример диаграммы в нотации ArchiMate
Проектирование архитектуры ИС ー системный дизайн
Системный дизайн — процесс разработки и планирования архитектуры, компонентов, модулей и интерфейсов для создания программных, аппаратных или информационных систем.
Системный дизайн направлен на определение состава компонентов системы и то, как они будут взаимодействовать, какие технологии, приёмы и решения использовать, чтобы удовлетворить функциональные и нефункциональные требования.
В процессе системного дизайна можно выделить несколько основных этапов, на каждом из которых нужно спроектировать разные аспекты будущей ИС:
Системный дизайн направлен на определение состава компонентов системы и то, как они будут взаимодействовать, какие технологии, приёмы и решения использовать, чтобы удовлетворить функциональные и нефункциональные требования.
В процессе системного дизайна можно выделить несколько основных этапов, на каждом из которых нужно спроектировать разные аспекты будущей ИС:
- Понимание контекста.
- Проектирование структуры.
- Проектирование поведения.
Понимание контекста
На этом этапе необходимо определить требования и цели, выявить окружение будущей системы. Для моделирования и визуализации контекста ИС отлично подходит контекстная диаграмма нотации C4. Применение строгой нотации не обязательно, можно визуализировать схематически.
Рис.5 — Пример контекстной диаграммы C4
Проектирование структуры
При определении структуры компонентов можно отталкиваться от подхода к управлению требованиями «Распределение требований» (Requirements Allocation). Подход направлен на декомпозицию требований и распределение их по компонентам системы, которые будут эти требования обеспечивать. Это не структура конечной реализации, а абстрактные компоненты или модулях.
Рис.6 — Пример распределения требований по компонентам для интернет-магазина
В проектирование структуры ИС входят следующие этапы:
- Выбор архитектурного стиля и паттернов: монолит, микросервисы, слоистая архитектура, событийно-ориентированная архитектура (EDA).
- Декомпозиция системы на основные модули и компоненты для бэкенда и фронтенда. Показать структуру модулей и компонентов системы можно схематически без применения строгой нотации или с помощью диаграммы контейнеров нотации С4 (следующий уровень после диаграммы контекста).
Рис.7 — Пример диаграммы контейнеров нотации C4
Далее можно проектировать внутреннюю структуру каждого контейнера на диаграмме компонентов.
Рис.8 — Пример диаграммы компонентов нотации C4
3. Выбор технологий и инструментов: фреймворки, языки программирования, СУБД. Подробнее о факторах выбора рассказываем дальше.
4. Проектирование данных:
a. Моделирование структуры данных. Не забывайте о том, что данные могут храниться не только в табличном виде (реляционные БД), но и в в виде документов, графов и т. д. (нереляционные БД).
b. Выбор хранилища.
c. Безопасность и производительность.
d. Определение ETL-процессов (Extract, Transform, Load).
4. Проектирование данных:
a. Моделирование структуры данных. Не забывайте о том, что данные могут храниться не только в табличном виде (реляционные БД), но и в в виде документов, графов и т. д. (нереляционные БД).
b. Выбор хранилища.
c. Безопасность и производительность.
d. Определение ETL-процессов (Extract, Transform, Load).
Проектирование поведения
Требуемое поведение системы можно задокументировать в разных форматах:
■ диаграммы потоков данных (DFD);
■ диаграмма последовательности действия нотации UML (Sequence Diagram);
■ BPMN-диаграмма.
В проектирование поведения входят такие этапы:
1. Проектирование интеграционных потоков данных:
a. определение источников и приёмников данных;
b. выбор режима обработки (пакетная или потоковая);
c. выбор технологий и формат передачи данных;
d. определение процедур очистки и форматирования.
2. Определение интерфейсов и API для взаимодействия с внешними системами и компонентов внутри системы.
3. Планирование производительности и масштабирования: кэширование, балансировка нагрузки.
4. Планирование развёртывания, обновлений и поддержки. Подробнее об этих аспектах поговорим дальше.
■ диаграммы потоков данных (DFD);
■ диаграмма последовательности действия нотации UML (Sequence Diagram);
■ BPMN-диаграмма.
В проектирование поведения входят такие этапы:
1. Проектирование интеграционных потоков данных:
a. определение источников и приёмников данных;
b. выбор режима обработки (пакетная или потоковая);
c. выбор технологий и формат передачи данных;
d. определение процедур очистки и форматирования.
2. Определение интерфейсов и API для взаимодействия с внешними системами и компонентов внутри системы.
3. Планирование производительности и масштабирования: кэширование, балансировка нагрузки.
4. Планирование развёртывания, обновлений и поддержки. Подробнее об этих аспектах поговорим дальше.
Факторы принятия архитектурных решений
Давайте подробнее рассмотрим, на основе каких факторов принимать то или иное архитектурное решение в разрезе основных аспектов ИС.
Выбор архитектурного стиля API веб-приложения
Часто между проектировщиками стоит выбор: REST API или RPC API (к этому стилю относятся SOAP, GraphQL и gRPC). Подробно о разных интеграционных паттернах мы рассказывали в предыдущих статьях (ссылка, ссылка).
Кратко рассмотрим разницу между REST API и RPC API.
REST API реализует концепцию оперирования ресурсами. Ресурсом может выступать какая-то сущность системы (пользователь, заявка, товар и т. д.). Клиент обращается к серверу по HTTP и через глаголы (GET, POST, DELETE и т. д.) инициирует действие с ресурсом.
REST API обычно проектируется через OpenAPI-спецификации. В спецификации указываются:
■ запросы, которые можно сделать к ресурсам;
■ структура полезной нагрузки при обращении к ресурсу;
■ форматы ответов на запросы.
Принято использовать REST API для реализации принципа «Запрос-ответ» (Request-Response), то есть синхронного взаимодействия.
RPC API реализует концепцию обращения клиента к серверу так, как будто они находятся на одной машине. Клиент обращается не к ресурсу, а к функции сервера.
RPC API предоставляет широкий выбор способов взаимодействия клиента и сервера:
■ запрос-ответ;
■ потоковая передача данных от клиента;
■ потоковая передача данных от сервера;
■ двунаправленная потоковая передача данных.
Факторы, которые нужно учитывать при выборе архитектурного стиля API.
Кратко рассмотрим разницу между REST API и RPC API.
REST API реализует концепцию оперирования ресурсами. Ресурсом может выступать какая-то сущность системы (пользователь, заявка, товар и т. д.). Клиент обращается к серверу по HTTP и через глаголы (GET, POST, DELETE и т. д.) инициирует действие с ресурсом.
REST API обычно проектируется через OpenAPI-спецификации. В спецификации указываются:
■ запросы, которые можно сделать к ресурсам;
■ структура полезной нагрузки при обращении к ресурсу;
■ форматы ответов на запросы.
Принято использовать REST API для реализации принципа «Запрос-ответ» (Request-Response), то есть синхронного взаимодействия.
RPC API реализует концепцию обращения клиента к серверу так, как будто они находятся на одной машине. Клиент обращается не к ресурсу, а к функции сервера.
RPC API предоставляет широкий выбор способов взаимодействия клиента и сервера:
■ запрос-ответ;
■ потоковая передача данных от клиента;
■ потоковая передача данных от сервера;
■ двунаправленная потоковая передача данных.
Факторы, которые нужно учитывать при выборе архитектурного стиля API.
- Характер взаимодействия;
- Типизация сообщения — строгость схемы полезной нагрузки.
- Протокол передачи и формат сериализации данных.
- Транзакционность.
- Раскрытие информации клиенту о внутреннем устройстве сервера.
Выбор языка программирования
Языков программирования (ЯП) очень много. При выборе ЯП, на котором будут написаны компоненты вашей ИС, стоит учитывать такие факторы:
- Назначение разработки. Мы разрабатываем компонент для фронтовой или бэковой части ИС? Может быть для решения задачи нужен обширный математический аппарат?
- Производительность. Какие у нас требования к производительности ИС? Часто у низкоуровневых языков производительность выше, но выше и сложность разработки.
- Возможности масштабирования. Нужна ли поддержка распределённых или многопоточных вычислений «из коробки»?
- Основная парадигма. Функциональные, объектно-ориентированные, логические, структурные, декларативные и другие парадигмы могут быть реализованы в ЯП.
- Строгость типизации. Нужно ли нам, чтобы структуры данных и переменные имели строгие типы? Строгая типизация снижает вероятность возникновения ошибок при компиляции кода.
- Совместимость со средой. Совместим ли ЯП с различными операционными системами для создания кроссплатформенных приложений?
- Опыт команды.
Выбор фреймворка
Фреймворки — это наборы готовых инструментов, компонентов и методов разработки. Использование фреймворка упрощает и ускоряет разработку за счёт переиспользования: в фреймворке уже реализованы типовые задачи, такие как создание базовой структуры проекта, подключение к БД, авторизация, работа с API, логирование и многие другие. Так разработчик может сконцентрироваться на решении бизнес-задач и реализации бизнес-логики.
При выборе фреймворка необходимо опираться на следующие ключевые факторы:
При выборе фреймворка необходимо опираться на следующие ключевые факторы:
- Назначение разработки. Также как и при выборе ЯП — фреймворки ориентированы на решение какой-то задачи, например, разработки фронтенда или бэкенда, потоковой обработки данных или анализа больших данных.
- Производительность.
- Масштабирование за счёт распределённых вычислений или многопоточных вычислений.
- Поддержка языков. Какие Я П поддерживает фреймворк? Например, фреймворки Apache Spark и Apache Flink поддерживают сразу несколько ЯП: Java, Python, Scala.
- Встроенные механизмы безопасности.
- Опыт команды.
Выбор хранилища данных
Все системы в том или ином виде хранят данные. Поэтому выбор хранилища данных, а также его параметров — очень важный этап для обеспечения производительности будущей ИС. При выборе хранилища нужно учитывать эти факторы:
- Функциональные и нефункциональные требования к ИС.
- Основная и вторичная модели БД. Сегодня многие СУБД поддерживают не только основную модель, например, реляционную, но и имеют вторичные модели, например, реляционная PostgreSQL поддерживает работу с JSON- и XML-документами, а также графами с помощью расширения AEG.
- Поддержка ACID-транзакций. С помощью каких механизмов реализуется транзакционность?
- Поддержка ANSI-SQL. Поддерживается ли стандартный SQL, используется диалект SQL или реализован собственный язык запросов?
- Максимальный размер базы. Сколько база может хранить данных и в каких единицах.
- OLTP или OLAP? На какие сценарии использования ориентирована БД: транзакционные или аналитические?
- Поддерживаемые типы данных и размеры.
- Поддерживаемые языки программирования.
- Операционная система и необходимая инфраструктура.
- Поддержка JDBC или ODBC драйверов для доступа к БД.
- Поддержка триггеров, хранимых процедур, индексации.
- Поддержка партиционирования, шардирования, репликации.
- Поддержка масштабирования: горизонтальное или вертикальное.
Выбор способа развёртывания
Под развёртыванием понимается процесс размещения разработанного ПО в инфраструктурном контуре. То, как будет реализовано развёртывание, напрямую влияет на стоимость внедрения и сопровождения, производительность, безопасность вашей ИС. Способов развёртывания много:
- Развёртывание на физическом сервере (Bare Metal), то есть на мощностях реальных компьютеров.
- Развёртывание на виртуальной машине (Virtual Machine, VM). Виртуальные машины не существуют физически, они эмулируют вычислительную мощность программно.
- Развёртывание в контейнере (Docker, Kubernetes). Контейнеризация позволяет разместить код вместе с необходимыми файлами конфигурации, библиотеками, зависимостями и средой выполнения. Такой контейнер не зависит от особенностей среды, потому что может быть развёрнут в любой среде, где установлен контейнерный движок. Использование контейнера облегчает развёртывание и делает его более безопасным.
- Развёртывание на облачных платформах (Iaas, PaaS), когда вычислительные мощности расположены на облачных серверах провайдера облачной инфраструктуры.
- Бессерверное (Serverless) развёртывание. В этой концепции провайдер облачной инфраструктуры самостоятельно отвечает за настройку и обслуживание облачных серверов.
Рис.9 — Виды развертывания ПО
Нужно выбрать также платформу развёртывания:
■ облачные платформы (такие как AWS или Yandex Cloud), предоставляющие мощности под ключ;
■ виртуальные частные серверы (VPS), то есть аренда выделенных только для вас ресурсов на виртуальных машинах;
■ виртуальные хостинги;
■ локальные сервера.
При выборе способов и платформ развёртывания нужно учитывать такие факторы:
■ облачные платформы (такие как AWS или Yandex Cloud), предоставляющие мощности под ключ;
■ виртуальные частные серверы (VPS), то есть аренда выделенных только для вас ресурсов на виртуальных машинах;
■ виртуальные хостинги;
■ локальные сервера.
При выборе способов и платформ развёртывания нужно учитывать такие факторы:
- Требуемая производительность.
- Требования к масштабируемости.
- Поддерживаемые технологий.
- Необходимый уровень контроля и управления.
- В какой юрисдикции должна располагаться ИС.
- Модель ценообразования и итоговая стоимость.
Выбор стратегии развёртывания
Под стратегией развёртывания понимают порядок развёртывания приложения в окружении. Стратегия влияет на длительность развёртывания и возникновение простоев в бизнес-процессах.
Выбор стратегии в основном относится к DevOps, но тесно связан с проектированием. Архитектура должна учитывать как будут развёртываться компоненты приложения, чтобы развёртывание было беспроблемным.
Выбор стратегии в основном относится к DevOps, но тесно связан с проектированием. Архитектура должна учитывать как будут развёртываться компоненты приложения, чтобы развёртывание было беспроблемным.
Рис.10 — Виды стратегий развертывания
Кратко о видах стратегий:
■ влияние развёртывания на бизнес: важно ли как новая функциональность будет поставляться пользователям (поэтапно или всем сразу);
■ длительность и стоимость возможного простоя;
■ обратная связь о новой версии от пользователей: нужна ли она и в каком объёме, чтобы развернуть новую версию для всех?
■ сложность и длительность процесса развёртывания;
■ транзакционность и возможность откатить изменения;
■ инфраструктурные ограничения и возможности автоматизации развёртывания;
■ размер и структура команды разработки.
- Big Bang Deployment. Новая версия приложения развёртывается единомоментно на всех серверах. В этой стратегии возникает простой серверов при развёртывании. Если произошел сбой — откат к предыдущей версии.
- Rolling Deployment (скользящее развёртывание). Серверы обновляются друг за другом поэтапно.
- Blue-Green Deployment (сине-зеленое развёртывание). Сразу два экземпляра приложения (синяя и зеленая) разворачиваются параллельно. Одна версия доступна пользователям, а другая — тестируется. После успешного тестирования версия переключается. Эта стратегия минимизирует простои.
- Canary Deployment (канареечное развёртывание). Стратегия похожа на сине-зеленую с отличием: при канареечном развёртывании переключение происходит постепенно для частей пользователей.
- Feature Toggle. Стратегия использует «включение» функциональности для части пользователей через проставление флагов в коде. Стратегия позволяет сформировать несколько версий приложения через одну кодовую базу.
■ влияние развёртывания на бизнес: важно ли как новая функциональность будет поставляться пользователям (поэтапно или всем сразу);
■ длительность и стоимость возможного простоя;
■ обратная связь о новой версии от пользователей: нужна ли она и в каком объёме, чтобы развернуть новую версию для всех?
■ сложность и длительность процесса развёртывания;
■ транзакционность и возможность откатить изменения;
■ инфраструктурные ограничения и возможности автоматизации развёртывания;
■ размер и структура команды разработки.
Выбор решения для мониторинга и алертинга
Важная составляющая эксплуатации системы — мониторинг её функционирования и оповещение заинтересованных лиц о возникающих проблемах (алертинг).
При выборе решений мониторинга и алертинга обращайте внимание на:
■ состав метрик, которые нужно отслеживать и их источники (важно отслеживать и системные метрики и бизнесовые);
■ периодичность сбора метрик;
■ критичные пороговые значения;
■ состав заинтересованных лиц, которых нужно уведомить при достижении пороговых значений;
■ каналы алертинга: каким образом отправлять уведомления о проблемах;
■ сложность подключения к системе мониторинга и алертинга;
■ стоимость эксплуатации мониторинга и алертинга.
При выборе решений мониторинга и алертинга обращайте внимание на:
■ состав метрик, которые нужно отслеживать и их источники (важно отслеживать и системные метрики и бизнесовые);
■ периодичность сбора метрик;
■ критичные пороговые значения;
■ состав заинтересованных лиц, которых нужно уведомить при достижении пороговых значений;
■ каналы алертинга: каким образом отправлять уведомления о проблемах;
■ сложность подключения к системе мониторинга и алертинга;
■ стоимость эксплуатации мониторинга и алертинга.
Ключевые факторы принятия архитектурных решений
На принятие архитектурных решений на уровне компонентов системы влияют общие факторы.
- Функциональные и нефункциональные требования с учётом их приоритетов. Особенно важны требования к показателям качества: производительности, безопасности, масштабирования.
- Возможности и ограничения компонента.
- Корпоративные стандарты: договорённости внутри организации об использовании различных подходов и инструментов.
- Совместимость с окружением.
- Схема лицензирования используемых инструментов, фреймворков, библиотек.
- Компетенции и опыт команды.
- Бюджеты и стоимость эксплуатации.
- Назначение разработки системы: для чего и кого мы её делаем, как она будет развиваться, какую ценность должна приносить.
- Контекст внедрения: окружающий ИТ-ландшафт, интеграции с внешними ИС, совместимость с технической и бизнес средами.
- Бизнес-архитектура: оргструктура предприятия, продукты и направления деятельности организации.
Участники, инструменты и артефакты проектирования
Участники
Кто влияет на процесс архитектурного проектирования?
- Бизнес-пользователи. Выдают требования, ограничения и пожелания.
- Команда разработки. Имеют определённый опыт, возможности и компетенции.
- Инфраструктура: администраторы и DevOps.
- Держатели бюджета. Накладывают ограничения по стоимости.
- Регуляторы. Накладывают ограничения со стороны законодательства.
Рис.11 — Участники процесса архитектурного проектирования
Задача архитектора — собрать информацию от всех участников процесса и принять архитектурные решения.
Артефакты
В каждой компании свой набор артефактов архитектурного проектирования, но в большинстве случаев это:
■ технологический радар, техрадар (technology radar);
■ каталог архитектурных стандартов и шаблонов;
■ реестр архитектурных решений (ADR, Architectural Decision Records);
■ архитектурный проект (ADD, Architecture Design Document)
Рассмотрим их подробнее.
■ технологический радар, техрадар (technology radar);
■ каталог архитектурных стандартов и шаблонов;
■ реестр архитектурных решений (ADR, Architectural Decision Records);
■ архитектурный проект (ADD, Architecture Design Document)
Рассмотрим их подробнее.
Техрадар
Технологический радар, техрадар (technology radar) — обзор технологий, инструментов и подходов, используемых в проекте или компании по категориям использования. Обычно составляют общий техрадар для всей организации.
Техрадар разделён на категории:
■ ADOPT — то, что активно внедряется;
■ TRIAL — то, что протестировано и готово к работе в проде;
■ ASSESS — то, что сейчас исследуется и тестируется;
■ HOLD — то, что используется для поддержки существующих систем, но для новых не используется.
Техрадар при выборе архитектурного решения помогает понять, по каким инструментам и технологиям есть экспертиза, какие активно внедряются, а какие — уже не стоит применять в новых проектах.
Техрадар разделён на категории:
■ ADOPT — то, что активно внедряется;
■ TRIAL — то, что протестировано и готово к работе в проде;
■ ASSESS — то, что сейчас исследуется и тестируется;
■ HOLD — то, что используется для поддержки существующих систем, но для новых не используется.
Техрадар при выборе архитектурного решения помогает понять, по каким инструментам и технологиям есть экспертиза, какие активно внедряются, а какие — уже не стоит применять в новых проектах.
Рис.12 — Пример техрадара
Каталог архитектурных стандартов
Каталог архитектурных стандартов и шаблонов — описания корпоративный стандартов, практик и архитектурных шаблонов, примеры реализации и рекомендации к применению.
Реестр архитектурных решений
Реестр архитектурных решений (ADR, Architectural Decision Records) —архитектурные решения, принятые в ходе разработки, с указанием критериев выбора, альтернатив, итогового выбора и последствий.
Для составления ADR не существует строгих правил, в каждой компании может вестись в своём виде.
Для составления ADR не существует строгих правил, в каждой компании может вестись в своём виде.
Рис.13 — Пример ADR
Архитектурный проект
Архитектурный проект (ADD, Architecture Design Document) — концепция и цели архитектуры проектируемой ИС, основные принципы и ограничения, требования к архитектуре, архитектурные диаграммы, технологический стек.
Техники и инструменты проектирования
Какими техниками и инструментами может пользоваться архитектор при проектировании:
Архитектура и риски
Анализ рисков — важная часть проектирования архитектуры ИС. Выбор любого архитектурного решения может нести возможные риски, которые нужно учитывать.
Примеры архитектурных рисков:
Примеры архитектурных рисков:
С точки зрения модели безопасности, у любой системы есть уязвимости, как внешние, так и внутренние. Это также создаёт риски в области информационной безопасности (ИБ).
Рис.14 — Модель безопасности
Поэтому при проектировании всегда нужно задаваться вопросами:
■ какие угрозы существуют для ИС?
■ какие уязвимости есть у ИС?
■ каковы риски?
■ какие последствия рисков?
■ как можно смягчить возможные риски?
Есть ряд типовых рисков ИБ и контрмер к ним.
■ какие угрозы существуют для ИС?
■ какие уязвимости есть у ИС?
■ каковы риски?
■ какие последствия рисков?
■ как можно смягчить возможные риски?
Есть ряд типовых рисков ИБ и контрмер к ним.
Компромиссы поиска архитектурного решения
Мы разобрали много разных аспектов, которые нужно учесть при проектировании архитектуры ИС. Кажется, можно выделить признаки идеальной архитектуры:
■ решает все задачи;
■ удовлетворяет всем требованиям и ограничениям;
■ идеально вписывается в контекст и окружающую среду;
■ отлично управляется, расширяется и масштабируется;
■ стоит недорого;
■ знакома команде разработки.
Нужно признать, что идеальной архитектуры, которую никогда не пришлось бы исправлять и менять, не существует. Поэтому архитектор часто стоит перед выбором.
Быстро сделать «костыльное» решение или потратить время на проектирование?
Написать полноценный бэкенд или быстро написать «хранимки» в БД? Спроектировать монолитную систему или сделать кучу микросервисов? Производительный, но не очень безопасный REST API или безопасный, но более медленный RPC API?
Поиск архитектурного решения — это всегда компромисс!
И не стоит забывать, что архитектура ИС тесно связана с архитектурой бизнеса. Изменения в бизнесе неизбежно приведут к необходимости менять архитектуру ИС. А также:
■ меняется внешний контекст: политические события, изменения в законодательстве;
■ требования меняются, невозможно предусмотреть все возможные изменения заранее;
■ технологии устаревают;
■ случаются рисковые события: риски при разработке есть всегда, некоторые из них могут случаться внезапно и неожиданно.
Поэтому не стремитесь к идеальной архитектуре, стремитесь к архитектуре, минимально и достаточно подходящей под требования, ограничения и возможности!
■ решает все задачи;
■ удовлетворяет всем требованиям и ограничениям;
■ идеально вписывается в контекст и окружающую среду;
■ отлично управляется, расширяется и масштабируется;
■ стоит недорого;
■ знакома команде разработки.
Нужно признать, что идеальной архитектуры, которую никогда не пришлось бы исправлять и менять, не существует. Поэтому архитектор часто стоит перед выбором.
Быстро сделать «костыльное» решение или потратить время на проектирование?
Написать полноценный бэкенд или быстро написать «хранимки» в БД? Спроектировать монолитную систему или сделать кучу микросервисов? Производительный, но не очень безопасный REST API или безопасный, но более медленный RPC API?
Поиск архитектурного решения — это всегда компромисс!
И не стоит забывать, что архитектура ИС тесно связана с архитектурой бизнеса. Изменения в бизнесе неизбежно приведут к необходимости менять архитектуру ИС. А также:
■ меняется внешний контекст: политические события, изменения в законодательстве;
■ требования меняются, невозможно предусмотреть все возможные изменения заранее;
■ технологии устаревают;
■ случаются рисковые события: риски при разработке есть всегда, некоторые из них могут случаться внезапно и неожиданно.
Поэтому не стремитесь к идеальной архитектуре, стремитесь к архитектуре, минимально и достаточно подходящей под требования, ограничения и возможности!
Шаги проектирования архитектуры ИС
Итак, в какой последовательности действовать, чтобы спроектировать архитектуру ИС и ничего не забыть:
- Осознание назначения разработки системы.
- Анализ ФТ и НФТ (производительность, масштабируемость, расширяемость, безопасность, надежность, стандартизация, стоимость).
- Анализ контекста: внешняя среда, интеграции с другими ИС, пользователи.
- Определение ограничений: домен, компания, техрадар, команда, внешние ИС.
- Осознание границ применения: POC, MVP, промышленный продукт.
- Выбор архитектурного стиля и паттернов проектирования.
- Декомпозиция ИС по компонентам, обеспечивающим ФТ и НФТ.
- Проектирование данных: модели данных, технологии хранения, ETL/ELT-процессы.
- Выбор компонентов мониторинга и алертинга.
- Определение стратегии тестирования и развертывания.
- Поиск альтернативных вариантов реализации компонентов структуры и их взаимодействия.
- Определение критериев выбора альтернативных вариантов.
- Сравнение вариантов, анализ рисков, обсуждение с командой.
- Фиксация выбранного варианта и текстека в ADR.
- Разработка техпроекта.
Резюме
- Архитектура ИС — это составная часть многослойной архитектуры предприятия. Поэтому решения на разных уровнях могут влиять на принятие решений по архитектуре ИС.
- Проектирование архитектуры — комплексный процесс, который должен учитывать самые разные аспекты будущей ИС. Архитектура — это не только состав микросервисов, но и хранение данных, внешние ограничения, сервисы для развёртывания и мониторинга, учёт опыта команды и многое другое.
- На выбор архитектурных решений влияет множество факторов. Все они важны в комплексе. При этом важно учитывать не только ФТ и НФТ, но и корпоративные стандарты, стоимость эксплуатации, опыт команды разработки и многое другое.
- В процессе архитектурного проектирования много заинтересованных лиц. Задача архитектора — собрать и учесть накладываемые ими ограничения для принятия архитектурных решений.
- Идеальной архитектуры не существует, поиск архитектурного решения — это всегда компромисс.
Ответы на вопросы
- Вопрос:Можно ли отождествлять архитектуру ИС и корпоративную архитектуру?Ответ:Это не одно и то же, но корпоративная архитектура и архитектура ИС неразрывно связаны и являются частью всей архитектуры организации. Корпоративная архитектура так или иначе будет влиять на архитектурные решения во всех ИС, архитектура ИС не может идти вразрез с корп. архитектурой.
- Вопрос:Почему выбор ЯП и фреймворков разработки — часть архитектурного проектирования?Ответ:Потому что ЯП и фреймворки нельзя игнорировать при проработке архитектурного решения. Любые выбираемые технологии, инструменты, ЯП, фреймворки, библиотеки должны как минимум соответствовать техрадару компании. Необязательно принимать такие решение должен архитектор ИС, все это может выбрать команда разработки, но выбор должен быть зафиксирован как часть архитектурного решения.
- Вопрос:Почему вы считаете, что выбор технологий зависит от команды, а не наоборот, команда подбирается под технологии?Ответ:Знания и компетенции команды учитываются, но это не единственный критерий выбора. При необходимости команда может быть собрана заново или расширена.
- Вопрос:Как проектирование согласуется с гибкими методологиями? Пока все спроектируем и согласуем, конкуренты могут занять нишу.Ответ:Если ваша задача — выпустить MVP и подтвердить гипотезу, не обязательно писать многотомные техпроект со всеми деталями. Но зафиксировать ключевые решения, используемые технология и ограничения нужно. Это позволит при развитии системы не забыть, что и для чего было сделано.
- Вопрос:С чего начать изучение проектирования архитектуры БА и СА?Ответ:С изучения системного анализа, системного проектирования на уровне технических заданий.
- Вопрос:Может ли СА стать архитектором?Ответ:Опыт СА безусловно полезен в контексте насмотренности, умения структурировать информацию и работать с требованиями. Но для архитектора крайне важно иметь хотя бы минимальный опыт в разработке, быть глубоко технически погруженным.
