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

Обычно в составе архитектуры выделяют от четырех до семи основных представлений (предметных областей или доменов) [4.1], [4.2], [4.3], [4.4]. Эти области последовательно покрывают архитектурные аспекты, отталкиваясь от потребностей функционирования организации (бизнеса) и обеспечивая весь набор технологий для реализации конкретного решения бизнес-проблемы. Ниже перечислены представления (домены) архитектуры:

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

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

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

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

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

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

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

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

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

• Миссия и видение.
• Руководящие принципы. Утверждения, описывающие принципы и ключевые элементы философии использования информационных технологий.
• Цели, задачи и стратегии.
• Архитектура информационных технологий.
• Политики (правила). Политики являются общими утверждениями, которые задают направления и цели, связанные с инициативами в области ИТ. Они носят, как правило, достаточно высокоуровневый и общий характер и обеспечивают скоординированный процесс планирования, закупку критически важных технологий, эффективную разработку систем и эффективное использование информационных технологий и ресурсов.
• ИТ-стандарты. Стандарты – это обязательные к использованию утверждения, касающиеся используемых технологий, продуктов и/или услуг. Они должны быть достаточно полными и в то же время определять разумный минимум требований, обязательных для использования. В случае, когда речь идет о стандартах, выбираемых государством, особенно важным является подход, когда стандарты описывают только наиболее общие и важные элементы технологий в соответствии с принципами честной конкуренции.
• Процедуры. Процедуры – это инструкции, описывающие, как выполняются политики и стандарты. Процедуры устанавливают и описывают процессы, которые выполняются на регулярной основе.
• Руководства или рекомендации (guidelines). Руководства и рекомендации – это описания лучших практик или приемлемых подходов к практической реализации политик и процедур. Руководства могут стать стандартами.

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

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

При разработке и использовании стандартов следует учитывать нижеперечисленные аспекты [4.5], [4.6]:

• Уделяйте большее внимание тем стандартам, которые обеспечивают эффективное использование базовых технологий. Прежде всего, это технологии, на которых построены многие системы и которые стали индустриальными стандартами. Примерами таких технологий для организаций являются XML,.NET, Java (рассматриваемая не как язык, а как среда разработки).
• Определяйте стандарты процессов. Примерами являются процессы бизнес-моделирования, методы разработки систем, тестирования, интеграции.
• Уделяйте внимание интерфейсам. Понимание интерфейсов является основой для интеграции систем.
• Теснее взаимодействуйте с бизнес-подразделениями. Например, разработка основанных на XML стандартов на электронные сообщения невозможна без участия специалистов в конкретных предметных областях.
• Для того чтобы быть эффективным инструментом, стандарты должны включать списки конкретных версий технологий, интерфейсов программирования (API), утилит и т.д. Примерами могут быть версии систем управления базами данных, версии XML и т.п.
• Стандарты должны включать способы проверки на соответствие.
• Стандарты должны содержать описание того, как организован процесс их поддержки. Стандарты должны периодически пересматриваться и обновляться.

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

• Руководства не заменяют техническую документацию, но рассматривают некоторые проблемы в контексте конкретной организации.
• Хорошие руководства сфокусированы на конкретных проблемах, общих для большинства разработчиков систем. Это включает, например, интеграцию приложений с использованием соответствующих систем интеграции корпоративных приложений, создание "горизонтальных" порталов, контроль версий.
• Тематика руководств может быть связана как с технологиями и их использованием, так и с процессами. Например, весьма полезными могут стать руководства, описывающие процессы создания конфигурации систем, построения версии системы или процесс контроля качества.
• Наиболее эффективные руководства, как правило, короткие и специфичные. Желательно ограничивать их четырьмя страницами.

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

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

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

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

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

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

Эти модели описывают архитектуру предприятия на различных уровнях абстракции, которые соответствуют "взглядам" на предприятие различных категорий людей. Вообще говоря, создание информационных систем состоит в постепенном уточнении моделей. Язык моделирования систем Unified Modelling Language (UML). При этом основная идея состоит в автоматизированном (насколько это возможно) процессе создания кода прикладных систем на основе разработанных моделей.

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

Бизнес-архитектура включает в себя, как правило, следующие аспекты:

• Бизнес-стратегия, функции и организационные структуры – собрание целевых установок, планов и структур организации. Данная информация может быть представлена в самых разных форматах, но наиболее важный аспект состоит в создании контекста для описания бизнес-процессов. Эта часть архитектуры не является технической, но она критически важна с той точки зрения, что архитектура информационных технологий (информации, прикладных систем, технологическая архитектура) строится на ее основе и обеспечивает реализацию ключевых функций организации.
• Архитектура бизнес-процессов, которая определяет основные функциональные области организации. Для министерства – это могут быть функции, перечисленные в Положении о министерстве, для коммерческой организации – процессы разработки новых продуктов, услуг и сбыта товаров и т.п. Она также описывает специфические процессы внутри каждой функциональной области и их операционные параметры – например, объемы операций, роли, реализацию централизованной или децентрализованной модели операций и т.д. Эта часть является как бы "точкой соприкосновения" между бизнес-архитектурой и архитектурой приложений и обеспечивает взгляд на бизнес и функции организации, достаточно детализированный для того, чтобы использовать его при выработке стратегии и планов создания приложений.
• Показатели эффективности. Этот аспект состоит в определении ключевых показателей эффективности (КПЭ) работы организации, их текущих уровней и желаемых, будущих уровней и включает в себя также разработку на верхнем уровне модели КПЭ для мониторинга.

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

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

