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

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

Объем

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

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

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

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

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

Стратегия

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

Узоры

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

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

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

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

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

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

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

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

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

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

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

Области знаний

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

Задачи

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

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

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

Функциональность

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

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

Создание рекомендаций по архитектуре решения

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

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

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

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

См. также

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

Ссылки

^ Стивен Спевак ; С. К. Хилл (1992). Планирование архитектуры предприятия: разработка плана для данных, приложений и технологий . Бостон, паб QED. Группа. ISBN 978-0-471-59985-2 .
^ «Эталонная модель сертификатов ISEB в архитектуре предприятия и решений версии 3.0» (PDF) . БКС. 2010.
^ «Архитектура приложения» . Глоссарий Gartner в области ИТ . 9 февраля 2012 г. Проверено 26 июля 2017 г.

«Фаза C: Архитектура информационных систем — Архитектура приложений» . ТОГАФ 9.1 . Проверено 26 июля 2017 г.
Хантер, Рой; Расмуссен, Брайан. «Архитектура приложений» . Оракул . Проверено 26 июля 2017 г.

[EAP-1] Стивен Спевак ; С. К. Хилл (1992). Планирование архитектуры предприятия: разработка плана для данных, приложений и технологий . Бостон, паб QED. Группа. ISBN 978-0-471-59985-2 .

[2] «Эталонная модель сертификатов ISEB в архитектуре предприятия и решений версии 3.0» (PDF) . БКС. 2010.

[Gartner_IT_Glossary_2012-3] «Архитектура приложения» . Глоссарий Gartner в области ИТ . 9 февраля 2012 г. Проверено 26 июля 2017 г.

[1]

[2]

[3]