Кемерово 2014 К.А. Васильев Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования «Кемеровский государственный сельскохозяйственный институт» Кафедра «Финансы и кредит» АРХИТЕКТУРА ПРЕДПРИЯТИЯ

ТЕМА 7 ТЕХНОЛОГИЧЕСКАЯ АРХИТЕКТУРА, СТАНДАРТЫ И ШАБЛОНЫ 7.1. Технологическая архитектура (архитектура инфраструктуры) Контекст и основные элементы технологической архитектуры Оценка состояния и требований к технологической инфраструктуре в контексте бизнес- стратегии Адаптивная технологическая инфраструктура Роль стандартов Использование архитектурных шаблонов Сервис-ориентированная архитектура (SOA) и архитектура, управляемая моделями (MDA).

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

Рисунок 7.1 – Различные уровни размещения инфраструктуры

Рисунок 7.2 – Пример областей, категорий, стандартов и спецификаций технической справочной модели TRM FEAF

Рисунок 7.3 – Взаимосвязи функциональных и операционных требований с архитектурой приложений и технологической архитектурой

Оценка состояния и требований к технологической инфраструктуре в контексте бизнес-стратегии Для оценки состояния технологической инфраструктуры предприятия в терминах, понятных бизнес-руководству, и с точки зрения потенциальных возможностей реализации различных бизнес-стратегий, можно использовать подход, предложенный Питером Кином (Peter Keen). Он основан на использовании двух критериев: Функциональные возможности: возможности по выполнению бизнес- активностей, начиная с простых, таких как пересылка информации (сообщений), до выполнения сложных транзакций, которые могут производиться совместно сотрудниками, а также поставщиками и клиентами; Охват: физические места расположения и группы людей, которые инфраструктура способна объединить, начиная от отдельного подразделения и до уровня отдельного сотрудника, где бы он ни находился. На рисунке 7.4 приведен вариант матрицы, которая использует эти два критерия. Чем шире функциональные возможности и охват инфраструктуры, тем более сложные, одновременно совершаемые в разных системах транзакции, может выполнять организация в различных местах расположения бизнеса. Например, точка «A» на рисунке означает возможность обеспечить, например, прием заказа и его обработку, включая информацию о складе, планах производства, выставление счетов во всех соответствующих системах и подразделениях независимо от местоположения. В то же время точка «B» соответствует ограниченным функциональным возможностям и широте охвата инфраструктуры, которая обеспечивает возможности по пересылке электронных сообщений в рамках отдельных подразделений.

Рисунок 7.4 – Охват и функциональные возможности инфраструктуры

Адаптивная технологическая инфраструктура Уделим особое внимание одному, но достаточно важному аспекту, который сейчас активно позиционируется в качестве перспективного направления развития. Речь идет о создании адаптивной технологической инфраструктуры, которая способна в определенных пределах, автоматически или полуавтоматически, «подстраиваться под требования» со стороны бизнес-приложений для обеспечения оптимальной работы. Основными характеристиками адаптивной системы являются: само конфигурирование – организация системы в соответствии с требованиями; самозащита – предотвращение сбоев в системе в результате нарушения работы компонент системы и потери целостности данных; самовосстановление – диагностика неисправностей, локализация ошибок и устранение их последствий; самооптимизация – наиболее рациональное использование имеющихся ресурсов без вмешательства оператора. Другая важная проблема – необходимость повышения эффективности использования существующих вычислительных ресурсов. Действительно, типовая загрузка мейнфреймов составляла порядка 80%, сейчас же характерными значениями являются порядка 40% для RISC-серверов и всего лишь 15% для Intel/Windows серверов. Это является следствием достаточно распространенной практики «каждому приложению – свой сервер». Но если для небольших организаций такой подход еще, в принципе, допустим, учитывая относительную дешевизну серверов уровня рабочей группы, то при количестве приложений в несколько десятков управление становится слишком неудобным, сложность – избыточной, надежность – низкой, а совокупные затраты – неприемлемо большими.

Рисунок 7.5 – Инфраструктура реального времени

7.2. Роль стандартов Применение стандартов играет важную роль в архитектуре информационных систем – прежде всего потому, что стандарты обеспечивают возможность взаимодействия различных компонент между собой. Чем более сложной, распределенной и тиражируемой является система, тем эта определяющая и консолидирующая роль стандартов становится все более актуальной. Стандарты есть общепринятые документы, формализующие лучшие практики. Строго говоря, принято различать стандарты де-юре, т.е. разработанные и поддерживаемые официальными органами по стандартизации, такими как Международная организация по стандартизации – ISO, и стандарты де-факто, основанные на существующем широком распространении технологии, методологии или продукта (например, использование MS Windows в качестве операционной системы для персональных компьютеров). С другой стороны, можно выделять два класса – «технологические» и «рамочные» стандарты. Технологические стандарты определяют особенности реализации тех или иных протоколов, интерфейсов, языков программирования и т.п. Типичным примером являются спецификации WWW консорциума W3C. В составе описания ИТ-архитектуры предприятия обычно приводятся ссылки на используемые стандарты такого типа.

Рисунок 7.6 – Структура активностей стандарта ISO 15288