Шаг 1. Идентификация критически важных для предприятия процессов (обычно не более восьми).

Хорошими кандидатами для включения в рамки архитектуры предприятия являются те ключевые процессы, которые максимально влияют на способности организации реализовывать свою миссию, достигать цели, выполнять основные функции, а также следующие процессы [4.13]:

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

Желательно, чтобы рекомендуемое число таких процессов, не превышало "волшебного числа" 8 в соответствии с известным принципом: "семь плюс-минус два" объекта. При необходимости схожие бизнес-процессы могут быть объединены в группы или классы.

Шаг 2. Отследить связи между этими процессами и бизнес-стратегиями, движущими силами и критически важными факторами успеха. Это можно сделать с помощью матрицы взаимных связей. Для каждого элемента этой матрицы определяется качественная оценка по принципу "важно" – "неважно" или по некоторой условной шкале. Например, можно использовать так называемую шкалу 9-3-1, в соответствии с которой 9 обозначает сильную взаимосвязь, 3 – промежуточную, 1 – слабую.

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

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

Шаг 5. Идентифицировать и документировать основные категории информационных объектов (опять же рекомендуется не более восьми).

Как правило, руководители и сотрудники бизнес-подразделений находят задачу понимания архитектуры трудной и требующей слишком больших затрат времени. Действительно, за пределами служб ИТ роль и связующий фактор архитектуры предприятия зачастую не осознается, а взаимосвязи между данными являются непонятными. Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно.

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

• декомпозиция функций/процессов;
• анализ бизнес-событий;
• моделирование местоположений выполнения функций/процессов;
• модель интеграции функций/процессов.

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

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

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

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

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

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

• Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)
• Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)
• Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней "пробелы"?)
• Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)
• Обучение (Как эти бизнес-процессы соотносятся с другими?)
• Общая стоимость владения (Сколько стоит этот процесс?)
• Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)

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

Архитектура информации. Сегодня организации должны искать эффективные способы работы с информацией, которая поступает из самых разнообразных источников и должна быть доступна там, где это нужно, и тогда, когда это необходимо. Ситуация осложняется тем, что различные формы информации зачастую требуют специфических технологий и методов работы с ней: 1) структурированная информация (реляционные и объектные модели); 2) развивающиеся, основанные на XML стандарты для полуструктурированной информации; 3) неструктурированная информация в форме текстов, графиков, образов, сопровождаемая определенными описательными данными (метаданными и каталогами).

Архитектура информации описывает, как информационные технологии обеспечивают в организации возможности для быстрого принятия решений, распространения информации внутри организации, а также за ее пределы, например, партнерам по бизнесу. Архитектура информации является как бы "зеркальным отражением" бизнес-архитектуры. Бизнес-архитектура отвечает на вопрос: "С учетом нашего общего видения, целей и стратегий, кто и что будет делать?" Архитектура информации отвечает на вопрос: "Какая информация должна быть предоставлена для того, чтобы эти процессы могли выполняться теми, кто их должен выполнять?" Архитектура информации включает в себя модели, которые описывают процессы обработки информации (information value chain), основные информационные объекты, связанные с бизнес-событиями, информационные потоки, принципы управления информацией. Архитектура должна описывать как те данные, которые требуются для выполнения процессов (операционные), так и аналитические данные и "контент", публикуемый на Web.

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

В ходе разработки архитектуры информации решаются, в соответствии с [4.16], следующие задачи:

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

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

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

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

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

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

Результатами процесса разработки архитектуры информации являются:

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

Еще одним важным понятием, относящимся к архитектуре информации, которое является особенно серьезным для крупных организаций или органов государственной власти с их большим количеством достаточно независимых систем и организационных структур (на национальном, региональном или муниципальном уровнях), является управление федеративными данными и метаданными (federated data management) [4.17]. Под управлением федеративными данными понимается архитектура, которая обеспечивает управление и доступ к данным и метаданным независимо от их внутренней логической структуры и физических границ их расположения, в целях организации взаимодействия систем и различных подразделений внутри организации и с внешними организациями

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

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

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

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

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

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

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

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

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

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

Ниже даны краткие характеристики каждой категории систем в соответствии с этой классификацией:

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

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

·

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

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

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

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

• базовые транзакционные (или вспомогательные, обеспечивающие, обслуживающие – utility);
• информационные (дающие преимущества);
• инновационные (стратегические).

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

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

• Критически важное для предприятия в целом (mission-critical). Приложение чрезвычайно важно для осуществления всей миссии компании, нарушения в работе приложения могут повлечь катастрофические последствия для бизнеса. Пример: система биллинга оператора мобильной связи или система управления движением в аэропорту.
• Критически важное для бизнеса (business-critical). Приложение важно для поддержки отдельного направления бизнеса или обеспечивающего бизнес-процесса. Нарушения могут повлечь серьезные затруднения в бизнесе. Пример: система приема заказов через Интернет.
• Вспомогательное (utility). Некритичное приложение, решающее частную, вспомогательную задачу. Пример: система резервирования помещений для переговоров.
• Средства офисной автоматизации (office productivity). Это приложения, используемые для автоматизации повседневной работы. Типичный пример: офисные пакеты и средства подготовки презентаций.

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

На практике ключевыми должны являться такие вопросы, как:

• Какие из этих пяти категорий приложений играют существенную роль в обеспечении общего успеха деятельности организации?
• Обеспечивает ли архитектура ИТ организации соответствующее оптимальное сочетание цены и производительности для обслуживания приложений, наиболее критичных с точки зрения успеха деятельности организации?

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