Какая из методологий управления архитектурой предприятия является статичным фреймворком

Обновлено: 14.01.2025

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

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

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

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

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

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

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

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

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

Теперь детализировано рассмотрим каждый столбец.

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

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

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

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

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

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

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

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

Витрувий, архитектор времен Римской империи

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

Рис. 8.1. Общий контекст разработки Архитектуры предприятия

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

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

методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;
модель Захмана;
методика TOGAF;
методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini , переданных для публичного использования в 1996 году.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF ( Department of Defence Architecture Framework).

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

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

Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники ( IEEE – Institute of Electrical and Electronics Engineers ), международная организация стандартизации ( ISO – International Organization for Standardization ), The Open Group и т.д. Но ни один из этих стандартов не занимает доминирующего положения . Более того, ни один из них, взятый в отдельности, не дает группам, ответственным за разработку архитектуры, всех инструментов, необходимых с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора архитектурных моделей, примеров и опыта различных индустрий [5.2].

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

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

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

достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем;
простоту для понимания бизнес-аудиторией;
динамику рассмотрения (т.е. "Архитектура как есть" – "Краткосрочные и среднесрочные задачи" – "Стратегические планы");
возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.

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

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

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

Принципы (система ценностей и постулатов)

Первое определение говорит о том, что " архитектура – это описание некоторой сложной системы в определенный момент времени". Оно аналогично схемам описания и чертежам здания, города, сада или компьютерной сети. Этому определению архитектуры соответствует центральная секция таблицы . Данная часть таблицы описывает два представления архитектуры : существующее и будущее состояния. В лекциях 10-12, посвященных организации архитектурного процесса, мы отдельно обсудим, как должны, с точки зрения затрачиваемых усилий, соотноситься эти два представления архитектуры .

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

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

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

Содержание

Обзор

Название «Zachman Framework» относится к Zachman Framework для корпоративной архитектуры, самой последней из которых является версия 3.0. За свою тридцатилетнюю историю Zachman Framework эволюционировала и включает:

Коллаж Zachman Frameworks, представленный в нескольких книгах по архитектуре предприятия с 1997 по 2005 год.

В других источниках фреймворк Захмана представлен как фреймворк, созданный Джоном Захманом и названный в его честь, представленный множеством способов, см. Изображение. Эта структура объясняется, например, как:

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

История

Фреймворк «Архитектура информационных систем»

Оригинальная "Структура архитектуры информационных систем" 1987 года.

Расширение и формализация

Соавтор Джона Захмана Джон Сова предложил дополнить перспективу «Объем» для «планировщика» (ограничивающие списки, общие для предприятия и его среды) и перспективу «Подробное представление» для «субподрядчика» (которая является решением поставщика вне контекста. составные части). Столбцы «Кто», «Когда» и «Почему» были представлены публике, понятие четырех уровней метафреймворков и описание интеграционных ассоциаций в разных точках зрения были изложены в документе. Кери Андерсон Хили помогла создать модель моделей (метамодель фреймворка), которая также была включена в статью.

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

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

В 2008 году компания Zachman Enterprise представила Zachman Framework: официальное краткое определение в качестве нового стандарта Zachman Framework.

Расширенные и модифицированные фреймворки

С 1990-х годов было предложено несколько расширенных фреймворков, таких как:

Темы Zachman Framework

Концепция

Просмотры строк

Текущая версия (3) Zachman Framework классифицирует строки следующим образом:

