Содержание курса

• Понятие «Архитектура»

• Бизнес-архитектура

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

• Архитектура прикладных решений. Область разработки прикладных систем.

• Архитектура прикладных решений. Портфель прикладных систем

• Технологическая Архитектура

• Подходы к построению Архитектуры

• Графический язык моделирования ArchiMate

• Архитекторы

В предыдущей части мы обсудили общие аспекты ИТ Архитектуры, и подробно затронули такой ее слой, как архитектура Данных, которая охватывает все многообразие бизнес-информации предприятия, знания о потоках ее распределения, сборе, обработке и использовании, представляемой в виде различных моделей данных.

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

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

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

Потому для упрощения восприятия, как правило, разделяют две основные области ее применимости:

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

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

4.1. Область разработки прикладных систем.

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

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

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

• обеспечения высокого качества ИТ- продукта;

• повышения стабильности и управляемости процессами его реализации;

• уменьшения стоимости производства.

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

Для обеспечения высокого качества самого ИТ-продукта, важно всесторонне рассмотреть и описать автоматизируемую предметную область. Потому необходимо комбинировать различные архитектурные представления: поведенческое или динамическое, структурное или статическое, логическое соответствие функциональным требованиям, физическое, например, гео-распределенность реализации, в частности, как детали архитектуры представляются в коде и т.п.

Поэтому Прикладной срез области разработки чаще всего принято представлять в виде следующих схем:

• статическая структурная модель, которая отображает подсистемы или компоненты и их взаимосвязи, разрабатываемые независимо на разных этапах;

• динамическая модель исполнения, представляющая организацию процессов во время функционирования системы;

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

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

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

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

• инструменты для проектирования и производства Программных продуктов;

• стандарты, регламентирующие процесс производства и набор применяемых для этого средств;

• структура цикла разработки и контроля версий;

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

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

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

Шаблоны представляют собой руководства по быстрому построению хорошо работающих систем в определенном контексте, с заданным уровнем качества. Так же благодаря повсеместному распространению они понятны широкому кругу исполнителей и упрощают взаимодействие в команде. Примеры архитектурных паттернов мы обсудим в ходе рассмотрения этой темы.

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

В качестве компонентов ИС описывают технологическую часть архитектуры прикладных решений и чаще всего включают:

• программные продукты;

• модели данных;

• интерфейсы (API);

• пользовательские интерфейсы.

С другой стороны, как и прочие слои архитектуры прикладные решения по уровням абстракции так же делятся по тесситуре. Чаще всего выделяют три основные домена:

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

• Бизнес-уровень. Правила, алгоритмы реакции приложения на действия пользователя или на внутренние события, правила обработки данных.

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

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

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

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

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

Используя «хорошую компонентную архитектуру», можно обеспечить следующие преимущества целевой системы:

• Масштабируемость - возможность расширять систему и увеличивать ее производительность, за счет добавления новых модулей / подсистем.

• Ремонтопригодность - изменение одного модуля / подсистемы не требует изменения других подсистем.

• Заменимость модулей - программный модуль легко заменить на другой.

• Возможность тестирования - программный модуль можно отсоединить от всех остальных и протестировать / починить.

• Переиспользование - подсистемы, могут быть, переиспользованы в других программах и другом окружении.

• Сопровождаемость - части системы, описанные в архитектуре приложений легче понимать, сопровождать и отчуждать.

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

4.1.1. Архитектурные стили

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

Компонентно-ориентированный архитектурный стиль - подчеркивает разделение функциональности на различные слои в рамках программной системы.

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

Принципы: Этот стиль архитектуры организует систему в виде слабосвязанных, повторно используемых компонентов.

Преимущества: Высокий уровень повторного использования, гибкости и поддерживаемости.

Недостатки: Сложность управления компонентами и их взаимодействиями.

Применение: Веб-приложения, десктоп-приложения, распределённые системы.

Примерами аргументов разделения и компоновки на модули /подсистемы могут являться:

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

2. усиление мощности, когда различные узлы должны работать над одной задачей так, чтобы система, содержащая набор процессоров, по мощности могла приближаться к суперкомпьютеру;

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

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

5. специализация компонентов, при которой происходит их упрощение и удешевление.

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

В подобных случаях обычно используют паттерн “Микроядро”, который отделяет минимальное функциональное ядро от расширенных функций и частей, специфичных для клиента. Микроядро содержит основную функциональность, в то время как другие функции реализуются в виде плагинов для микроядра. Это позволяет легко расширять систему без изменения основного кода.

Преимущества: Гибкость, масштабируемость, повторное использование и слабая связанность.

Недостатки: Повышенная сложность, зависимость от сети и возможные проблемы с производительностью.

Применение: Корпоративные системы, веб-сервисы, микросервисы.

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

Примером сервисно-ориентированного стиля, может служить применение паттерна “Микросервисы”, организующего приложение в виде набора небольших сервисов, каждый из которых работает в своём процессе и общается с помощью легковесных механизмов, часто при помощи простых сетевых протоколов.

Эти сервисы ориентированы на бизнес-возможности и могут быть независимо развёрнуты с помощью полностью автоматизированного механизма развёртывания. Этот паттерн позволяет быстро, часто и надёжно доставлять сложные приложения.

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

Архитектурный стиль параллелизма (Concurrency). Паралелилизм — это свойство системы, в которой несколько независимых задач выполняются одновременно.

Принципы: Различные части программы выполняются независимо, потенциально одновременно.

Преимущества: Может значительно улучшить производительность, особенно на многопроцессорных системах.

