Методики описания архитектур. Модели Захмана и Gartner, методики META Group и togaf

1. Модель Захмана

2. Cтруктура и модель описания ИТ-архитектуры Gartner

3. Методика META Group

4. Методика TOGAF

Модель Захмана

Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A. Zachman). С момента публикации "модель Захмана для описания архитектуры предприятия" прошла определенную эволюцию в своем развитии и стала основой, на базе которой многие организации создавали свои собственные методики описания информационной инфраструктуры предприятия. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как General Motors, Bank of America и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF – Federal Enterprise Architecture Framework), Методика описания архитектуры Open Group (TOGAF – The Open Group Architecture Framework), Методика описания архитектуры министерства обороны США (DoDAF – Department of Defence Architecture Framework). Отметим, что в данном случае в исторически сложившемся переводе названия на русский язык используется именно термин "модель", отражающий прежде всего четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала "framework" как "методики".

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

Итак, в своей работе [5.3] Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Термин "архитектура" здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС).

Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

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

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

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

Рис. 1. Модель Захмана

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

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

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

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

используемые данные (что?)

процессы и функции (как?)

места выполнения этих процессов (где?)

организации и персоналии–участники (кто?)

управляющие события (когда?)

цели и ограничения, определяющие работу системы (зачем?)

Сам Захман в своем интервью он-лайновому журналу "Enterprise Architect Online" без ложной скромности сравнил свою модель с периодической таблицей элементов Менделеева и назвал ее "периодической таблицей описательных представлений предприятия или двумерной системой, схемой классификации" [5.5]. Это действительно ко многому обязывающее сравнение, но Захман привел следующие аргументы в его пользу: "Вопросы что, как, где, кто, когда и зачем существуют тысячи лет. И они будут существовать еще тысячи лет. Требования к системам, процесс проектирования, производства или концептуальный, логический и физический уровень описания также существуют в течение тысяч лет и будут существовать еще тысячи лет. Логическая структура классификации, схема – неизменны".

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

Основные правила заполнения таблицы следующие:

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

порядок следования колонок несущественен;

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

базовые модели для каждой из колонок являются уникальными;

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

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

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

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

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

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

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

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

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

Так, первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" (E-R диаграммы) с отражением основных связей и наиболее существенных бизнес-ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе (в объектно-ориентированном подходе – иерархию классов). Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Наконец, последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п. Конечно, можно отметить определенное несовершенство данной модели при использовании объектно-ориентированного подхода – фактически модель предписывает раздельное рассмотрение данных (свойств) и функций (методов) классов.

Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление бизнес-процессов. Второй уровень будет содержать модель бизнес-процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках Предприятия в целом, а по отдельным подсистемам или приложениям.

Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой, – будь то обмен информацией или поставки товаров. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня (так называемое "middleware"), используемых для интеграции различных компонент информационной системы между собой. Типичным примером могут являться брокеры запросов или средства обмена сообщениями. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.

Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также могут быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли (в RUP используются диаграммы событий и описание вариантов использования), требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.

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

Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию.

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

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

Основными характеристиками данной модели Захмана, как отмечено в [5.6], являются следующие:

· простота для понимания как техническими, так и нетехническими специалистами;

· целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом;

· поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;

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

· применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого;

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

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

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

· облегчает понимание и общение людей, имеющих разные роли в процессах создания, развития и использования системы;

· ясно определяет фокус внимания на (относительно) независимых параметрах для целей анализа;

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

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

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

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

Тем не менее, существуют специализированные продукты, такие как Popkin Software Architect, которые фактически основаны на модели Захмана и позволяют достаточно эффективно управлять созданием моделей и артефактов описания архитектуры предприятия.

Соответствующее обобщение подхода Захмана было предложено в работах Е.Б. Зиндера [5.7]. Основная идея заключается в обеспечении возможностей отражения постоянного развития предприятия (и его информационных систем) как непрерывной последовательности трансформаций.

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

Таким образом, была создана "объемная" схема архитектуры предприятия или модель "3D-предприятие", которая строится в трех измерениях с учетом временного пространства.

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