Исполнительная перспектива (Содержание) - Первый архитектурный эскиз - "пузырьковая диаграмма" или же Диаграмма Венна, который в общих чертах отображает размер, форму, частичные отношения и основное назначение окончательной конструкции. Он соответствует резюме для планировщика или инвестора, которому нужен обзор или оценка объема системы, ее стоимости и того, как она будет соотноситься с общей средой, в которой она будет работать.
Перспектива управления бизнесом (Бизнес-концепции). Далее следуют чертежи архитектора, которые изображают финальное здание с точки зрения владельца, которому придется жить с ним в повседневных делах. Они соответствуют корпоративным (бизнес-моделям), которые составляют структуру бизнеса и показывают бизнес-сущности и процессы, а также их взаимосвязь.
Перспектива архитектора (Системная логика) - планы архитектора представляют собой перевод чертежей в подробные представления требований с точки зрения дизайнера. Они соответствуют модели системы, разработанной системным аналитиком, который должен определить элементы данных, логические потоки процессов и функции, представляющие бизнес-объекты и процессы.
Перспектива инженера (Технологическая физика) - Подрядчик должен перерисовать планы архитектора, чтобы представить перспективу строителя с достаточной детализацией, чтобы понять ограничения инструментов, технологий и материалов. Планы разработчика соответствуют технологическим моделям, которые должны адаптировать модель информационных систем к деталям языков программирования, устройств ввода / вывода (I / O) или другой необходимой вспомогательной технологии.
Перспектива техника (Компоненты инструмента) - субподрядчики работают с планами магазина, в которых указываются детали деталей или подразделов. Они соответствуют подробным спецификациям, которые даются программистам, которые кодируют отдельные модули, не заботясь об общем контексте или структуре системы. В качестве альтернативы они могут представлять подробные требования к различным коммерчески готовые (COTS), готовое государственное оборудование (GOTS)или компоненты программного обеспечения модульных систем, которые закупаются и внедряются, а не создаются.
Перспектива предприятия или (Экземпляры операций)

Фокус столбцов

Наборы инвентаря - Что
Технологические потоки - как
Распределительные сети - Где
Назначение ответственности - Кто
Циклы синхронизации - когда
Мотивационные намерения - почему

Модели ячеек

Описания ячеек взяты непосредственно из Zachman Framework версии 3.0.

(Что) Идентификация инвентаря
(Как) Идентификация процесса
(Где) Идентификация распределения
(Кто) Определение ответственности
(Когда) Определение времени
(Почему) Определение мотивации

(Что) Определение инвентаря
(Как) Определение процесса
(Где) Распределение Определение
(Кто) Определение ответственности
(Когда) Определение времени
(Почему) Определение мотивации

(Что) Представление инвентаря
(Как) Представление процесса
(Где) Представительство о дистрибуции
(Кто) Заявление об ответственности
(Когда) Время представления
(Почему) Представление мотивации

(Что) Спецификация инвентаря
(Как) Спецификация процесса
(Где) Спецификация распространения
(Кто) Спецификация ответственности
(Когда) Спецификация времени
(Почему) Спецификация мотивации

(Что) Конфигурация инвентаря
(Как) Конфигурация процесса
(Где) Конфигурация распространения
(Кто) Конфигурация ответственности
(Когда) Настройка времени
(Почему) Конфигурация мотивации

(Что) Инвентаризация
(Как) Обработка экземпляров
(Где) экземпляры распространения
(Кто) Ответственность
(Когда) Создание экземпляров времени
(Почему) Мотивационные экземпляры

Рамочный набор правил

Правило 1 Столбцы не имеют порядка : Столбцы взаимозаменяемы, но не могут быть уменьшены или созданы
Правило 2 У каждого столбца есть простая общая модель : У каждого столбца может быть своя метамодель
Правило 3 Базовая модель каждой колонны должна быть уникальной. : Базовая модель каждого столбца, объекты отношений и их структура уникальны. Каждый объект отношения взаимозависим, но цель представления уникальна.
Правило 4 Каждая строка описывает отдельную, уникальную перспективу : Каждая строка описывает представление конкретной бизнес-группы и является уникальным для нее. Все строки обычно присутствуют в большинстве иерархических организаций.
Правило 5 Каждая ячейка уникальна : Комбинация 2, 3 и 4 должна давать уникальные ячейки, где каждая ячейка представляет конкретный случай. Пример: A2 представляет результаты бизнеса, поскольку они представляют то, что в конечном итоге должно быть построено.
Правило 6 Объединение или интеграция всех моделей ячеек в одной строке составляет полную модель с точки зрения этой строки. : По той же причине, что и для отказа от добавления строк и столбцов, изменение имен может изменить фундаментальную логическую структуру Framework.
Правило 7 Логика рекурсивна : Логика взаимосвязана между двумя экземплярами одной и той же сущности.

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

Гибкость в уровне детализации

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

Приложения и влияния

Настройка

Zachman Framework применяется в специализированных фреймворках, таких как ЧАЙФ, построенный на аналогичных фреймворках, Матрица TEAF.

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

Стоит отметить основные этапы разработки архитектура компании:

Определение и обоснование цели архитектуры.
Анализ текущего состояния архитектуры.
Анализ рисков.
Разработка плана миграции.
Управление реализацией проекта внедрения.
Выполнение намеченного плана.

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

Фреймворк Захмана – первый и самый известный фреймворк.
FEAF- разработанный в США для правительственных нужд фреймворк.
TOGAF- международный фреймворк, разработанный сотнями компаний, которые входят в единую организацию.
EAF- фреймворк разработанный на основе TOGAF компанией SAP.

Рассмотрим более детально приведенные выше фреймворки, как наиболее популярные.

Методология TOGAF представляет собой инфраструктуру архитектуры предприятия, которая появилась 20 лет назад для разработки стандарта архитектуры предприятия. Фреймворк разработан независимым консорциумом The Open Group, для установки открытых стандартов в области информационных технологий.

TOGAF включает в себя 7 частей:

Введение. Описание ключевых концепций.
Методы разработки архитектуры.
Руководящие принципы и методы.
Содержимое фреймворка архитектуры.
Континуум предприятия и инструменты.
Эталонная модель TOGAF.
Архитектурная возможность фреймворка.

Архитектура предприятия в TOGAF разделена на четыре домена (рис. 1)

Рисунок 1. – Компоненты архитектуры предприятия по TOGAF

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

Архитектура информационных систем описывает, как устроена ИС в компании. Обычно делится на две части:

Архитектура данных;
Архитектура приложений.

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

Структура ADM включает в себе 10 этапов:

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

Рисунок 2 – Схема TOGAF ADM.

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

Методология Захмана, как правило, представлена в виде таблицы имеющей 5 строк и 6 столбцов, которая представлена на рисунке 3.

Рисунок 3- Модель Захмана.

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

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

В основе FEA лежат пять эталонных моделей:

Исполнительная модель.
Бизнес-модель.
Сервисная модель Компонента.
Техническая эталонная модель.
Эталонная модель данных.

Одно из полезных свойств фреймворка FEA – принцип сегментного подхода, дает возможность ускорить внедрение «Архитектуры предприятия».

Процесс разработки архитектуры предприятия по методологии FEA изображен на рисунке 4.

Рисунок 4- Процесс разработки архитектуры по FEA.

Данная методология применима и за пределами государственного сектора экономики.

Методология Garther – по сути своей не является методологией, как например структурированная модель Захмана, ни процессом как TOGAF, ни как FEA. Garther – является набором практических рекомендаций. Данная методология является сборником советов по построению архитектуры предприятия от одной из наиболее известных в мире консалтинговых ИТ-компаний – Garther. Данный фреймворк представляет собой трехмерный куб, состоящий из слоев:

Горизонтальные слои.
Вертикальные домены.
Вертикальные элементы технической архитектуры.

Так как выше описанные методологии сильно отличаются друг от друга, следует задать критерии для их сравнения.

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

Каждой из методологий будет присвоена оценка по каждому из критериев от 0 до 5 (0 – непригодная для данной области, 5 –отлично работает в данной области)

В статье рассматриваются современные подходы в архитектуре предприятий, их особенности, достоинства и недостатки. Изучены фреймворк Захмана, подход TOGAF и методология компании “Gartner”.

Ключевые слова: архитектура предприятия, фреймворк, методы разработки, архитектурные подходы, управление предприятием

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

Родоначальником современных архитектурных подходов является Джон Захман с его методологией (фреймворком), которую он опубликовал в 1987 году. Суть ее заключается в том, что стадии жизненных циклов элементов относятся к точке зрения определенного представителя организации. Участники отвечают на одинаковые вопросы, расположенные в столбцах таблицы, но с различным уровнем абстракции. В целом архитектура представлена в виде матрицы, представленной на рисунке 1.

Рис. 1. Матрица архитектуры предприятия Захмана

Достоинства и недостатки подхода Захмана

Достоинства

Недостатки

простота и полнота понимания

отсутствие оси времени, для видения динамики развития организации.

бедность описания с технических позиций.

Один из самых известных архитектурных фреймворков это TOGAF . Он продвигается как методология архитектуры предприятия. Ядро этого фреймворка представлено методом разработки архитектуры (Architecture Development Method) или ADM. С точки зрения определения общего языка, у TOGAF есть два важных элемента.

Структура архитектурного контента (Architecture Content Framework) — выделяет набор ключевых артефактов, произведенных для поддержки архитектуры
Техническая эталонная модель (Technical Reference Model) — предоставляет модель и систематику общих сервисов на платформе.

TOGAF получил широкое распространение в индустрии за рубежом и в России. Большинство архитекторов предприятий стремятся получить его аккредитацию, однако нельзя сказать, что TOGAF это эталон проектирования, он довольно часто подвергается критике последователями других методологий. Схема представлена на рисунке 2.

Рис. 2. Структура разработки архитектуры по TOGAF

Достоинства и недостатки подхода TOGAF

Достоинства

Недостатки

Наличие метода разработки (ADM)

Высокий уровень абстракции, нет практической реализации

Свободное распространение и бесплатное использование для внутренних проектов

Отсутствие оценки качества архитектуры

Довольно известной методологией является архитектурный фреймворк от “Gartner” . Он разработан для поддержки принятия решений в организации при планировании развития архитектуры предприятия. Его использование предполагает оценку нынешнего состояния компании, определение инвестиций в технологии и процедуры для достижения желаемого результата, а также план управления компанией в переходный момент. Основная цель методологии состоит в том, чтобы использовать «Текущее состояние» и «Будущее состояние» для выявления прогрессивных практик и ресурсов, необходимых для устранения разрыва между архитектурой текущего и будущего состояния. Это можно четко увидеть на рисунке 3.

Рис. 3. Структура разработки архитектуры

Весь процесс перехода от текущего состояния к желаемому определяется в 5 фаз:

− Анализ и организация процессов в компании

− Определение целевой архитектуры

− Документирование текущей архитектуры

− Проведения анализа расхождения между двумя состояниями

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

Сравнительный анализ архитектурных подходов

Критерий

TOGAF

Матрица Захмана

Gartner

Уровень Бизнес/IT согласованности

Руководство по эталонным моделям

Оценка зрелости процесса

Качество руководства по внедрению

Итого

По итогам анализа можно сделать следующие выводы:

Фреймворк Захмана — 6 баллов. Инновационный способ для конца XX века, который используется до сих пор на предприятиях, в связи с качеством систематизации и простотой внедрения. Сейчас метод устарел, так как он достаточно медленный в плане согласования, а скорость имплементации постоянно повышается.

TOGAF — 17 баллов. Самый популярный на данный момент фреймворк имеет множество достоинств, в числе которых масштабируемость, совместимость и согласованность, на деле является сильно абстрактным. Предприятия внедряют лишь части фреймворка в конкретных ситуациях, не основывая всю архитектуру на данном методе.

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

Читайте также: