Проектирование архитектуры информационных систем

1.3 Основные виды архитектуры информационной системы

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

1.3.1 Функциональная архитектура

Функциональная архитектура описывает функции, которые должна выполнять система, и отношения между этими функциями. Она отвечает прежде всего на вопрос: что должна делать система? На данном уровне внимание сосредоточено не на конкретных программах, серверах или базах данных, а на задачах, операциях, процессах и результатах деятельности. Функциональная архитектура формируется на основе целей организации и требований пользователей. Сначала определяется общая функция системы, затем она последовательно разделяется на подфункции. Такой процесс называется функциональной декомпозицией. Например, общей функцией информационной системы интернет-магазина является обеспечение электронной продажи товаров. Эта функция может быть разделена на управление каталогом, поиск товаров, управление корзиной, оформление заказа, прием оплаты, управление складскими остатками, организацию доставки, возврат товаров и формирование аналитической отчетности. Функция «оформление заказа» может быть дополнительно разделена на идентификацию покупателя, проверку содержимого корзины, расчет стоимости, выбор способа доставки, выбор способа оплаты, подтверждение заказа и формирование уведомления. Каждая функция получает определенные входные данные, выполняет преобразование и формирует выходной результат. Функциональная архитектура может описывать функции разного уровня. Стратегические функции связаны с достижением целей организации. Управленческие функции обеспечивают планирование, контроль и принятие решений. Основные функции создают ценность для клиентов или пользователей. Обеспечивающие функции поддерживают деятельность системы, например управление пользователями, аудит, резервное копирование и мониторинг. Функциональное представление важно потому, что оно позволяет отделить потребности бизнеса от способов технической реализации. Одна и та же функция может быть реализована различными технологиями. Например, функция уведомления клиента может выполняться посредством электронной почты, SMS, мобильного уведомления или сообщения в личном кабинете. Функциональная архитектура фиксирует необходимость уведомления, а конкретные каналы определяются на последующих уровнях проектирования. При разработке функциональной архитектуры используются модели бизнес-процессов, диаграммы потоков данных, диаграммы вариантов использования, функциональные модели и другие средства. Важным результатом является определение границ системы: какие функции выполняются самой системой, какие остаются за человеком, а какие передаются внешним системам. Например, информационная система медицинской клиники может регистрировать пациента, хранить историю обращений, планировать прием, передавать результаты анализов и формировать счета. Однако постановка диагноза остается функцией врача, хотя система может предоставлять ему аналитическую поддержку. Функциональная архитектура должна обеспечивать полноту и непротиворечивость функций. Необходимо исключить ситуации, когда важная функция не учтена или одна функция необоснованно дублируется в нескольких подсистемах. Также следует определить зависимости между функциями, последовательность их выполнения и общие правила обработки исключительных ситуаций.

1.3.2 Системная архитектура

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

1.3.3 Информационная архитектура

Информационная архитектура описывает информационное содержание системы, информационные потоки, источники и получателей информации, способы представления информации и правила ее использования. Она отвечает на вопросы: какая информация необходима системе, откуда она поступает, каким образом преобразуется, кому передается и в какой форме представляется? Информационная архитектура шире архитектуры данных. Архитектура данных преимущественно сосредоточена на моделях, структурах, хранилищах и технологиях управления данными. Информационная архитектура также учитывает смысл информации, ее связь с деятельностью пользователей, документы, сообщения, отчеты, информационные потоки и способы навигации. Например, в системе университета используются данные о студентах, преподавателях, дисциплинах, учебных планах, расписании, посещаемости и оценках. Однако информационная архитектура рассматривает не только таблицы базы данных. Она определяет, какие сведения требуются деканату, преподавателю, студенту, бухгалтерии и руководству; какие отчеты формируются; как информация передается между подразделениями; кто имеет право изменять данные; какие документы являются официальными. Информационная архитектура включает понятия информационного объекта, информационного потока, источника информации, получателя информации, жизненного цикла информации и правил доступа. Информационный объект представляет собой осмысленную единицу информации, используемую в деятельности. Это может быть заказ, договор, счет, медицинская карта, заявление, учебный план, отчет или электронное сообщение. Информационный поток представляет собой движение информации между участниками, процессами или системами. Например, заявка клиента поступает в систему, передается на проверку, затем направляется исполнителю, после чего информация о результате возвращается клиенту. Жизненный цикл информации включает создание, регистрацию, проверку, использование, изменение, архивирование и удаление. Для каждого этапа могут действовать различные правила. Например, черновик документа может свободно изменяться автором, утвержденный документ должен быть защищен от несанкционированного редактирования, а архивный документ хранится установленный срок. Информационная архитектура должна обеспечивать логичность, понятность и непротиворечивость информационной среды. Пользователь должен понимать, где найти нужную информацию, как она организована и насколько ей можно доверять. В веб-системах понятие информационной архитектуры часто связывают со структурой разделов, навигацией, классификацией контента и поиском. Например, информационная архитектура интернет-магазина определяет категории и подкатегории товаров, фильтры, карточки товаров, структуру каталога и связи между объектами. Ошибки в такой архитектуре могут привести к тому, что пользователь не сможет найти нужный товар даже при наличии корректной программной реализации.

1.3.4 Архитектура данных

Архитектура данных определяет принципы организации, хранения, обработки, интеграции, защиты и управления данными. Она отвечает на вопросы: какие данные существуют в системе, как они структурированы, где хранятся, каким образом связаны, кто отвечает за их качество и как обеспечивается их доступность? Данные являются одним из наиболее устойчивых активов информационной системы. Программы и технологии могут изменяться, но накопленные данные часто должны сохраняться десятилетиями. Поэтому ошибки в архитектуре данных имеют длительные последствия. Архитектура данных включает концептуальные, логические и физические модели данных. Концептуальная модель данных отражает основные сущности предметной области и связи между ними без привязки к конкретной технологии. Например, для университета такими сущностями могут быть студент, преподаватель, дисциплина, учебная группа, занятие и оценка. Логическая модель данных уточняет атрибуты сущностей, ключи, связи и ограничения. На этом уровне определяется, что студент имеет идентификатор, фамилию, имя, дату рождения, статус обучения и связан с учебной группой. Физическая модель данных описывает реализацию в конкретной системе управления базами данных. Определяются таблицы, столбцы, типы данных, индексы, ограничения, способы распределения и хранения. Архитектура данных определяет выбор типов хранилищ. Реляционные базы данных организуют данные в виде таблиц и обеспечивают строгие связи и транзакции. Они хорошо подходят для финансовых, учетных и операционных систем. Документные базы данных хранят данные в виде документов и удобны для объектов с изменяющейся структурой. Графовые базы данных предназначены для хранения сложных сетей связей, например социальных отношений, маршрутов или зависимостей. Ключ-значение хранилища обеспечивают быстрый доступ по ключу и часто используются для кэширования. Колонночные хранилища эффективны для аналитической обработки больших объемов данных. В одной информационной системе могут использоваться разные типы хранилищ. Такой подход называется полиглотным хранением данных. Например, интернет-магазин может использовать реляционную базу для заказов и платежей, поисковый индекс для каталога, ключ-значение хранилище для пользовательских сессий и аналитическое хранилище для отчетности. Архитектура данных также определяет подход к централизации и распределению. В централизованной модели данные хранятся в единой базе. Это упрощает обеспечение согласованности, но может создавать ограничения масштабирования и зависимость от одного хранилища. В распределенной модели данные размещаются в нескольких базах или узлах. Это может повышать производительность и отказоустойчивость, но усложняет синхронизацию и контроль целостности. Одной из ключевых проблем является согласованность данных. Если одна и та же информация хранится в нескольких местах, изменения должны корректно распространяться между ними. Например, изменение адреса клиента должно быть учтено в системе заказов, системе доставки и системе взаимоотношений с клиентами. Архитектура данных должна определять источник достоверных данных, или систему, которая считается официальным владельцем определенного вида информации. Например, сведения о сотрудниках могут официально храниться в кадровой системе, а данные о платежах — в финансовой системе. Важным понятием является качество данных. Качественные данные должны быть точными, полными, актуальными, непротиворечивыми, уникальными и пригодными для использования. Низкое качество данных приводит к ошибкам в отчетах, неправильным решениям и сбоям процессов. Архитектура данных включает механизмы управления метаданными. Метаданные — это данные о данных. Они описывают происхождение, структуру, смысл, формат, владельца и правила использования данных. Например, метаданные могут указывать, что поле «дата регистрации» содержит дату первого создания учетной записи и заполняется автоматически. Также архитектура данных охватывает вопросы безопасности. Необходимо определить классификацию данных, права доступа, шифрование, резервное копирование, архивирование и удаление. Особое внимание уделяется персональным, медицинским, финансовым и коммерчески значимым данным.