Стоит отметить, что предложенный вариант развития исходного подхода Захмана не является единственно возможным. Существует большое количество модельных схем, которые в той или иной мере используют данный подход, хотя визуальное представление модели в целом может достаточно сильно отличаться. Одним из таких примеров может служить предложенная Институтом разработок архитектуры предприятия модель Extended Enterprise Architecture Framework (E2AF) [5.8]. Эта модель содержит 4 области рассмотрения (бизнес, информация, информационная система, технологическая инфраструктура) и следующие 6 уровней абстракции:

· контекстуальный (Зачем?)

· уровень взаимодействия (с Кем?)

· концептуальный (Что?)

· логический (Как?)

· физический (с помощью Чего?)

· трансформационный (Когда?)

Другой пример – это так называемая модель 4-доменной архитектуры (Four Domains architecture, FDA) [5.9], в которой предлагается, в частности, провести как бы условное разбиение ячеек исходной модели Захмана на 2 компоненты – архитектуру описания (Architecture-in-Design) и архитектуру исполнения (Architecture-in-Operation). При этом первая компонента описывает ход, средства и артефакты процесса разработки архитектуры предприятия, в то время как вторая предназначена для описания непосредственно бизнес-процессов и реализации ИТ-систем.

Cтруктура и модель описания ИТ-архитектуры Gartner

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

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

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

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

Раздел Протоколы и Стандарты описывает те промышленные протоколы и стандарты, которые должны поддерживаться используемыми в организации технологиями.

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

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

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

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

Билл Гейтс в своей книге "Бизнес со скоростью мысли" [5.12] дал следующее определение: "электронная нервная система есть совокупность электронных процессов, с помощью которых организации воспринимают мир и адекватно реагируют на изменения, происходящие в нем".

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:

· Среда бизнес-взаимодействия (Business Relationship Grid);

· Бизнес-процессы и стили бизнес-процессов;

· Шаблоны;

· Технологические строительные блоки (кирпичики – bricks).

Рис. 2. Уровни модели архитектуры Gartner

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

Рис. 3. Архитектура ИТ в бизнес-контексте

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

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

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

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

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

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

Полная модель [5.13] представляет собой "трехмерную" комбинацию бизнес-архитектуры, технической и информационной архитектур. При этом описанные выше слои среды бизнес-взаимодействия, стилей бизнес-процессов, шаблонов и строительных блоков пересекаются со слоями Информационной архитектуры (Домен данных, Домен приложений, Домен интеграции, Домен доступа) и Технической архитектуры (Домен инфраструктуры, Домен системного управления и Домен безопасности. По большому счету, "все пересекается со всем". Например, при построении прикладных систем могут использоваться шаблоны проектирования и строительные технологические блоки. При этом для управления прикладной системы используются технологии системного управления и также должны быть учтены вопросы безопасности.

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

Методика META Group

Подробное описание методики разработки архитектуры предприятия META Group содержится в документе Enterprise Architecture Desk Reference [5.14] объемом около 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).

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

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

На этапе 1 разрабатывается Видение общих требований. Разработка Видения общих требований включает в себя:

анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;

бизнес-стратегии и основные движущие силы с точки зрения бизнеса;

требования к информационным системам со стороны бизнеса;

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

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

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

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

Рекомендация относительно Видения общих требований состоит в том, что этот документ не должен обязательно быть исключительно точным и всеобъемлющим с точки зрения анализа бизнес-стратегии. Главное – это совместное участие представителей бизнес-подразделений и ИТ в выработке общего понимания набора требований, согласованных со стратегическим направлением развития компании. Размер этого документа может быть 10-15 страниц

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

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

Таким образом, результатом первого этапа работ могут быть четыре документа:

список ключевых технологических тенденций;

список бизнес-стратегий;

список требований к информационным системам;

список требований к технологической архитектуре.

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

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

принципы представляют собой содержательные утверждения, которые касаются архитектурного процесса или содержания архитектуры;

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

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

