Архитектура приложений

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

В информационных системах архитектура приложений или архитектура приложений является одним из нескольких доменов архитектуры , которые формируют столпы архитектуры предприятия (EA). ^{[1] [2]}

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

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

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

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

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

Архитектура приложений определяет, как несколько приложений готовы работать вместе. Она отличается от архитектуры программного обеспечения , которая занимается техническими проектами того, как построена система. ^{[ необходима цитата ]}

Необходимо не только понимать и управлять динамикой функций, реализуемых композитной архитектурой, но и помогать формулировать стратегию развертывания и следить за технологическими рисками, которые могут поставить под угрозу рост и/или деятельность организации. ^{[ необходима цитата ]}

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

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

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

«Шаблон» определяется как:

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

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

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

Шаблоны приложений могут описывать структурные (связанные с развертыванием/распределением) или поведенческие (связанные с потоком процессов или взаимодействием/интеграцией) характеристики, а архитектура приложения может использовать один или несколько шаблонов.

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

Помимо GoF, Томас Эрл является известным автором различных типов шаблонов, а большинство крупных поставщиков программных инструментов, таких как Microsoft , опубликовали обширные библиотеки шаблонов.

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

• одноуровневое / толстое клиентское / настольное приложение (структурный шаблон): приложение, которое существует только на одном компьютере, обычно на настольном. Конечно, можно иметь одно и то же настольное приложение на многих компьютерах, но они не взаимодействуют друг с другом (за редкими исключениями).
• клиент-сервер / 2-уровневый (структурный шаблон): приложение, состоящее из фронтенд- слоя (обращенного к пользователю), работающего как расширенный клиент, который взаимодействует с бэкендом ( сервером), который обеспечивает бизнес-логику, рабочий процесс , интеграцию и службы данных . В отличие от настольных приложений (которые являются однопользовательскими), клиент-серверные приложения почти всегда являются многопользовательскими приложениями.
• n-уровневая (структурная модель): расширение клиент-серверной модели, в которой функции сервера разделены на несколько уровней, которые распределены по разным компьютерам в локальной сети (LAN).
• распределенный ( структурный шаблон ): расширение шаблона n-tier, где функции сервера распределены по глобальной сети (WAN) или облаку. Этот шаблон также включает некоторые атрибуты поведенческого шаблона , поскольку функции сервера должны быть спроектированы так, чтобы быть более автономными и функционировать в асинхронном диалоге с другими функциями, чтобы справиться с потенциально значительной задержкой , которая может возникнуть в сценариях развертывания WAN и облака .
• горизонтальная масштабируемость (структурная модель): модель для запуска нескольких копий функций сервера на нескольких компьютерах таким образом, что увеличивающаяся нагрузка обработки может быть распределена по увеличивающемуся числу экземпляров функций, а не для повторного развертывания функций на более крупных, более мощных компьютерах. Облачные приложения в основе своей основаны на горизонтальной масштабируемости.
• Архитектура, управляемая событиями (поведенческий шаблон): События данных (которые изначально могли исходить от устройства , приложения, пользователя, хранилища данных или часов) и логика обнаружения событий, которая может условно отклонить событие, инициировать процесс, связанный с событием, оповестить пользователя или менеджера устройств или обновить хранилище данных. Шаблон, управляемый событиями, является основополагающим для асинхронной обработки, требуемой шаблоном распределенной архитектуры .
• ETL (поведенческий шаблон): шаблон процесса приложения для извлечения данных из исходного источника, преобразования этих данных в соответствии с некоторыми бизнес-правилами, а затем загрузки этих данных в пункт назначения. Вариации шаблона ETL включают ELT и ETLT.
• Запрос-ответ (поведенческий шаблон): Шаблон интеграции приложений для обмена данными, где приложение запрашивает данные у другого приложения и ждет ответа, содержащего запрошенные данные. Это наиболее яркий пример синхронного шаблона, в отличие от асинхронной обработки, упомянутой в предыдущих описаниях шаблонов.

Правильная схема применения зависит от отрасли организации и использования компонентов приложений.

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

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

Моделирование приложений

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

Конкурентная разведка , бизнес-моделирование , стратегический анализ

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

Технологии

Понимание ИТ-стратегии , жизненного цикла разработки и обслуживания приложений/инфраструктуры; Понимание процессов ИТ-обслуживания и поддержки для повышения конкурентного преимущества, повышения эффективности и добавления ценности бизнесу.

Технологические стандарты

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

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

• Возможность взаимодействия
• Производительность и масштабируемость
• Надежность и доступность
• Этап жизненного цикла приложения
• Технологические риски
• Количество экземпляров

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

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

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

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

Стандарты в мире архитектуры определены в TOGAF, Open Group Architecture Framework описывает четыре компонента EA как BDAT ( бизнес-архитектура , архитектура данных , архитектура приложений и техническая архитектура) .

Существуют и другие стандарты, которые следует учитывать в зависимости от уровня сложности организации:

• Структура Захмана для EA
• Архитектура федерального предприятия (FEA)
• Гартнер ^[3]

• ISO/IEC 42010 Системная и программная инженерия. Описание архитектуры — международный стандарт для описания архитектуры систем и программного обеспечения.
• IEEE 1471 — устаревший стандарт IEEE для описания архитектуры «программно-интенсивной системы», также известной как программная архитектура .
• Архитектура приложений IBM Systems
• Планирование архитектуры предприятия
• Архитектура приложений высокой доступности

• "Фаза C: Архитектуры информационных систем - Архитектура приложений". TOGAF 9.1 . Получено 26.07.2017 .
• Хантер, Рой; Расмуссен, Брайан. «Архитектура приложений». Oracle . Получено 26.07.2017 .