В Архитектуре приложений, как правило, выделяют две основные области:

1. формирование и управление портфелем прикладных систем предприятия;

2. разработку прикладных систем.

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

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

Модели и инструменты

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

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

• системам грозит вывод из эксплуатации (замена) или консолидация;

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

• системы, требующие обновления;

• системы, требующие сопровождения и развития.

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

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

20. Контекст и основные элементы архитектуры приложений. Портфель прикладных систем. Область разработки прикладных систем.

Смотри вопрос 19!!!!

21. Технологическая архитектура (архитектура инфраструктуры). Основные элементы технологической архитектуры.

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

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

Другими словами, под технической архитектурой мы понимаем полное описание инфраструктуры предприятия, включающее в себя: ЭЛЕМЕНТЫ ↓

• Информацию об инфраструктуре предприятия.

• Системное программное обеспечение (СУБД, системы интеграции).

• Стандарты на программно-аппаратные средства.

• Средства обеспечения безопасности (программно-аппаратные).

• Системы управления инфраструктурой.

22. Роль технологической архитектуры предприятия. Описание Gartner в технологической архитектуре.

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

Gartner Group называет в технологической архитектуре шесть архитектурных компонентов (сервисов), в каждом из которых выделяется определенное количество технологических «строительных блоков»:

• сервисы данных — системы управления базами данных, хранилища данных, системы поддержки принятия решений;

• прикладные сервисы — языки программирования, средства разработки приложений, системы коллективной работы (средства групповой работы и электронной почты, средства управления документами), архитектура приложений (модель компонентов, серверы приложений, серверы поддержки тонких клиентов), геоинформационные системы и средства;

• программное обеспечение промежуточного слоя (middleware);

• вычислительная инфраструктура — операционные системы и аппаратное обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства — ноутбуки, беспроводные устройства, принтеры), среда для веб-инфра- структуры (браузеры, веб-порталы, веб-серверы и т.д.), системы хранения (сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений);

• сетевые сервисы — локальные сети (протоколы, кабельные системы, топология), глобальные сети (транспорт, протоколы), технологии доступа (пользователи с удаленным доступом, беспроводные технологии для локальных и глобальных сетей, интегрированные средства передачи данных и голоса, обеспечение доступности, средства видеоконференций), голосовые технологии (голос/данные поверх IP-протокола, голосовая почта), сетевое аппаратное обеспечение (концентраторы, маршрутизаторы и пр.);

• сервисы безопасности — авторизация, аутентификация (внутренняя и внешняя), сетевая безопасность, физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

23. Роль технологической архитектуры предприятия. Подход п. Кина в описании технологической архитектуры.

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

← Оценка состояния технологической инфраструктуры предприятия на основе подхода, предложенного Питером Кином, основана на критериях:

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

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

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

24. Адаптивная технологическая инфраструктура. Использование.

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

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

• самоконфигурирования (организация в соответствии с текущими требованиями);

• самозащиты (предотвращение сбоев в результате нарушения конфигурации отдельных компонентов или потери целостности данных);

• самовосстановления (диагностика неисправностей, локализация ошибок и устранение их последствий);

• самооптимизации (наиболее рациональное использование имеющихся ресурсов без вмешательства человека).

Основные идеи адаптивной технологической инфраструктуры сводятся к следующему:

• все ИТ-ресурсы являются общими и разделяемыми;

• выделение ресурсов конкретным приложениям производится автоматически в соответствии с организационными требованиями;

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

25. Модель Захмана. Структура и модель описания ит-архитектуры Gartner.

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

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

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

Собственно модель представляется в виде таблицы, имеющей шесть строк и шесть столбцов, которая приведена на рисунке ←.

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

• Данные (DATA) - что? Уровень описывает любые формы предоставления информации необходимой для эффективного функционирования предприятия.

• Функции (FUNCTION) – как? Описывает набор бизнес-процессов, обеспечивающих функционирование предприятия.

• Место (NETWORK) – где? Определяет географическое расположение объектов и сетевую организацию предприятия.

• Люди (PEOPLE) - кто? Определяет участников процесса, описывает распределение ответственности и функции работников.

• Время (TIME) - когда? Описывает временные характеристики. Время может быть абсолютным или относительным, отражать взаимосвязь процессов.

• Мотивация (MOTIVATION) - почему? Определяет направление развития бизнес-цели и стратегии.

Строки таблицы:

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

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

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

• На четвертом уровне — технологической или физической модели — осуществляется привязка данных и операций над ними к выбранным технологиям реализации.

• Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

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

Gartner

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