1.3.5 Программная архитектура

Программная архитектура описывает фундаментальную структуру программного обеспечения, его основные компоненты, интерфейсы, зависимости и способы взаимодействия. Она отвечает на вопрос: из каких программных элементов состоит система и как они совместно выполняют функции? Программная архитектура находится между требованиями и программным кодом. Она представляет систему на более высоком уровне абстракции, чем отдельные классы, функции или строки кода. К элементам программной архитектуры относятся приложения, модули, компоненты, сервисы, библиотеки, интерфейсы, базы данных, очереди сообщений, внешние API и механизмы интеграции. Программная архитектура может описываться на нескольких уровнях. На уровне системы определяются крупные приложения и сервисы. На уровне приложения выделяются модули и компоненты. На более детальном уровне описываются классы, интерфейсы и зависимости. Например, программная архитектура интернет-магазина может включать веб-интерфейс, мобильное приложение, серверную часть, модуль аутентификации, каталог, корзину, управление заказами, платежный модуль, модуль доставки, базу данных и систему уведомлений. Программная архитектура определяет способы взаимодействия компонентов. Взаимодействие может происходить через вызовы функций, API, обмен сообщениями, события, общие базы данных или файлы. Одним из важных свойств является связанность. Высокая связанность означает, что компоненты сильно зависят друг от друга. Изменение одного компонента может потребовать изменения многих других. Низкая связанность позволяет изменять компоненты более независимо. Другим свойством является сцепление, или внутренняя согласованность компонента. Хорошо спроектированный компонент объединяет функции, относящиеся к одной ответственности. Если в одном модуле смешаны обработка платежей, управление пользователями, формирование отчетов и отправка писем, такой модуль обладает низкой внутренней целостностью. Принцип высокой внутренней связности и низкой внешней связанности считается одним из базовых принципов программной архитектуры. Компонент должен отвечать за логически связанную область, но минимально зависеть от других компонентов. Программная архитектура влияет на возможность тестирования, сопровождения и развития системы. Если компоненты четко разделены и взаимодействуют через стабильные интерфейсы, разработчики могут изменять отдельные части без полной переработки системы.

1.3.6 Взаимосвязь различных видов архитектуры

Функциональная, системная, информационная, программная архитектура и архитектура данных не существуют изолированно. Они описывают одну систему с разных позиций и должны быть согласованы. Функциональная архитектура определяет, какие функции необходимы. Программная архитектура показывает, какие программные компоненты реализуют эти функции. Архитектура данных определяет, какие данные необходимы компонентам. Информационная архитектура показывает движение и использование информации. Системная архитектура объединяет программные, технические и организационные элементы. Например, функция «оформить заказ» может быть реализована программным компонентом управления заказами. Компонент использует данные о клиенте, товарах, цене и доставке. Информация поступает из пользовательского интерфейса и внешних сервисов. Компонент развернут на определенном сервере и взаимодействует с базой данных и платежной системой. Все эти аспекты должны быть согласованы. Если функциональная архитектура предусматривает обработку большого количества заказов, а системная архитектура предполагает один маломощный сервер, возникает несоответствие. Если программная архитектура разделяет систему на независимые сервисы, а архитектура данных требует постоянного совместного доступа к одной сложной структуре, также могут возникнуть проблемы. Поэтому проектирование архитектуры представляет собой итеративный процесс согласования различных представлений.

1.4 Монолитная архитектура

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

1.5 Микросервисная архитектура