Недостатки: Проектирование и устранение проблем с состоянием гонки (race conditions) и взаимной блокировкой (deadlocks) может быть сложным.

Применение: Системы реального времени, вычислительные системы с высокой производительностью, веб-серверы.

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

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

Например, паттерн “Оркестратор” - управляет взаимодействием между сервисами. Он организует управление потоком бизнес-логики и обеспечивает согласованное выполнение всех действий. Простыми словами: один сервис (оркестратор) говорит другим, что и когда делать. Суть паттерна в том, что Оркестратор получает запрос — и дальше сам инициирует вызовы нужных сервисов, обрабатывает результаты, принимает решения, контролирует поток выполнения и ошибки. Этот паттерн часто используется в сложных бизнес-процессах, где необходимо согласовать работу нескольких сервисов и обеспечить централизованный контроль.

Или паттерн “Хореография” - реализует систему сервисов, где каждый сервис работает независимо и взаимодействует с другими сервисами через события. Простыми словами: каждый сервис знает свою “партию” и выполняет её, когда наступает событие, без централизованного управляющего элемента. Взаимодействие сервисов строится на распределенных правилах: сервис публикует события и подписывается на события других сервисов. Этот паттерн используется, когда требуется создать децентрализованную, высоко связанную систему, обеспечивающую большую гибкость и масштабируемость.

Многослойный архитектурный стиль является одним из наиболее распространённых архитектурных паттернов. Он часто используется для традиционных веб-приложений и корпоративных приложений:

Принципы: Этот архитектурный стиль разделяет функциональность на отдельные слои. Типичный пример это 3-х уровневая архитектура: слой представления, бизнес-логики и слой хранения данных.

Преимущества: Легко понимать, тестировать и поддерживать; каждый слой может разрабатываться и обновляться независимо.

Недостатки: Это может привести к накладным расходам на производительность; внесение изменений, затрагивающих несколько слоёв, может быть сложным.

Применение: Веб-приложения, корпоративные приложения.

Многослойный (n-tier) паттерн – делит систему на N слоёв, каждый из которых несёт определённую ответственность. Самое распространённое деление — на три слоя: представление, бизнес-логику и слой хранения данных.

Стиль архитектуры распределённой системы - относится к системе, в которой компоненты, размещённые на сетевых компьютерах, взаимодействуют и координируют свои действия, передавая сообщения. Компоненты взаимодействуют друг с другом для достижения общей цели.

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

Преимущества: Масштабируемость, устойчивость к сбоям и общий доступ к ресурсам.

Недостатки: Увеличенная сложность, зависимость от сети и проблемы, связанные с согласованностью данных.

Применение: Распределённые базы данных, облачные вычисления, телекоммуникационные сети.

Наиболее известный паттерн распределенной системы – “Пространство данных” (Space-Based Pattern). Также известный как “Пространство кортежей»” или “Облачная архитектура”, предназначен для избегания единой точки отказа или узкого места производительности, путем равномерного распределения сервисов и ресурсов по нескольким серверам.

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

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

4.1.2. Классификация приложений

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

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

С этой точки зрения прикладные системы классифицируют по пяти различным архитектурными категориям:

1. Приложения, обслуживающие большое количество транзакций. Например: биллинг у телекоммуникационных операторов, резервирование авиабилетов, обработка транзакций по кредитным картам и тому подобное. Акцентируется внимание на: поддержке целостности данных, масштабируемости, производительности, надежности, транзакционности и т.д.

2. Операции в реальном времени. Например: транспортные операции в аэропорту, мониторинг пациентов в клинике. Должны обеспечить: высокую скорость реакции, Работу 24*7, надежность, поддержку приоритезации запросов и т.д.

3. Аналитические приложения, бизнес-аналитика, поддержка принятия решений. Например: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита. Должны поддержать: способность давать объяснения, наглядность представления информации, работу с большими объемами данных и т.д.

4. Приложения поддержки совместной работы. Например: средства асинхронного взаимодействия (электронная почта, дискуссионные форумы, групповые календари), средства синхронного взаимодействия (мгновенный обмен сообщениями). Должны обеспечивать: скорость распространения, простоту использования, высокую пропускную способность и т.д.

5. Корпоративные и обслуживающие приложения. Эта категория характерна для многих стандартных систем, таких как ERP, CRM, системы управления персоналом, системы расчета заработной платы. Характеризуется: надежностью, низкой стоимостью с точки зрения ИТ, сложной интеграцией и т.д.

Для наглядности категоризации удобно использовать матрицу категорий, в которой в строках указывают "Требование к ИС", а в колонках "Категория ИС". В ячейках на пересечении отмечают значения характеристик.

Существуют и другие способы сегментации характеристик для классификации информационных систем, с целью выбора наиболее подходящих архитектурных стилей. Например:

• по признаку структурированности и формализованности задач;

• по характеру представления и логической организации хранимой информации;

• по масштабу и интеграции компонент;

• по уровням управления;

• по функциональному признаку;

• и прочие.

Важно принимать во внимание, что не приложение подгоняется под стиль, а стиль подбирается под свойства приложения и бизнеса. Например, для корпоративных приложений, где существует необходимость интеграции со множеством систем, подходящим стилем будет SOA, при этом сложные процессы в них могут быть обеспечены Оркестрацией. Для высоконагруженных же систем понадобится масштабирование отдельных модулей и подойдет использование Микросервисов.

Метод группировки прикладных систем крайне важен так же и для управления Портфелем приложений о котором пойдет речь в следующей части.