Мы уже отмечали, что в соответствии с методикой META Group результатом разработки принципов концептуальной архитектуры является выделение в технологической архитектуре (EWTA) набора доменов (предметных областей), которые объединяют группы связанных между собой технологий и компонент. При этом, можно выделить два различных типа доменов технологической архитектуры: базовые (технологии, которые используются практически каждой информационной системой: сети, аппаратное обеспечение, операционные системы, системы хранения, программное обеспечение промежуточного слоя, системы управления базами данных, технологии системного управления ИТ-ресурсами в распределенной среде, архитектура безопасности) и прикладные (более специфические с точки зрения использования бизнесом технологии: системы коллективной работы, электронной почты и управления потоками работ (workflow), Интранет, Интернет-приложения, системы электронной коммерции, архитектура хранилищ данных, специализированное аппаратное обеспечение).

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

На рисунке 6 приведена структура описания каждого домена технологической архитектуры предприятия, согласно META Group.

Рис. 8.7. Структура описания доменов технологической архитектуры

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

Формулировка миссии домена: стратегические цели домена.

Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.

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

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

Лучшие практики.

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

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

В ряде публикаций [5.15], [5.16] представления о технологической архитектуре META Group получили дальнейшее развитие и дополнены такими аспектами, как инфраструктурные шаблоны и инфраструктурные сервисы. Это связано с общей для индустрии ИТ тенденцией уделять большое внимание шаблонам проектирования, а также с развитием принципов сервис-ориентированной архитектуры.

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

Взгляд на технологическую архитектуру с точки зрения предоставляемых ею инфраструктурных сервисов обусловлен распространением принципов сервис-ориентированной архитектуры. Это связано с описанием, например, сервисов презентации информации (порталы, настольные системы и пр.), сетевыми сервисами (LAN, WAN, удаленный доступ), сервисами безопасности (управление пользователями, доступ), сервисами хранения данных (SAN – Storage Area Network, файловые системы), сервисами баз данных (OLTP), интеграционными сервисами, платформенными сервисами, которые используются прикладными системами.

При этом архитектурные домены, шаблоны и сервисы обеспечивают наращивание уровней адаптируемости технологий предприятия:

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

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

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

При этом выделяется четыре группы сервисов по мере повышения уровня абстракции:

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

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

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

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

В результате получается технологическая модель предприятия, представленная на рис. 7.

Рис. 7. Технологическая модель предприятия

В полном описании методики 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 [5.17] показана на рис. 8.

Рис. 8. Структура TOGAF

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

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

Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.

Фаза A: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.

Фаза B: разработка бизнес-архитектуры предприятия.

Фаза C: разработка архитектуры данных и архитектуры приложений.

Фаза D: разработка технологической архитектуры.

Фаза E: проверка возможности реализации предложенных решений.

Фаза F: планирование перехода к новой системе.

Фаза G: формирование системы управления преобразованиями.

Фаза H: управление изменением архитектуры.

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

Описание существующей технологической архитектуры.

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

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

Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.

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

Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.

Формирование целевой технологической архитектуры.

Описание существующей системы в терминах TOGAF.

Определение перспектив (представлений) архитектуры.

Формирование модели целевой архитектуры.

Определение ИТ-служб (сервисов).

Подтверждение учета бизнес-требований.

Определение архитектуры и используемых блоков (шаблонов).

Проведение анализа расхождений (gap analysis).

Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!

Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры (Implementation Governance). Так, фаза G предусматривает следующие задачи:

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

Разработка конкретной реализации достаточно полного набора Архитектурных принципов на основе существующего шаблона.

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

Базовая Архитектура, в свою очередь, включает:

набор наиболее общих служб и функций, объединенных в Техническую Эталонную Модель (Technical reference model – TRM);

набор элементарных архитектурных элементов, которые используются как "строительные блоки" при построении конкретных решений;

база данных стандартов (Standards Information Base).

Концепция использования Базовой архитектуры определяется в соответствии с иерархией архитектур (см рис. 9) входящих в общий континуум определений.

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

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

Рис. 9. Иерархия описаний архитектур

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

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

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

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

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

Дата добавления: 2013-12-13