Применение архитектурных подходов в сфере информационных технологий

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

2.2. Абстрактные модели архитектуры предприятия

Для описания предприятия, его бизнес-процессов, информационных систем и информации на каждом уровне абстракции могут использоваться как динамические, так и статические модели. Одной из наиболее общих моделей архитектуры предприятия является разработка Дж. Захмана. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира. Модель Захмана послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF), Методика описания архитектуры Open Group (TOGAF), Методика описания архитектуры министерства обороны США (DoDAF).

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

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

Рис. 2.6. Матрица Захмана

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

На рис. 2.6 представлена русская интерпретация англоязычной оригинальной модели (см. подробнее http://www.zachman.com/about-the-zachman-framework). Стоит обратить особенное внимание, что в оригинале данная матрица называется «framework», что в переводе означает «каркас или структура», что и определяет суть данного подхода: он не дает конкретных инструментов описания, зато предлагает определенную последовательность рассмотрения, которая позволяет при дальнейшем развитии получить описания определенной организации.

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

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

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

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

Аналогично, в применении к деятельности предприятия верхняя строка «Контекст» соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам менеджеров и владельцев процессов. Третий уровень - тот, на котором менеджеры, аналитики и ИТ-менеджеры должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.

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

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

Таблица (матрица) Захмана имеет и определенные правила заполнения:

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

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

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

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

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

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

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

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

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

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

Остановимся более подробно на том, как может использоваться такой подход на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и информационные системы этого предприятия, выявления "белых пятен" и координации работ. Во-вторых, данную модель можно использовать на метауровне - для сравнения различных реализаций создания архитектур предприятия. Наконец, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 - соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих "унаследованных" компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы.

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

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

Например, на основе модели Захмана выстроена методология TOGAF (The Open Group Architecture Framework), разработанная консорциуумом The Open Group). Она появилась в последние два десятилетия с целью стать стандартом разработки в данной сфере. Изначально данная методология не воплощала целостную концепцию архитектуры предприятия. Первоначально (версии с 1 по 7) TOGAF включала только технические аспекты архитектуры, однако недавно в эту инфраструктуру была добавлена предметная область архитектуры бизнеса (версия 8, Enterprise Edition),  в результате TOGAF быстро переместилась на передний план современных вариантов инфраструктур архитектуры предприятий.

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

Рис. 2.7. Архитектура предприятия в модели TOGAF

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

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

Кроме собственно структуры самой EA данный подход предлагает и конкретную методику ее построения (Architecture Development Method, метод ADM). В архитектурном смысле модель TOGAF дополняет подход Захмана. Последний показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.