Одним из возможных, достаточно простых форматов описания архитектуры является простое матричное представление, которое для каждой из основных областей архитектуры ИТ, таких как данные, приложения, интеграция, общие сервисы, и инфраструктура, "последовательно накладывает" несколько спецификаций, отличающихся по уровню детализации и конкретизации:
· Бизнес-потребности, которые определяют ключевые требования к конкретной технологии для данной индустрии и организации. Фактически здесь определяется индивидуальность архитектуры. Другой важный аспект связан с позиционированием ИТ в организации – либо ИТ-архитектура формируется для максимального уменьшения издержек, либо она должна обеспечивать возможности быстрых изменений и высокую гибкость. Другие примеры могут включать быстрое распространение информации, высокую безопасность, простоту использования и требуемую степень надежности.
· Принципы, которые включают в себя те основополагающие подходы, которых придерживается руководство. Например, это может быть принцип максимального использования стандартных приложений вместо заказных разработок, правила относительно того, кто владеет данными и пр. Большинство организаций могут иметь от 20 до 30 таких базовых принципов.
· Процессы и руководства во всех областях жизненного цикла элементов архитектуры. Этот раздел может охватывать такие области как документирование требований пользователей, стили программирования, процессы обеспечения качества или управление конфигурациями устройств и систем. Здесь также могут быть определены "эталонные модели" для организации пользовательского интерфейса, доступа к данным, управления содержанием.
· Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями.
· Раздел Используемые продукты и технологии является, по сути дела, утвержденным для организации списком продуктов или технологий. Они закупаются и используются как для создания приложений, так и для формирования инфраструктуры и обеспечения интеграции с внешними системами. Эта часть содержит взвешенную оценку всех "за" и "против" о конкретных поставщиках.
Таким образом, данный подход позволяет обеспечить отслеживание логической связи между выбранными технологиями, их ценностью для бизнеса и потребностями бизнеса. Выбор не должен быть сделан просто по той причине, что это "крутая" технология или что эта технология уже фактически используется.
В 2002 году Gartner сформулировала новую концепцию архитектуры предприятия, которая стала определенным обобщением рассмотренной ранее модели ИТ-архитектуры на уровень Бизнес-архитектуры, косвенным отражением растущей важности вопросов взаимодействия предприятий между собой, влияния концепций сервис-ориентированной архитектуры, осознания того факта, что существуют различные стили архитектуры информационных систем, соответствующие различным стилям бизнес-процессов. Мы уже отмечали выше, что типичными стилями бизнес-процессов являются массовая обработка транзакций, операции в реальном времени, аналитические процессы и бизнес-анализ, совместная работа.
Эта модель в какой-то степени расширяет рассмотренные выше представления, а также подчеркивает взаимосвязь между понятиями "Электронной нервной системы" предприятия, которые были сформулированы в свое время Биллом Гейтсом, основателем, а ныне Председателем и Главным архитектором программного обеспечения компании Microsoft, и практической реализации этих идей в рамках современных подходов к проектированию архитектуры ИТ предприятия. Кстати, обратите внимание, как называется должность Билла Гейтса. Не является ли это еще одним подтверждением важности вопросов систематического построения и описания архитектуры?
Билл Гейтс в своей книге "Бизнес со скоростью мысли" дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем".
Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:
· Среда бизнес-взаимодействия (Business Relationship Grid);
· Бизнес-процессы и стили бизнес-процессов;
· Шаблоны;
· Технологические строительные блоки (кирпичики – bricks).
Рис. 2.3. Уровни модели архитектуры Gartner
При этом уровни ИТ-архитектуры соответствуют различным уровням выполнения операций реального бизнеса так, как показано на рис. 1.4.
Рис. 2.4. Архитектура ИТ в бизнес-контексте
В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и ИТ-специалистами и в какой-то степени соответствуют тому, что мы называли бизнес-архитектурой, а нижние два уровня входят во внутреннюю компетенцию ИТ-службы:
· верхний уровень Среды бизнес-взаимодействия описывает новую модель "виртуального" бизнеса, а также все, что связано с кооперацией предприятий и бизнесом B2B. Этот уровень соответствует понятию "отраслевой нервной системы" взаимодействующих предприятий. Он получил развитие в связи с распространением Интернет как среды взаимодействия, и связан с понятиями доступа, межорганизационного взаимодействия;
· второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие как обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией;
· следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы, как мы рассматривали ранее в лекции 7. Примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс-логика-данные), использование "толстого" клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в виде модульного набора различных типов сервисов. Это, в том числе, позволяет в перспективе интегрировать приложения как web-сервисы.
· нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и пр.
Этот подход является адекватным с точки зрения того, что он раскрывает руководству механизм влияния решений в области ведения бизнеса на решения в области использования ИТ на предприятии. Как предлагают первые верхние два уровня модели, архитектура становится особенно важной по мере того, как модели ведения бизнеса развиваются в сторону все "более виртуальных" структур ("расширенных организаций"), успех которых будет в существенной степени зависеть от рациональной реализации архитектуры.
Полная модель представляет собой "трехмерную" комбинацию бизнес-архитектуры, технической и информационной архитектур. При этом описанные выше слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности. По большому счету, "все пересекается со всем". Например, при построении прикладных систем могут использоваться шаблоны проектирования и строительные технологические блоки. При этом для управления прикладной системы используются технологии системного управления и также должны быть учтены вопросы безопасности.
Данный подход Gartner представляет собой пример реализации методологии достаточно высокого уровня. Он задает только общую рамочную модель описания и фактически не определяет ни форматов, ни какого-либо специализированного языка для описания. Что касается разработки архитектуры, то в данном подходе сформулированы важные и полезные рекомендации в виде последовательности шагов и задач участников, которые, однако, не детализированы до уровня моделей процесса разработки архитектуры.
Методика META Group
Подробное описание методики разработки архитектуры предприятия META Group содержится в документе Enterprise Architecture Desk Reference объемом около 380 страниц, который предоставлялся клиентам компании. Остановимся на самых главных моментах этой безусловно интересной методики, доступных в открытых материалах.
По мнению META Group, "архитектура является одновременно некоторым структурированным описанием информационных технологий предприятия и его информационных технологий (т.е. конечным результатом, включающим определенные артефакты- стандарты, утверждения, касающиеся общего видения, архитектурные документы), процессом создания и обновления артефактов архитектуры и группами людей, вовлеченных в этот процесс". Соответственно этим представлениям методика компании уделяет достаточно подробное внимание всем трем составляющим архитектуры. При этом отличительной особенностью методики META является более детальное и формализованное описание именно процесса разработки архитектуры и всех его составляющих.
Исторически архитектурная методика META Group оперировала таким понятием, как Технологическая архитектура масштаба предприятия (EWTA – Enterprisewide Technical Architecture). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) архитектуры предприятия META Group были добавлены такие домены, как Бизнес-архитектура (EBA – Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и Портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio).
Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.
Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).
Рис. 2.5. Аналитическая работа и компоненты Архитектуры предприятия
Организация рабочего процесса разработки архитектуры и быстрое создание начальной версии архитектуры предприятия, согласно META Group, состоит в прохождении следующих этапов.
На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:
· анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;
· бизнес-стратегии и основные движущие силы с точки зрения бизнеса;
· требования к информационным системам со стороны бизнеса;
· требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса.
Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состоянием архитектуры.
Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры.
При этом данная методика предлагает формализованные шаблоны, обеспечивающие разработку Видения общих требований и Концептуальной архитектуры.
Рекомендация относительно Видения общих требований состоит в том, что этот документ не должен обязательно быть исключительно точным и всеобъемлющим с точки зрения анализа бизнес-стратегии. Главное – это совместное участие представителей бизнес-подразделений и ИТ в выработке общего понимания набора требований, согласованных со стратегическим направлением развития компании. Размер этого документа может быть 10-15 страниц. Основное содержание документа может состоять из четких утверждений, которые тематически связаны между собой, например, так, как показано в таблице 2.2.
Таблица 2.2. Пример компоненты Видения общих требований
| Тенденция | Бизнес-стратегия предприятия | Требования к информационным системам | Требования к архитектуре |
| Задержки в предоставлении услуги затрагивают 20% клиентов | Процесс обслуживания, уменьшающий ожидание клиента, приведет к увеличению доли рынка | Информация о заказах, независимо от канала и места их получения, должна немедленно передаваться в производство | ИТ-инфраструктура должна обеспечивать управляемый доступ и своевременную передачу информации, чтобы обеспечить операционную эффективность |
Важный аспект заключается в документировании явных связей между бизнес-стратегией (потребностями бизнеса) и требованиями к информационным системам и, в конечном итоге, установления логических связей с требованиями к технологической архитектуре. Для этого рекомендуется использовать простые матрицы так, как это показано на рис. 2.6. Документированные связи послужат основой для будущих решений об инвестициях.
Рис. 2.6. Матрица связей между бизнес-стратегиями, требованиями к информационным системам и технологической архитектуре
Таким образом, результатом первого этапа работ могут быть четыре документа:
· список ключевых технологических тенденций;
· список бизнес-стратегий;
· список требований к информационным системам;
· список требований к технологической архитектуре.
Видение общих требований агрегирует все требования к технологической архитектуре, и это служит основой для формулировки принципов Концептуальной архитектуры. В свою очередь, эти принципы обеспечивают общие руководства в использовании, разработке различных информационных систем и инфраструктуры в различных технологических областях.
Концептуальная архитектура разрабатывается еще до создания других архитектурных доменов и основана на принципах, которые имеют несколько общих характеристик:
· принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры;
· принципы являются ограниченным числом точек стабильности, на которых строится архитектура;
· принципы должны быть утверждениями, чья справедливость для организации носит "вечный" характер, поскольку они задают систему ценностей для архитектуры в целом.
Мы уже отмечали, что в соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, как отмечалось в лекции 7, можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение).
Каждый домен технологической архитектуры включает описание принципов, технологий, стандартов, продуктов, конфигураций, лучших практик, которые являются многократно используемыми строительными блоками при построении ИТ-систем.
На рисунке 2.7 приведена структура описания каждого домена технологической архитектуры предприятия, согласно META Group.
Рис. 2.7. Структура описания доменов технологической архитектуры
Таким образом, документ, описывающий каждый домен технологической архитектуры, включает следующие компоненты:
· Формулировка миссии домена: стратегические цели домена.
· Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.
· Принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений в отношении технологий домена, а также обоснования и последствия принятия этих принципов. Здесь могут быть построены матрицы соответствия между требованиями к технологической архитектуре (RTA), сформулированные в процессе создания Видения общих требований, и принципов проектирования, принятых для конкретного домена.
· Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре. Выделяют стратегические (предпочтительные) стандарты, переходные (которые используются временно), устаревшие (которые, возможно, еще используются, но от которых организация отказывается) и исследовательские или новые (которые находятся только на этапе рассмотрения и апробации).
· Лучшие практики.
· Конфигурации. Они формулируются в тех случаях, когда нужно уменьшить сложность принятия решений или когда можно уменьшить общую стоимость владения за счет стандартных конфигураций.
· Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры.
Взгляд на технологическую архитектуру с точки зрения предоставляемых ею инфраструктурных сервисов обусловлен распространением принципов сервис-ориентированной архитектуры. Это связано с описанием, например, сервисов презентации информации (порталы, настольные системы и пр.), сетевыми сервисами (LAN, WAN, удаленный доступ), сервисами безопасности (управление пользователями, доступ), сервисами хранения данных (SAN – Storage Area Network, файловые системы), сервисами баз данных (OLTP), интеграционными сервисами, платформенными сервисами, которые используются прикладными системами.
При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия:
· Домены архитектуры – первый уровень адаптируемости технологий. Категоризация помогает предприятиям обнаруживать излишние технологии, продукты и конфигурации, а также позволяет идентифицировать возможности многократного использования элементов технологической архитектуры.
· Шаблоны – второй уровень адаптируемости технологий. Позволяют разработчикам использовать одни и те же конфигурации технологий для решения похожих задач.
· Сервисы – третий уровень адаптируемости технологий. Они обеспечивают общие интерфейсы для разработчиков прикладных систем и интеграторов приложений в рамках всей инфраструктуры предприятия.
При этом выделяется четыре группы сервисов по мере повышения уровня абстракции:
· Базовые инфраструктурные сервисы: общие, стандартные технологии, широко используемые в рамках всех ИТ-систем предприятия. Они ориентированы не на разработчиков прикладных систем, а на специалистов по инфраструктуре. Примерами являются ПО пересылки сообщений промежуточного слоя, мониторы транзакций, сервисы каталогов.
· Общие (framework) инфраструктурные сервисы: общие, совместно используемые технологии, которые не содержат готовой бизнес-логики (хотя она и может быть запрограммирована), ориентированы на разработчиков и могут быть не полностью стандартизированы. Примерами таких сервисов являются управление контентом, серверы приложений, серверы выполнения бизнес-правил.
· Общие (framework) бизнес-сервисы: могут быть использованы в рамках различных бизнес-процессов, поскольку они содержат готовую, предопределенную бизнес-логику. Примерами таких сервисов являются модули определения цены товара, модули персонализации информации, модули оценки кредитного рейтинга.
· Прикладные бизнес-сервисы: специфические для отдельных бизнес-процессов, содержат высокоуровневую бизнес-логику. Например, сервисы CRM-систем или систем управления поставками.
В результате получается технологическая модель предприятия, представленная на рис. 8.8.
Рис. 2.8. Технологическая модель предприятия
В полном описании методики META Group приводятся также следующие аспекты:
· практическая реализация архитектуры через процесс управления корпоративными ИТ-программами и проектами;
· вопросы управления и контроля архитектурного процесса (governance);
· оценка зрелости архитектуры;
· анализ технологических тенденций и планирование;
· управление портфелем ИТ-активов и проектов.
Методика TOGAF
Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а также компаний из списка Fortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как "средство для разработки архитектур информационных систем". Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 года была опубликована версия 8.1 этой модели.
Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.
В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.
Общая структура TOGAF показана на рис. 2.9.
Рис. 2.9. Структура TOGAF
Важно отметить, что TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов. Лицензируется только коммерческое использование.
В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:
· Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
· Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
· Фаза B: разработка бизнес-архитектуры предприятия.
· Фаза C: разработка архитектуры данных и архитектуры приложений.
· Фаза D: разработка технологической архитектуры.
· Фаза E: проверка возможности реализации предложенных решений.
· Фаза F: планирование перехода к новой системе.
· Фаза G: формирование системы управления преобразованиями.
· Фаза H: управление изменением архитектуры.
Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:
· Описание существующей технологической архитектуры.
o Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
o Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
o Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
o Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
o Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
· Формирование целевой технологической архитектуры.
o Описание существующей системы в терминах TOGAF.
o Определение перспектив (представлений) архитектуры.
o Формирование модели целевой архитектуры.
o Определение ИТ-служб (сервисов).
o Подтверждение учета бизнес-требований.
o Определение архитектуры и используемых блоков (шаблонов).
o Проведение анализа расхождений (gap analysis).
Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!
Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры (Implementation Governance). Так, фаза G предусматривает следующие задачи:
· Организация Совета по архитектуре, включающего представителей всех бизнес-подразделений и руководства. Этот Совет должен выполнять наблюдательную и координирующую роль.
· Разработка конкретной реализации достаточно полного набора Архитектурных принципов на основе существующего шаблона (см. ниже).
· Формирование Стратегии Соответствия Архитектуре, определяющей правила и рекомендации для оценки и выбора проектов в части их соответствия или несоответствия согласованной архитектуре, а также формальную процедуру проверки такого соответствия. Это похоже на жизненный цикл технологических стандартов германской архитектуры электронного правительства SAGA, и на правила использования стандартов: проект, который не полностью удовлетворяет всем обязательным стандартам, не может получить бюджетного финансирования.
Базовая Архитектура, в свою очередь, включает:
· набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);
· набор элементарных архитектурных элементов, которые используются как "строительные блоки" при построении конкретных решений;
· база данных стандартов (Standards Information Base).
Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур (см рис. 2.10) входящих в общий континуум определений.
В этом смысле компонента Базовой Архитектуры, содержащая набор служб и стандартов, является некоторой абстрактной реализацией ИТ-системы в целом. Архитектура Общих Систем реализуется путем выбора и интеграции определенных служб для формирования выделенных блоков, которые могут (возможно, повторно или в различных комбинациях) использоваться в различных функциональных областях, таких как архитектура безопасности, сетевая архитектура и т.п.
Следующая степень детализации реализуется на уровне Отраслевой Архитектуры, которая добавляет специфичные для каждой индустрии модели данных, приложения, стандарты, бизнес-правила, а также, при необходимости, процедуры взаимодействия различных отраслевых систем между собой. Наконец, на последнем уровне Архитектуры Организации формируется архитектура ИТ-систем конкретного предприятия, учитывающая все его особенности, в том числе наличие унаследованных систем, планы и возможности реализации, организацию данных на физическом уровне и т.п.
Рис. 2.10. Иерархия описаний архитектур
В состав Эталонной Модели, в свою очередь, входит система (таксономия) общих служб, включающая такие службы, как Обмен и преобразование данных, Управление данными, Поддержка интернационализации, Службы Каталогов и т.п.
Для всех используемых в архитектуре служб, наряду с функциональным назначением, необходимо определить и уровень качества реализации, то есть такие характеристики как управляемость, гибкость, гарантированность, удобство использования и т.п. При этом следует учитывать, что некоторые службы являются в этом плане взаимозависимыми. Например, для обеспечения заданного качества службы интернационализации могут потребоваться специализированные компоненты службы разработки программного обеспечения для создания и тестирования соответствующих программных продуктов.
Архитектурные принципы представляют собой как бы фундаментальные "аксиомы", которые используются в качестве "отправных точек" как для оценки существующей системы, так и для разработки отдельных архитектурных решений. Вообще говоря, архитектурные принципы являются подмножеством более общего понятия ИТ-принципов, которые определяют основные аспекты всей деятельности, связанной с применением информационных технологий. ИТ-принципы, в свою очередь, являются детализацией еще "более общих" принципов, определяющих деятельность предприятия в целом.
В состав набора принципов могут входить обоснования для формирования системы требований или критериев оценки тех или иных решений. Например, такой принцип, как "минимизация числа поставщиков программного обеспечения", может быть в дальнейшем конкретизирован в зависимости от особенностей предприятия, как требование "единой СУБД для всех критичных для бизнеса приложений" или же как "использование той же СУБД, что и уже применяемая". Архитектурные принципы могут также использоваться для обоснования значимости самого понятия Архитектуры и необходимости ее разработки для бизнеса предприятия, а также для выбора вариантов реализации этого процесса.
Принципы являются взаимозависимыми и должны применяться в целостном наборе. "Хороший" набор принципов должен удовлетворять таким естественным критериям, как доступность для понимания, точность формулировок, полнота, последовательность и стабильность (не нужно путать с неизменяемостью!) Обычно число принципов не превышает 20, чтобы не ограничивать гибкость архитектуры или чтобы избежать чисто формального определения принципов, которые неработоспособны на практике.
Примерный набор принципов может включать, в частности, следующие:
Таблица 2.3.
Примеры принципов, используемых при создании архитектуры (TOGAF)
| Название | Содержание |
| Примат использования | Сформулированные принципы управления ИТ применимы для всех случаев и подразделений организации |
| Максимальная польза | Решения в области ИТ принимаются исходя из максимума пользы для организации в целом |
| Привлечение всех | Управление информацией есть дело каждого |
| Непрерывность бизнеса | Деятельность предприятия должна обеспечиваться, несмотря на возможные помехи в работе ИТ |
| Общее использование | Предпочтение должно отдаваться разработке или внедрению приложений, применимых в масштабах всего предприятия, а не отдельных его подразделений |
| Соответствие законодательству | Управление ИТ не должно противоречить применяемому законодательству и принятым регламентам, однако это не есть препятствие к улучшению бизнес-процессов, влекущему за собой изменение этих регламентов |
| Ответственность ИТ-службы | ИТ-служба является ответственным владельцем ИТ-ресурсов и исполнителем процессов для удовлетворения требований бизнеса |
| Защита интеллектуальной собственности | Обеспечение защиты интеллектуальной собственности организации должно быть реализовано на уровне архитектуры, процессов эксплуатации и управления ИТ |
| Данные являются активом | Данные в ИТ-системе предприятия имеют определенную ценность и должны соответственно управляться, быть общими и доступными для пользователей с учетом их прав доступа |
| Обеспечение качества | Каждый элемент данных должен иметь ответственного за качество |
| Общие метаданные | Метаданные должны быть едиными в рамках предприятия и доступными для всех пользователей |
| Безопасность данных | Данные должны быть защищены от неавторизованного использования и распространения |
| Технологическая независимость | Прикладное ПО не должно зависеть от специфичных моделей оборудования и системного ПО |
| Простота использования | Приложения позволяют сконцентрироваться на выполнении бизнес-задач за счет единого интерфейса, минимизации специфики работы, интеграции систем, снижения вероятности неправильного использования |
| Обоснованность и своевременность изменений | Изменения в информационной системе и приложениях производятся только в соответствии с запросами бизнеса, но в случае появления такой необходимости – в нужное время |
| Взаимодействие | Компоненты программного и аппаратного обеспечения должны обеспечивать интеграцию между собой в соответствии с общими стандартами |
| Минимизация разнообразия | Уменьшение числа различных вариантов применяемых платформ, продуктов и версий |
Набор шаблонов IT Architecture Toolkit, разработанный американской ассоциацией CIO, первоначально позиционировался как специализированное средство для документирования ИТ-архитектуры организации. Основное преимущество его использования заключается в построении иерархической системы описаний элементов, удобной для поддержания жизненного цикла документа, т.е. в форме, предполагающей его возможные изменения в будущем по мере изменения требований бизнеса и совершенствования технологий. Однако в версии 3.0, опубликованной в октябре 2004 года, предмет его рассмотрения уже охватывает и область бизнес-архитектуры, так что он может рассматриваться наряду с другими универсальными рамочными моделями. Другим весьма полезным обстоятельством является большое количество реальных примеров из практики отдельных американских штатов и федеральных организаций.
Для наших целей сравнительного анализа интересно проследить эволюцию данного подхода, поэтому вначале мы рассмотрим основные идеи, заложенные в версию 2.0. В этой версии структурная схема этой методики включала в себя пять уровней:
· области или домены (Domains) ИТ-архитектуры;
· дисциплины;
· технологические дисциплины;
· продуктовые компоненты;
· документы соответствия.
Области (домены) являются логическими блоками технологической архитектуры. Каждая Область может включать одну и более дисциплин. Вся ИТ-архитектура подразделялась на набор областей верхнего уровня (доменов), описывающих отдельные аспекты ИТ-систем. В составе списка доменов предлагалось выделять такие области, как:
· управление приложениями;
· управление данными;
· управление информацией;
· интеграция;
· управление пользователями и доступ;
· сети и коммуникации;
· платформы;
· управление системами;
· информационная безопасность и т.п.
Дисциплины обеспечивают логическое деление доменов на разделы, которыми уже проще управлять, т.е. домены включают в себя несколько функциональных дисциплин. Дисциплины представляют собой достаточно связанные единицы в рамках соответствующей предметной области. Каждая дисциплина содержит одну и более Технологических дисциплин.
Например, в домен Управление системами входят, в том числе, следующие дисциплины:
· Управление активами (Asset management).
· Управление изменениями (Change management).
· Управление событиями (Event Management).
· Поддержка пользователей (HelpDesk).
· Обеспечение непрерывности бизнеса (Business continuity) и др.
Технологические дисциплины – это технические дисциплины, которые поддерживают функциональные технологические разделы архитектуры. В качестве примера (см. табл. 2.3 ниже) можно привести Дисциплину "Управление данными" (Data Management), которая является частью Области "Информация". Дисциплина "Управление Данными" может включать в себя такие Технологические Области, как:
· реляционные СУБД;
· плоские файловые системы;
· настольные базы данных;
· модели данных.
Каждая из этих технологических областей включает свои продукты, протоколы и связанные с ними конфигурации. Это детализируется на уровне "Продуктовые компоненты". С указанного уровня начинаются технические детали технологической архитектуры.
Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической области. Примерами Продуктовых Компонент, которые могут быть идентифицированы в рамках технологической области "Модели Данных", являются такие продукты, как ERWin, Visio и Designer 2000. Документация для каждой компоненты включает оценочные критерии, которые были использованы для включения продуктовой компоненты в общую технологическую архитектуру.
Документы Соответствия определяют руководства, стандарты и регулирующие документы, которые связаны с Дисциплинами, Технологическими дисциплинами и/или Продуктовыми компонентами. Они предписывают необходимость соблюдения тех или иных международных рекомендаций (RFC), стандартов, законодательных актов – например, по применению сертифицированных средств ЭЦП, внутренних инструкций и т.п.
Документы соответствия могут присутствовать на каждом из этих уровней и обеспечивают основу для принятия важных решений о новых продуктах, протоколах, конфигурациях и т.д.
Для элементов описания архитектуры в документе определяется следующее:
Таблица 2.1
Элементы описания архитектуры
| Область (домен) | Описание, область охвата, входящие функциональные области, принципы, лучшие практики, тренды |
| Дисциплина | Описание, область охвата, ссылка на Домен, кросс-ссылки на другие функциональные области, методологии, Технологические Области, требования к документированию |
| Технологическая дисциплина | Описание, ссылка на функциональную область, обоснование выбора единственного или множественных продуктов (вендоров, приложений) |
| Продукты/приложения | Описание, ссылка на Технологическую область, информация о вендоре, классификация, условия использования, политика миграции |
Важным преимуществом такого подхода является возможность представления всего описания архитектуры в виде единой (гипертекстовой) базы данных, что позволяет эффективно организовать процессы управления жизненным циклом отдельных документов (см. ниже), а также эффективно разграничить права доступа к отдельным разделам (например, документам, описывающим применяемые средства защиты информации) при сохранении целостности и единства описания. Пример приведен в табл. 2.2.
Таблица 2.2.
Пример иерархии описания архитектуры в соответствии с рекомендациями NASCIO
| Область (Домен) | Дисциплина | Технологическая дисциплина | Продуктовые компоненты | Документы Соответствия |
| Информация | Управление Данными | реляционные СУБД | MS SQL Oracle DB2 | стандарты предприятия на именование хранимых процедур |
| плоские файловые системы | квоты на использование общего дискового пространства | |||
| настольные БД | MS Access | стандарты предприятия по защите БД Access | ||
| модели Данных | ERWin MS Visio Designer 2000 | нормализация данных стандарты предприятия на именования таблиц и атрибутов |
В таблице 2.3 дан пример модели технологической архитектуры, включающей в себя девять Областей, которые, в свою очередь, разбиты на 26 технических функциональных элементов или Дисциплин. Каждая организация должна определять свой набор технических дисциплин в зависимости от потребностей, но приведенный пример может служить отправной точкой.
Таблица 2.3.
Области и Дисциплины
| Область | Дисциплины |
| Информация |
|
| Приложения |
|
| Интеграция |
|
| Доступ |
|
| Сеть |
|
| Платформа |
|
| Системное Управление |
|
| Частная информация |
|
| Безопасность |
|
В версии 3.0 набор включает в себя как процесс управления ИТ (IT Governance), так и следующие 4 взаимосвязанные архитектуры:
· бизнес-архитектуру;
· архитектуру информации;
· технологическую архитектуру (практически соответствует всей ИТ-архитектуре, рассмотренной в версии 2);
· архитектуру решений (Solution Architecture), поэтому структура модели частично изменилась.
В частности, в составе собственно бизнес-архитектуры предлагается выделить несколько бизнес-областей (доменов). Это разделение может производиться как по функциональному (например, образование /здравоохранение /социальное обеспечение), так и по некоторому "тематическому" признаку (например; услуги гражданам/взаимодействие с другими органами власти/внутренние процессы) или географическому признаку. В составе этих бизнес-доменов выделяются отдельные архитектурные компоненты, рассмотрение которых может вестись с различных "перспектив", соответствующих столбцам в модели Захмана и с фокусом на двух верхних уровнях (строках) этой модели. В руководстве указывается на возможную целесообразность объединения таких перспектив, как "Кто?" и "Зачем?", вообще говоря, различных с точки зрения модели Захмана, в одну общую – "Стратегический бизнес". Важно отметить, что одни и те же выбранные перспективы должны будут применяться ко всем бизнес-областям.
Для каждой бизнес-области в описании определяются существенные принципы, лучшие практики и существующие тенденции. Далее, в составе бизнес-области формируются подчиненные документы, описывающие ее компоненты, которые фактически соответствуют отдельным ячейкам в верхних двух уровнях модели Захмана. Таким образом, в состав компонент могут входить, например, описание ролей (должностей) и их ответственности в организации, важные с точки зрения предприятия события и циклы деятельности, расположения офисов и т.п. Важным атрибутом описания является индикация типа состояния компоненты, т.е. относится ли это описание к существующему или целевому состоянию. Здесь прослеживается некая аналогия с подходом группы Зиндера и выделением "стратегического времени", хотя и в ограниченной интерпретации из всего двух состояний.
Специальным типом компоненты являет так называемая Gap-компонента, которая описывает существующие расхождения между текущим и целевым состоянием. Эти компоненты не случайно выделены в отдельный тип, поскольку одна и та же "причина", такая, например, как используемая устаревшая технология доступа к данным, может оказывать влияние на целый ряд основных компонент, в том числе из различных функциональных или тематических бизнес-областей. Описания этих основных компонент и описания gap-компоненты дополняются соответствующими кросс-ссылками, позволяющими осуществлять необходимую навигацию.
Представленный ранее в предыдущей версии руководства в рамках общей ИТ-архитектуры домен "Информация" в новой версии выделен в отдельную архитектуру информации. В ее составе определяются следующие элементы:
· основные информационные сущности (information subject areas), такие как, например, Гражданин/Услуга/Платеж, которые специфичны для деятельности данной организации;
· процессы обработки информации, описывающие, в частности, каким образом, кем и в каком порядке используется, например, сущность "Гражданин";
· метаданные, определяющие, какова логическая и физическая структуры данных, существующие или целевые бизнес-правила, уровень конфиденциальности, кто является владельцем/ответственным за качество и т.п. для данной сущности.
Кроме того, как и в случае бизнес-архитектуры, здесь явно выделяются Gap-компоненты.
Новым понятием, которое требует некоторого комментария, является архитектура решений. В данном контексте под ней понимается "процесс в рамках общей архитектуры предприятия, который фокусируется на создании сервиса или решения в интересах всей организации". Фактически эта область во многом соответствует понятию слоя шаблонов из модели Gartner, которая рассматривалась выше.
В отличие от остальных архитектур, описания элементов архитектуры решений не содержат такого признака, как "существующий" или "целевой". Фактически, все эти "решения" относятся как раз к стадии перехода от существующего состояния к целевому , так что по завершении соответствующего проекта они сохраняются со статусом "архивный".
Для описания конкретного решения используются три типа шаблонов:
· "обзор" (scope) – определяет область проекта, цели и подход;
· "требования" – содержит формализованные требования к решению, сгруппированные по типу, т.е. бизнес-требования, функциональные, по безопасности и т.п. В этой части организация шаблона схожа с разделом отечественного стандарта ГОСТ 34.698-90 "Техническое задание на АС";
· "дизайн" – документирует существенные элементы предложенного решения, включая явные ссылки на соответствующие требования и другие существующие элементы бизнес-архитектуры, архитектуры информации или технологической архитектуры.
Как уже отмечалось выше, наряду с описанием элементов архитектуры, в ходе процесса разработки определяется реализация применительно к конкретным особенностям предприятия стандартных процессов поддержки жизненного цикла архитектуры. К этим процессам относятся, в частности, такие:
· документирование;
· рецензирование;
· информирование;
· изменение;
· проверка соответствия;
· поддержка актуальности;
· организация и управление разработкой архитектуры, включая построение системы "IT Governance".
Диаграммы процессов строятся применительно к набору типовых предопределенных ролей (например, Рецензент, Документатор, Лидер и т.п.), которые присваиваются отдельным сотрудникам, должностям или подразделениям. Эти роли определяют права и ответственность данных участников процесса.
Модель "4+1" представления архитектуры
Достаточно важную роль в развитии подходов к описанию архитектуры предприятия сыграла модель "4+1" (точнее "The 4+1 View Model of Architecture"), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational еще в 1995 году. Данная методика позиционировалась, прежде всего, как способ описания архитектуры систем, основанных на активном использовании программного обеспечения, хотя идеи, заложенные в эту методику, могут использоваться и в более широком контексте архитектуры предприятия – что, собственно, и произошло на практике.
Рис. 2.11. Модель "4+1"
Модель предлагает простой и понятный способ описания архитектуры сложных систем, который состоит в использовании пяти различных категорий или представлений (views). Четырьмя основными представлениями в этой методике являются следующие:
· Логическое представление. Является объектной моделью проектирования (в том случае, если используется объектно-ориентированная модель проектирования).
· Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
· Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
· Представление уровня разработки. Описывает статическую организацию программной системы в среде разработки.
Описание архитектуры системы на основе этих четырех представлений иллюстрируется и проходит проверку путем использования еще одного представления, которое содержит некоторые отобранные сценарии использования (use cases). Архитектура системы во многом определяется этими сценариями. Каждое представление отражает специфические аспекты моделируемой системы.
Основной целью логического представления в данной методике является описание функциональных требований: что система должна выполнять в терминах конечных пользователей. Для этого представления используются различные абстрактные конструкции, такие как объекты и классы объектов. Для их иллюстрирования могут применяться диаграммы классов (в нотации языка UML) либо, например, диаграммы "сущность-связь", если в разработке приложения доминируют данные.
Процессное представление учитывает некоторые нефункциональные требования к системе, включая производительность и доступность. С помощью этого представления рассматриваются такие аспекты, как одновременное выполнение и распределение процессов, интеграция системы, устойчивость к сбоям, а также то, как основные объекты абстракции, рассмотренные на уровне логического представления, соответствуют архитектуре процессов. Архитектура процессов может быть представлена на различных уровнях абстракции. На самом высоком уровне система рассматривается как набор независимо выполняемых сетей взаимодействующих между собой программ. На более низких уровнях рассматриваются процессы и задачи.
Представление уровня разработки описывает фактическую организацию модулей системы, разделение ее на подсистемы, которые могут разрабатываться независимо.
Физическое представление, в основном, рассматривает нефункциональные требования, такие как доступность, надежность, устойчивость, производительность, масштабируемость. Этот уровень описывает распределение различных элементов – сетей, процессов, задач и объектов – по различным узлам (элементам аппаратного обеспечения, объединенным в сеть).
Сценарии объединяют все представления вместе. Сценарии использования описываются как последовательность взаимодействия объектов и процессов. Они отражают наиболее важные требования, которым должна удовлетворять система. Это представление в каком-то смысле является избыточным и пересекается с четырьмя предыдущими, но оно важно по следующим причинам:
· Сценарии использования позволяют идентифицировать элементы архитектуры, которые требуются для эффективно работающей системы.
· С помощью сценариев можно выполнять проверку и иллюстрацию того, что архитектура является работоспособной и полной. Это также является основой для проведения тестирования архитектурного прототипа.
Дата: 2019-02-02, просмотров: 1694.