Микросервисная архитектура представляет собой архитектурный подход, при котором система разделяется на набор небольших автономных сервисов. Каждый сервис реализует определенную бизнес-возможность, имеет четкую ответственность и взаимодействует с другими сервисами через сетевые интерфейсы. Например, интернет-магазин может быть разделен на сервис каталога, сервис заказов, сервис пользователей, сервис платежей, сервис склада, сервис доставки и сервис уведомлений. Каждый микросервис может иметь собственный программный код, собственную базу данных, отдельный цикл разработки и отдельное развертывание. Команда может изменять и выпускать сервис независимо от остальных, если сохраняется совместимость интерфейсов. Ключевой принцип микросервисной архитектуры заключается в разделении по бизнес-возможностям, а не только по техническим слоям. Например, сервис заказов должен включать логику, связанную с заказами, а не представлять собой общий слой доступа к данным для всей системы. Другим важным принципом является автономность сервисов. Сервис должен обладать достаточной самостоятельностью и минимально зависеть от внутренних деталей других сервисов. В микросервисной архитектуре взаимодействие происходит через сеть. Для синхронного взаимодействия могут использоваться HTTP API, REST, gRPC и другие протоколы. Для асинхронного взаимодействия используются очереди сообщений и события. Например, после создания заказа сервис заказов может опубликовать событие «Заказ создан». Сервис склада уменьшит остатки, сервис уведомлений отправит сообщение клиенту, а аналитическая система зарегистрирует событие для отчетности. Преимуществом микросервисов является независимое развертывание. Изменение сервиса уведомлений не требует обязательного развертывания сервиса заказов или каталога. Микросервисы позволяют независимо масштабировать части системы. Если сервис поиска испытывает высокую нагрузку, можно увеличить только число его экземпляров. Разные сервисы могут использовать различные технологии и типы баз данных, если это оправдано задачами. Например, сервис заказов может использовать реляционную базу данных, а сервис рекомендаций — графовое или аналитическое хранилище. Микросервисная архитектура также позволяет распределить ответственность между командами. Каждая команда может владеть определенной группой сервисов и отвечать за их разработку, тестирование и эксплуатацию. Отказ одного сервиса не обязательно приводит к полному отказу системы. Например, при временной недоступности сервиса рекомендаций интернет-магазин может продолжать оформлять заказы без персональных предложений. Однако такая устойчивость возникает только при специально спроектированной обработке отказов. Микросервисная архитектура имеет и существенные недостатки. Основной проблемой является распределенная сложность. Взаимодействие по сети менее надежно, чем вызов функции внутри одного процесса. Запрос может задержаться, потеряться, выполниться несколько раз или завершиться частично. Необходимо учитывать сетевые задержки, тайм-ауты, повторные попытки, балансировку нагрузки, обнаружение сервисов, версионирование API и защиту каналов связи. Сложнее обеспечить целостность данных. В монолите операция может выполняться в рамках одной транзакции базы данных. В микросервисной системе данные распределены между несколькими сервисами, и единая транзакция может быть невозможна или нежелательна. Например, оформление заказа включает резервирование товара, списание средств и создание доставки. Если платеж выполнен, но резервирование товара завершилось ошибкой, система должна корректно обработать частичный результат. Для этого используются распределенные процессы, компенсационные операции и шаблоны типа Saga. Возрастает сложность тестирования. Необходимо проверять отдельные сервисы, их интерфейсы, совместимость версий и совместное поведение системы. Эксплуатация требует развитой инфраструктуры. Необходимы автоматическое развертывание, централизованное журналирование, мониторинг, трассировка запросов, управление конфигурациями, контейнеризация и оркестрация. Большое количество сервисов увеличивает число сетевых соединений, журналов, версий и точек отказа. Без зрелых инженерных процессов микросервисная архитектура может оказаться значительно сложнее монолита. Особенно опасно создавать чрезмерно мелкие сервисы. Если каждое простое действие требует последовательного обращения к множеству сервисов, производительность снижается, а система становится трудноуправляемой. Размер микросервиса определяется не количеством строк кода, а целостностью его бизнес-ответственности и возможностью независимого изменения.