Аннотация: в статье ведется обзор методик построения архитектуры предприятия. Описываются виды и разновидности ИТ-архитектуры, обеспечивающей достижение стратегических целей организации. Анализируются модели Захмана и TEAF, а также рассматриваются методологии FEAF и TOGAF, позволяющие реализовать корпоративную архитектуру. Задаются отличительные особенности подходов к созданию ИТ-архитектуры, среди которых выделяются схема Захмана и TOGAF как наиболее представительные, кроме того, определяются области их применения. Формулируется вывод о схожести указанных подходов и возможности их использования как в коммерческих, так и государственных структурах.
Ключевые слова: корпоративная архитектура, архитектура корпоративной системы, архитектура корпоративных приложений, архитектура корпоративной информационной системы, архитектура корпоративных данных, концептуальная архитектура, концептуальный уровень архитектуры, проектирование ИТ архитектуры, архитектура ИТ решений, модель Захмана архитектура предприятия, методология FEAF, модель TEAF, TEAF, методология TOGAF, TOGAF ADM, TOGAF стандарт..
Скачать: PDF (статья).

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

Чем комплекснее проект внедрения ПО, тем более продуманные стратегии их доставки применяются: от миграции, тестирования и обучения, до тиражирования/пилотирования и Cutover (план перехода). Масштабное ПО помимо сложной имплементации так же требует бережного отношения к построению своего фундамента, то есть архитектуры [2].
Вопросам реализации архитектуры предприятия посвящено множество литературных источников. В последнее время укоренилась ассоциация вопросов ИТ-архитектуры с методологией TOGAF [3]. Как и любой другой свод знаний TOGAF предоставляет пошаговую инструкцию и рассматривает типовые проблемные вопросы построения корпоративной архитектуры. Однако, если присмотреться к данной методологии, можно заметить, что ее базис основывается на более ранних теориях.

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

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

1. Архитектура предприятия: определение, назначение и элементы

Введем ключевой термин, относящийся к рассматриваемой проблематике.

Определение 1. Архитектура предприятия (Enterprise architecture, EA) – это совокупность принципов, концепций, регламентов, стандартов и др., используемых для организации эффективной работы предприятия по достижению его стратегических бизнес-целей [4].

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

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

Работа над архитектурой в масштабе организации требует больших человеческих ресурсов, в связи с чем ее декомпозируют на виды и разновидности (табл. 1). Каждый вид/разновидность архитектуры предполагает независимые роли: архитектор по данным, архитектор по процессам (закупки, сбыт, производство и др.), архитектор по конкретному ПО, связующим звеном для которых является архитектурный комитет, модерируемый EA-архитектором [5].

Табл. 1. Области знаний
Вид архитектуры Объект описания Разновидности
Процессная Бизнес-процессы на 1-2 уровнях декомпозиции, карта процессов
Данные Мастер данные и НСИ, ER-диаграммы Миграционная
Приложения Программные системы (бизнес-приложения, офисные и др.) Концептуальная, интеграционная, функциональная/ компонентная, системная
Техническая Серверы, сайзинг, размещение ПО и др. Инфраструктурная, сетевая, информационной безопасности

Стратегические сессии, проводимые руководством компании, формируют понимание бизнес-потребностей организации, исполнение которых позволит достигнуть желаемых финансовых результатов. Синхронизируя потребности, строится TO-BE видение архитектуры предприятия, а также идентифицируются и приоритизируются инициативы, позволяющие ее достигнуть. Имплементация подобных инициатив ведется, следуя канонам проектного менеджмента, для чего ведутся активности по управлению проектом и изменениями, что дополняет задачи проектирования архитектуры (табл. 1). При этом существующие своды знаний PMBoK, BPM CBoK, DAMA-DMBoK, SWEBoK досконально описывают возможные проблемные области [6-9], в то время как вопросы проектирования корпоративной архитектуры детально освещены в модели Захмана и методиках FEAF, TEAF и TOGAF [10-11, 3].

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

Определение 2. Модель Захмана (Zachman framework) представляет собой фундаментальный онтологический подход для всестороннего анализа вопросов, связанных с архитектурой предприятия [10].

Основу модели Захмана представляет матрица размерностью 6×6, в которой каждая ячейка представляет собой результаты анализа, связанные с архитектурой предприятия. Строки матрицы представлены атрибутами/ролями:

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

а столбцы уточняют вопросы:

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

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

Табл. 2. Пример заполнения матрицы Захмана
Атрибут / вопрос Что (данные) Как (функции) Где (сеть) Кто (люди) Когда (время) Почему (мотивация)
Сфера действия (планировщик) Клиент, продукт, сделка Управление продажами РФ, СНГ Руководство, отдел продаж 6 месяцев Увеличение роста продаж на 20% в год
Бизнес-модель предприятия (владелец) Клиенты центрального региона РФ, FMCG-продукты, оптовые продажи Лид, квалификация, переговоры, сделка Офисы в 5 локациях Менеджер по продажам, администратор Еженедельные отчеты Сокращение цикла продаж на 30%
Модель системы (архитектор) ER-диаграммы клиентов, продуктов, сделок Модули управления клиентами, сделками и отчетности Веб-сервер, сервер БД и файл-сервер Роли для пользователей и техспециалистов Автосохранение каждые 15 минут Масштабируемость, надежность, гибкость
Технологическая/физическая модель (проектировщик) PostgreSQL Django REST Framework, React.js 3 сервера Учетные записи пользователей и администраторов Ежедневное резервное копирование в 03:00 Ограничения бюджета в 65 млн. руб.
Детали реализации (подрядчик) Классы данных для клиентов и заказов Алгоритмы расчета KPI для менеджеров IP адреса, порты, Firewall SOD-права для ролей пользователей Автоуведомление при изменении статуса сделки Скорость разработки
Работающее предприятие 500 записей клиентов, 1500 сделок в год Работающее CRM- приложение Серверы и дата-центры 100 менеджеров по продажам Круглосуточно Стратегия роста продаж на 20% в год

3. Методология FEAF

Определение 3. Методология федеративной корпоративной архитектуры (Federal Enterprise Architecture Framework, FEAF) представляет собой инструмент для перехода от изолированного управления разрозненными ресурсами к целостному ведению архитектуры правительства как единого организма [11].

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

  • планировщик;
  • владелец;
  • проектировщик;
  • строитель;
  • подрядчик,

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

  • данные;
  • приложения;
  • технологии,

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

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

  • двигатели архитектуры, описывающие источники изменения архитектуры: бизнес-стимулы (например, новые законодательство и инициативы Президента, бюджетные деньги для развития заданных сфер и др.) и технические стимулы (примером служат инновационные технологии для удовлетворения бизнес-потребностей);
  • стратегическое направление, представляющее собой видение по развитию архитектуры в горизонте 4-5 лет, согласованное с двигателями изменений;
  • текущая и целевая архитектуры;
  • переходные процессы, необходимые для реализации бизнес-операций в момент времени, когда уже произошел отказ от AS-IS архитектуры, но целевая TO-BE модель еще полноценно не заработала;
  • архитектурные сегменты, заданные уровнями данных, процессов, приложений и техники;
  • архитектурные модели, позволяющие описывать архитектурные сегменты согласно устоявшимся теоретическим практикам: ER-диаграммы для таблиц баз данных, графические нотации проектирования бизнес-процессов, карты процессов, схемы приложений и др.;
  • стандарты, представленные руководящими принципами, сводами знаний, методологиями, обеспечивающими реализацию TO-BE архитектуры.

Цель FEAF заключается в установлении единого подхода и унифицированного языка для описания, анализа и совершенствования структуры федеральных ведомств, их бизнес-процессов, информационных систем и технологий с фокусом на сквозные сервисы и непрерывную интеграцию [11].

4. Модель TEAF

Определение 4. Модель корпоративной архитектуры казначейства (Treasury enterprise architecture framework, TEAF) предлагает упрощенную структуру для категоризации заинтересованных лиц и аспектов архитектуры, а также рабочие продукты, обеспечивающие соответствие специфическим требованиям финансового госсектора [11].

Основной TEAF является матрица, решающая ключевые вопросы построения архитектуры от стратегических целей до технологической реализации, и представленная вопросами:

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

в разрезе представлений:

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

TEAF матрица наследует базовые концепции модели Захмана, но адаптирует их под нужды министерства финансов, что делает ее более практико-ориентированной и компактной [11].

5. Методология TOGAF

Определение 5. The Open Group Architecture Framework (TOGAF) представляет собой методологию непрерывного построения, контроля и улучшения ИТ-архитектуры предприятия [3].

Методология TOGAF включает метод разработки архитектуры ADM (Architecture Development Method) и дает рекомендации по его использованию согласно доменам знаний (табл. 3).

Табл. 3. Этапы работ над архитектурой согласно ADM
Этап Подэтап Ключевые задачи
Подготовка Предварительный
  • Бизнес-цели и задачи;
  • объем проекта (организационный, функциональный, системный);
  • ролевая модель для команды архитекторов;
  • архитектурные принципы.
  Архитектурное видение
  • Описание проблемы;
  • выявление бизнес-ограничений;
  • верхнеуровневое понимание AS-IS и TO-BE архитектуры (бизнес, данные, приложения и техника);
  • план коммуникаций.
  Управление требованиями
  • Обработка и управление требованиями к архитектуре;
  • ведение спецификации архитектурных требований.
Проработка архитектуры Бизнес-архитектура

Активности проводятся для каждого вида архитектуры отдельно:

  • Gap-анализ между AS-IS и TO-BE архитектурами и выявление требований;
  • оценка влияния прочих видов архитектур на рассматриваемую TO-BE архитектуру;
  • финализация TO-BE архитектуры;
  • предварительная дорожная карта для достижения TO-BE архитектуры.
  Архитектура данных
  Архитектура приложений
  Техническая архитектура
Планирование внедрения Планирование решения
  • Консолидация требований по результатам Gap-анализа четырех видов архитектур;
  • идентификация взаимозависимых требований;
  • определение временных архитектур для переходного периода;
  • группировка активностей для реализации требований от различных видов архитектур в пакеты работ;
  • предварительная дорожная карта для достижения TO-BE архитектур в разрезе пакетов работ.
  Планирование внедрения
  • Определение бизнес-ценностей и выгоды от пакетов работ;
  • расчет стоимости реализации пакетов работ;
  • объединение пакетов работ в проекты внедрения согласно получаемым выгодам;
  • финализация дорожной карты для достижения TO-BE архитектур в разрезе проектов внедрения;
  • подготовка детальных план-графиков для проектов внедрения.
Управление проектом внедрения Внедрение
  • Исполнение проекта внедрения;
  • контроль соответствия результатов проекта и TO-BE архитектур.
  Изменение архитектуры
  • Необходимо убедиться, что изменения архитектуры ведутся в соответствии с архитектурными принципами и работой архитектурного комитета.

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

6. Анализ архитектурных моделей и методологий

Рассмотрение моделей и методологий построения корпоративной архитектуры, представленные схемами Захмана и TEAF, а также фреймворками FEAF и TOGAF позволил выявить следующие их особенности:

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

Заключение

Многообразие подходов к построению корпоративной архитектуры обеспечивает возможность выбора тех методов и методологий, которые наилучшим образом позволяют решать прикладную задачу. Наличие проблемно-ориентированных методик FEAF и TEAF, предназначенных для государственных целей, а также обобщенных подходов, заданных моделью Захмана и TOGAF, демонстрирует отличительные области их применения. Проведение доскональной работы над архитектурой и детальное описание алгоритма ее построения/внедрения отличают рассмотренные модели Захмана и TEAF от методологий FEAF и TOGAF. Указанные подходы затрагивают лишь небольшую часть архитектурных практик, среди которых не были упомянуты NIST, EAP, TISAF, TAFIM, POSIX и многие другие. В связи с чем последующие исследования по данной тематике будут посвящены их детальному рассмотрению.

Список литературы

  1. Гвоздева Т.В., Баллод Б.А. Проектирование информационных систем: учебное пособие. – Ростов н/Д.: Феникс, 2009. – 508 с.
  2. Степанов Д.Ю. Основы теории корпоративных информационных систем // Высокопроизводительные вычислительные системы и технологии. – 2023. – т. 7, № 1. – c.147-152.
  3. Harrison R. TOGAF certified study guide. Van Haren Publishing, Zaltbommel, 2013. – 324 p.
  4. Грекул В.И. Проектирование информационных систем. М.: Юрайт, 2023. – 385 с.
  5. Степанов Д.Ю. Стратегия поддержки и развития внедренных ERP-систем (часть 2) // Корпоративные информационные системы. – 2025. – №4 (32) – c. 7-11. – URL: https://corpinfosys.ru/archive/2025/issue-32/299-2025-32-supportdevelopmentstrategies.
  6. A guide to the project management body of knowledge and the standard for project management, 7th edition. Project Management Institute, 2021. – 369 p.
  7. Свод знаний по управлению бизнес-процессами: BPM CBoK 4.0 / Бенедикт Т., Кирхмер М., Шарсиг М., Франц П., Саксена Р., Моррис Д., Хилти Д. – М.: Альпина Паблишер, 2024. – 504 с.
  8. DAMA-DMBoK: Свод знаний по управлению данными. Второе издание / DAMA International [пер. с англ. Агафонова Г.]. – М.: Олимп-бизнес, 2024. – 828 с.
  9. Washizaki H. Guide to the software engineering body of knowledge. Waseda University, IEEE Computer Society, 2024. – 413 p.
  10. Карандашев В.И. Модель Захмана и ее применение в проектах внедрения, поддержки и развития ERP-систем // Корпоративные информационные системы. – 2026. – №1 (33) – c. 21-27. – URL: https://corpinfosys.ru/archive/2026/issue-33/322-2026-33-zachman.
  11. Opengroup.org [Электронный ресурс] // Other architectures and architectural frameworks. Режим доступа: https://www.opengroup.org/architecture/togaf7-doc/arch/p4/others/others.htm (дата обращения 31.03.2026).
  12. Сорокин М.М. TOGAF для построения корпоративной архитектуры в ИТ-проектах по разработке и настройке программного обеспечения // Корпоративные информационные системы. – 2024. – №2 (26) – С. 1-9. – URL: https://corpinfosys.ru/archive/2024/issue-26/275-2024-26-togaf.

Выходные данные

Брит С.А., Гамбаров А.А., Карандашев В.И., Степанов Д.Ю. Модели и методологии построения корпоративной архитектуры // Аспирант и соискатель. – 2026. – т.153, №2. – c.6-13. – URL: https://stepanovd.com/science/article/210-2026-2-enterprisearchitecture. 

Статьи

Дипломные работы