7.3. Использование архитектурных шаблонов Мы уже отмечали выше актуальность интеграции приложений и использования общих компонент информационных систем (сервисов). Отражением этого факта является существующая тенденция выделения данных аспектов в отдельные области архитектуры предприятия. Существенную роль при реализации этих областей играют стандартизованные элементы. Подобно тому, как проект здания может включать в себя элементы ранее созданных конструкций, так и реализация поддержки бизнес-процесса в информационной системе может использовать уже известные фрагменты программного кода и/или типовые конфигурации оборудования. Это позволяет, с одной стороны, значительно сократить сроки выполнения решения, с другой – уменьшить риски за счет использования фрагментов, проверенных на практике. Фактически речь идет о выборе и использовании подходящих шаблонов (patterns). Английский термин «pattern» имеет различные варианты перевода, в том числе «образец», «шаблон» и т.п. В данном случае мы будем использовать русский термин «шаблон», оставляя кальку «паттерн» для обозначения аналогичных объектов в области программной архитектуры. Шаблоны являются как бы проверенными способами построения какой-то части системы. Одним из удачных определений шаблонов является следующее: «Шаблон – это общее решение некоторой повторяющейся проблемы в определенном контексте».

Рисунок 7.8 – Шаблон показывает взаимодействие компонент системы между собой Рисунок 7.7 – Шаблон – решение проблемы в контексте

Рисунок 7.9 – Архитектура, шаблоны и модели Рисунок 7.10 – Пример инфраструктурного шаблона

Рисунок 7.11 – От традиционной архитектуры – к архитектуре, использующей инфраструктурные шаблоны

Большой интерес при создании бизнес-архитектуры предприятия представляют бизнес-шаблоны. Описание бизнес-шаблона включает: описание поддерживаемой бизнес-функции; данные, которые требуются для выполнения описанной бизнес-функции; бизнес-компоненты, которые являются представлением данных и функций бизнеса на языке информационных технологий; возможно, описание инфраструктуры, которая необходима для поддержки функций, данных и компонент. В качестве другого примера рассмотрим возможности предложенных компанией IBM «шаблонов для электронного бизнеса». Так как практически все приложения для электронного бизнеса сталкиваются с необходимостью решения таких вопросов, как масштабируемость, надежность, доступность, безопасность, то представляется, что использование относительно небольшого числа стандартизованных решений может оказаться полезным. Эти решения можно, в свою очередь, подразделить в зависимости от уровня абстракции – соответственно на бизнес-шаблоны, архитектурные шаблоны, шаблоны уровня приложений и т.п. При этом: бизнес-шаблоны (Business pattern) предназначены для описания взаимодействия между участниками процесса; шаблоны дизайна (Design pattern) отражают внутреннюю компонентную структуру системы; шаблоны уровня приложений (Application pattern) определяют различные варианты взаимодействия между пользователями, приложениями и данными в системе, а также соответствующий прототип уровня выполнения; шаблоны уровня выполнения (Runtime pattern) описывают привязку компонент системы к физическим узлам и определяют конкретные возможные продукты и их комбинации. В соответствии с предлагаемой схемой выделяются 4 основных бизнес-шаблона (табл. 7.1). Таблица 7.1 – Модель шаблонов электронного бизнеса IBM

Рисунок 7.12 – Категоризация архитектурных шаблонов Microsoft

7.4. Сервис-ориентированная архитектура (SOA) и архитектура, управляемая моделями (MDA) В последнее время необходимость интеграции и взаимодействия приложений в рамках совокупности большого количества информационных систем предприятия или нескольких предприятий, объединенных в целую партнерскую цепочку, оказывают существенное влияние на используемые программные архитектуры. Детальное рассмотрение этих аспектов выходит за рамки данного курса, но мы посчитали целесообразным привести краткую информацию о новых подходах к проектированию архитектуры информационных систем, так как они имеют непосредственное влияние на принципы формирования архитектуры предприятия в целом. Речь идет, прежде всего, о сервисной модели взаимодействия между приложениями общей системы в рамках так называемой сервис-ориентированной архитектуры (Service- oriented architecture SOA) и о реализации архитектуры, «управляемой моделями» (модельная архитектура. Model-driven architecture MDA). Что такое сервис-ориентированная архитектура и как она связана с вопросами бизнес-архитектуры и архитектуры информационных технологий предприятия? Хотя концепция сервис-ориентированной архитектуры была сформулирована специалистами в области ИТ, но в действительности это был прямой ответ на потребности сегодняшнего дня, когда становится уже не совсем понятно, где заканчиваются бизнес- функции организации и начинаются информационные технологии, их обеспечивающие, и наоборот. Ведущие поставщики информационных технологий, такие как Microsoft и IBM, развивают эту концепцию в рекомендациях по проектированию информационных систем на своих программных платформах. А такие компании, как Gartner, считают, что сервис- ориентированная архитектура будет ведущим принципом проектирования новых критически-важных прикладных систем и бизнес-процессов в ближайшем будущем.

Рисунок 7.13 – Ссылочная модель сервис-ориентированной Архитектуры предприятия

Рисунок 7.14 – Создание прикладных систем в соответствии с подходом MDA

The end. Спасибо за внимание! Васильев Константин Александрович, зав. кафедрой «Финансы и кредит», к.э.н., доцент Вопросы и предложения по е-mail: