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

Введение

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

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

С точки зрения непосредственно вопросов разработки архитектуры предприятия, большинство исследователей анализируют эволюцию архитектурного подхода, многообразие стандартов в этой сфере [11]. Вопросы построения архитектуры предприятия активно изучаются как российскими, так и зарубежными исследователями. Ученые рассматривают различные виды архитектур, включая бизнес-архитектуру, информационную архитектуру, архитектуру приложений, интеграционную и техническую архитектуру [2-8, 12]. Все эти категории объединяются в единую модель архитектуры предприятия.

В рамках разработки архитектуры предприятия учёные проводят комплексные исследования, направленные на анализ и оптимизацию структурного построения организаций. Д.В. Кудрявцев и М. Ю. Арзуманян рассматривают эволюцию архитектурного подхода, анализируя структуру архитектуры предприятия и её компонентов, а также сценарии применимости для компаний [7]. Их работа коррелирует с исследованиями зарубежных учёных, таких как Janne J. Korhonen и Marco Halen [12], которые также изучают развитие архитектурного подхода.

Л. И. Зинина и Л. И. Ефремова фокусируются на анализе доменов архитектуры и уровней абстракции, исследуя взаимосвязь между единой моделью архитектуры предприятия и корпоративными информационными системами, что позволяет выявить взаимозависимость между различными компонентами архитектуры и определить оптимальные подходы к её разработке [8].

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

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

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

К примеру, зарубежные авторы Х. Джонкерс, Х. Пропер и М. Тернер изучили модель интеграции двух методологий TOGAF ADM и ArhiMate [2], а компания Otus в своем блоге проанализировала возможности TOGAF ADM [4, 6].

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

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

Стандарты и фреймворки разработки архитектуры предприятия

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

В Российской Федерации принята серия стандартов по системной и программной инженерии, часть из которых имеют непосредственное отношение к трактовке понятия «архитектура предприятия». Стоит отметить стандарты ГОСТ 57100- 2016 «Системная и программная инженерия. Описание архитектуры» и ГОСТ Р ИСО 15704-2022 «Моделирование и архитектура предприятия. Требования к стандартным архитектурам и методологиям предприятия».

В соответствии с ГОСТ Р ИСО 15704 архитектура предприятия относится к организации физических компонентов, логических взаимосвязей и взаимодействию людей, вовлеченных в разработку, реализацию и функционирование программы, например, к интеграции предприятия или другому предприятию, использующему программное обеспечение, обычно включая ряд проектов [1]. Архитектура предприятия (Enterprise Architecture) используется для упорядочения процессов, технологий, данных и ресурсов в организациях.

На зарубежном уровне разработаны стандарты Zachman's Framework, The Open Group Architecture Framework (TOGAF), Federal Enterprise Architecture (FEA), Value Realization Framework (VRF) вместе с Simple Iterative Partitions (SIP) или VRF/SIP, Department of Defense Architecture Framework (DoDAF), Integrated Architecture Framework (IAF), Enterprise Knowledge Development (EKD) and Resources, Events and Agents (REA).

Согласно исследованию международной компании CompTIA, которая занимается сертификацией, обучением в области IT-технологий, наиболее распространенными из всех методологий являются TOGAF со спецификацией ArchiMate, Zachman, FEAF, MODAF. Рассмотрим их более подробно.

TOGAF (The Open Group Architecture Framework) — один из самых популярных фреймворков для построения корпоративной архитектуры, который разработан организацией The Open Group в 90-х годах прошлого века, является открытым стандартом, помогает организациям планировать, реализовывать и контролировать свои IT архитектурные изменения более эффективно.

Фреймворк TOGAF включает в себя четыре уровня. Бизнес-архитектура (Business Architecture) определяет стратегию бизнеса, управление, организацию и ключевые бизнес-процессы. Архитектура данных (Data Architecture) представляет структуру информационных ресурсов организации, включая логическую и физическую организацию данных, а также средства управления информацией. Архитектура приложений (Application Architecture) предоставляет план развертывания отдельных приложений, их взаимодействия и взаимосвязи с основными бизнес-процессами организации. Технологическая архитектура (Technology Architecture) описывает цифровую архитектуру, логические возможности, стандарты программной и аппаратной инфраструктуры, необходимые в качестве поддержки развертывания сервисов для бизнеса, данных и приложений.

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

­ метод разработки архитектуры TOGAF Architecture Development Method (ADM) – определение и описание стандартного цикла изменений;

­ фреймворк контента TOGAF (TOGAF Content Framework) – определение и описание основных элементов (строительных блоков);

­ набор рекомендаций, методик и советов по созданию и поддержанию эффективной архитектуры предприятия [6].

Практический интерес представляет TOGAF ADM, который описывает метод разработки и управления жизненным циклом корпоративной архитектуры. На всем его протяжении важно проверять соответствие получаемых результатов первоначальным ожиданиям. На рисунке 1 показано восемь этапов (A-H) в рамках цикла ADM.

Рис. 1 - Цикл разработки архитектуры [13]

Стоит отметить, что данные этапы объединяются в три группы: понимание, определение и управление. К группе «понимание» относятся этапы от A до D, к группе «определение» - этапы E и F, а к группе «внедрение» - этапы G и H. TOGAF ADM предусматривает выполнения этапов в различном порядке и предоставляет возможность пропускать некоторые из них, что делает этот метод более привлекательным для организаций, работающих по гибким методологиям. Преимуществом данного метода является интеграция с другими фреймворками, к примеру, с моделью Захмана, которую сейчас рассмотрим более подробно.

Модель Захмана (Zachman Framework, ZFEA), разработана основоположником корпоративной архитектуры Джоном Закманом. Модель ISA framework (Information Systems Architecture) представляет собой логическую структуру для организации данных, процессов и технологий в компании. Первым, кто применил данную модель - правительство США (Department of Defence), которые в последующем разработали отдельный стандарт на основе модели Захмана.

В настоящее время актуальна версия модели ZachmanV3, которая представляет собой матрицу 6x6 (рис.2). Колонки в ней отражают различные аспекты архитектуры, а строки представляют собой понятие овеществления — превращения абстрактной концепции в конкретное воплощение с помощью различных подходов. Шестая строка соответствует уровню работающей системы. Каждая ячейка таблицы отражает набор артефактов, или элементов архитектуры предприятия.

Рис.2 - Модель Закмана [14]

Основная идея матрицы состоит в определении последовательности заполнения, так как, заполнив одни ячейки, появляется возможность заполнить и другие недостающие «детали паззла». В результате специалист имеет простую для понимания модель другими специалистами любых направлений [15]. На базе идей, заложенных в модели Захмана, было разработано два стандарта ArchiMate и FEAF (Federal Enterprise Architecture Framework). Рассмотрим их особенности более подробно.

Графический язык ArchiMate содержит набор понятий для описания архитектуры предприятия и фреймворк, который представляет логическую структуру для классификации данной информации (рис. 3). Актуальная версия стандарта ArchiMate 3.2 вышла в 2022 году.

Рис. 3 - Отношения и структура элементов метамодели [16]

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

Рис. 4 - Слои фреймворка ArchiMate 3.2 [16]

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

1) активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия;

2) пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над которым выполняются действия;

3) элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.

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

Стандарт FEAF (Federal Enterprise Architecture Framework) разработан для описания архитектуры в Федеральных агентствах США. Назначение данного фреймворка заключалось в ускорении внедрения цифровых систем и инструментов, получения актуальной информации для внутриведомственного и межведомственного планирования и принятия решений.

Согласно последней версии FEAF v2 структура содержит пять референтных моделей [17]:

- PRM (Performance Reference Model) - эталонная модель, которая связывает стратегию компании, внутренние бизнес-компоненты, инвестиции и метрики, показывающие влияние на стратегические результаты; обеспечивает основу для остальной части FEAF;

- BRM (Business Reference Model) - эталонная бизнес-модель представляет собой стандартизированное описание бизнес-процессов и возможностей государственного управления; обеспечивает единое понимание деятельности государственных органов и помогает выявлять резервы для улучшения и инноваций;

- SRM (Service Component Reference Model) - эталонная модель услуг представляет собой описание услуг, предоставляемых государственными органами, включая функциональные и нефункциональные требования к услугам, принципы их проектирования, интеграции, развертывания и эксплуатации;

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

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

Референтные модели описывает 6 субархитектурных домена в FEAF: стратегия, бизнес, данные, предложения, инфраструктура, безопасность.

Рассмотрим еще один известный стандарт в области концепции «архитектуры решений» – MODAF (Ministry of Defence Architecture Framework) разработан Министерством обороны Великобритании для поддержки сложных военных систем. Данный стандарт организует информацию в серию представлений, которые подразделяются на различные точки зрения (рис. 5).

Рис. 5 - Точки зрения стандарта MODAF [18]

Стратегическая точка зрения (Strategic Viewpoint, StV) определяет желаемые результаты планирования возможностей и стратегическое направление. Операционная точка зрения (Operational Viewpoint, OV) описывает задачи, действия, операционные элементы и обмен информацией, необходимые для выполнения операций. Системная точка зрения (Systems Viewpoint, SV) указывает системы и их взаимосвязи, которые обеспечивают или поддерживают операционную деятельность. Закупочная точка зрения (Acquisition Viewpoint, AcV) связана с закупкой систем, включая временные рамки и стандарты. Техническая точка зрения (Technical Viewpoint, TV) устанавливает стандарты и правила, регулирующие услуги систем и их взаимодействие.

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

Практика разработки архитектурных решений на примере ПАО «Альфа-банк»

Как в Российской Федерации, так и на зарубежном пространстве присутствуют примеры разработки архитектуры предприятий в различных отраслях, к примеру, в отраслях розницы, химической и машиностроительной промышленности, ИТ и банковского сектора. К примеру, в компании «Prosleep Medic» [20], госкорпорации “Росатом” [21], а также частные банки РФ - ПАО “Сбербанк России” [22-23] и АО “Альфа-Банк” [24] и др. В качестве примера практического использования концепции «архитектуры решений» рассмотрим процесс разработки и интеграции решения в Альфа-банке.

Архитектура решения формируется на основе фреймворка TOGAF и используются инструменты графического стандарта ArchiMate. Конкретные диаграммы описаны по стандарту диаграмм контекста системы (System Context Diagram) в рамках модели C4 на первом уровне ArchiMate а также модели С4 2 уровня — Диаграммы содержания (Container diagram). В рамках рассматриваемого процесса обозначения адаптированы под специфику банка для лучшего понимания реализуемых изменений.

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

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

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

Одним из эффективных инструментов является построение диаграмм контекста системы (System Context Diagram) в рамках модели C4 на первом уровне (пример исходной диаграммы процесса приведен на рис. 6). Данный подход, адаптированный под восприятие заказчика и команды разработчиков, позволяет визуализировать взаимодействие целевой системы с ее IT-окружением, преодолевая разрыв в понимании технических аспектов, что обеспечивает более четкое определение требований и минимизирует риски недопонимания на этапе проектирования.

Рис. 6 - Исходная диаграмма процесса [23]

Предлагается методология проектирования интеграционных решений, эффективность которой подтверждена многократным применением. Методология базируется на использовании чек-листа, упрощающего процесс. Рассмотрим прикладную задачу: клиент банка обращается в контакт-центр (КЦ) для получения информации о своем счёте. Оператор КЦ использует приложение «Единое окно КЦ» для поиска необходимой информации и предоставления ответа клиенту. Несмотря на простоту бизнес-процесса, заказчик сталкивается с вопросами оценки стоимости разработки и определения ответственных команд.

Представим пошаговый алгоритм проектирования интеграции для данной задачи, основанный на использовании чек-листа. Сначала определяются use case (в переводе с англ. «сценарий использования»), который содержит, какие действия выполняет пользователь, и как система должна на них реагировать. В данной задаче можно выделить два сценария использования. Первый состоит из следующих шагов. Оператор контакт‑центра открывает приложение «Единое окно КЦ» и отвечает на вопрос клиента по счету, далее ищет карточку клиента, после этого оператор КЦ из карточки клиента находит информацию о его счетах и после этого информацию о конкретном счете. Второй сценарий использования состоит в том, что администратор приложения просматривает данные о работе системы при разборе инцидента. Далее определяются пользователи (user). В задаче участвуют два вида пользователей: оператор КЦ и администратор приложения. Определение пользователей позволяет понять, какие данные могут потребоваться для выполнения use case.

После этого пользователи и окно КЦ наносятся на диаграмму и определяются потоки данных. Оператору КЦ нужно видеть информацию о клиенте и данные о его счетах. Администратору необходимы знания, что оператор КЦ делал в системе, чтобы проанализировать почему произошла ошибка. Также будут полезны технические логи (от англ. Logs – записи) работы приложения. После того как потоки определены, определяем системы. Данные понятны, теперь необходимо определить места, откуда их можно получить или куда передавать. Эта самая сложная часть задачи, так как здесь требуются знания IT-ландшафта банка, архитектурных паттернов, принятых внутри компании. На этом шаге могут появиться несколько решений, так как сроки реализации и желание команд не всегда совпадает с потребностями заказчика. После того как основные составляющие диаграммы готовы, определяется легенда данной диаграммы, которая располагается под диаграммой, что позволит командам сразу оценивать доработки, которые необходимо будет реализовать.

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

На примере рассматриваемой практической задачи возможно осуществить детализацию приложения «Единое окно КЦ». Предположим нам требуется создать два новых модуля по клиентам и счетам и доработать основное приложение (рис. 7).

Рис. 7 - Переработанная диаграмма процесса [23]

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

- определить объем необходимых работ и, следовательно, приблизительную стоимость проекта;

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

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

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

Результаты

В ходе исследования были решены следующие задачи:

1. Анализ существующих фреймворков и стандартов архитектуры предприятия: проведен анализ популярных фреймворков и стандартов (TOGAF, ArchiMate, Zachman, FEAF, MODAF), выявлены их сильные и слабые стороны, а также особенности применения в различных организационных контекстах.

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

3. Демонстрация совместного применения TOGAF и ArchiMate: на примере проектирования процесса обработки запроса клиента банка, обратившегося в контакт-центр, показана практическая возможность и эффективность совместного применения фреймворка TOGAF и графического стандарта ArchiMate для моделирования архитектуры предприятия. Разработанная модель наглядно иллюстрирует интеграцию различных аспектов архитектуры и обеспечивает четкое понимание взаимодействия компонентов системы.

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

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

Заключение

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

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

Дальнейшие исследования авторов будут направлены на углубленное изучение отдельных архитектурных слоев, процессов их формирования и функциональных особенностей. Планируется расширить анализ, выходя за рамки частного случая разработки архитектурного решения в ПАО «Альфа-Банк», и охватить архитектуру компании в целом, что будет включать в себя детальный анализ всех архитектурных слоев, оценку эффективности использования архитектурного подхода в управлении процессами и количественную оценку результатов его внедрения. Такой комплексный подход позволит получить более полное и объективное представление о потенциале и ограничениях применения концепции архитектуры решений в различных организационных контекстах.