Интересы и проблемы в ArchiMate 4.0: что такое Concerns

Интересы и проблемы (Concerns) в ArchiMate 4.0 — это вопросы, ожидания, риски и области внимания, которые важны для заинтересованных сторон при разработке и изменении архитектуры организации.

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

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

Что такое интересы и проблемы (Concerns) в ArchiMate 4.0

Интерес или проблема — это значимый вопрос, тема или область внимания, которая влияет на архитектурные решения. В англоязычной терминологии ArchiMate используется слово Concern. Его не всегда правильно переводить только как «проблема»: в зависимости от контекста это может быть также интерес, ожидание, риск, ограничение или предмет обсуждения.

Например, к интересам и проблемам могут относиться:

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

Важно понимать: интерес — это не готовое техническое решение. Формулировка «нужно внедрить микросервисную архитектуру» описывает предполагаемый способ реализации. А формулировка «нужно быстрее изменять отдельные функции системы без остановки всего сервиса» описывает реальный интерес или проблему.

В ArchiMate интересы и проблемы помогают связать несколько уровней описания:

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

Таким образом, интересы и проблемы отвечают на вопрос: «Что именно необходимо учитывать при проектировании архитектуры и почему?»

Зачем нужны

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

Интересы и проблемы нужны для следующих задач.

Связь архитектуры с целями организации

Любое архитектурное изменение требует ресурсов: денег, времени, сотрудников и управленческого внимания. Описание интересов помогает показать, какую бизнес-задачу решает архитектура и почему проект имеет значение.

Например, новая система может быть нужна не сама по себе, а для того, чтобы:

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

Согласование ожиданий разных участников

У одной и той же системы могут быть разные пользователи и владельцы. Руководителю важна окупаемость, сотруднику — удобство, специалисту по безопасности — защищённость, клиенту — скорость и понятность обслуживания.

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

Поиск конфликтов на раннем этапе

Интересы позволяют увидеть противоречия ещё до начала разработки. Например:

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

Все эти ожидания законны, но одновременно выполнить их в максимальном объёме невозможно. Архитектура должна найти разумный баланс.

«Если интересы не названы явно, они всё равно будут влиять на архитектуру — только скрыто и часто в форме конфликтов».

Обоснование архитектурных решений

При выборе архитектурного варианта важно объяснить, почему предпочтён именно он. Интересы служат основой такого обоснования.

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

Управление изменениями и проектами

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

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

Какие вопросы и проблемы возникают при разработке архитектуры

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

Бизнес-цели и ожидаемые результаты

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

Полезно уточнить:

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

Расплывчатая формулировка «нужно улучшить обслуживание» не даёт архитектору достаточной информации. Её можно уточнить: «необходимо сократить среднее время ответа оператора с десяти до трёх минут и обеспечить единое представление истории клиента».

Пример уточнения бизнес-интереса

Исходная формулировка:
«Нужно повысить качество обслуживания клиентов».

Уточнённые интересы:
1. Сократить время ожидания ответа.
2. Сделать историю обращений доступной оператору.
3. Снизить количество повторных обращений.
4. Измерять качество работы контактного центра.

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

Стоимость, риски и экономическая эффективность

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

К этой группе относятся интересы:

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

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

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

Безопасность и соответствие требованиям

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

Типичные вопросы:

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

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

Надёжность и удобство использования ИТ-систем

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

В этой области могут возникать следующие интересы:

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

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

«Техническая сложность системы не должна становиться сложностью для человека, который использует её в своей ежедневной работе».

Как выявлять и описывать

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

Выявление актуальных вопросов и проблем

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

Для этого используют:

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

Полезно задавать открытые вопросы:

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

После интервью ответы нужно превратить в краткие и понятные формулировки. Одна формулировка должна описывать один самостоятельный вопрос или проблему.

Пример карточки интереса

Название: Защита персональных данных

Заинтересованные стороны:
- служба информационной безопасности;
- юридический отдел;
- клиенты;
- руководство компании.

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

Почему это важно:
Утечка может привести к штрафам, финансовым потерям
и снижению доверия клиентов.

Связанные требования:
- разграничение доступа;
- журналирование действий;
- шифрование;
- регулярное резервное копирование.

Сбор ожиданий и требований к архитектуре

Интересы формулируются на достаточно общем уровне. Затем их переводят в цели и требования.

Например:

Связь между уровнями

Интерес:
Сократить время обслуживания клиента.

Цель:
Уменьшить среднее время обработки обращения с 12 до 5 минут.

Требование:
Оператор должен видеть историю заказов, обращений и платежей
в едином рабочем окне.

Архитектурное решение:
Интегрировать систему обслуживания клиентов
с системами заказов и платежей.

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

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

При описании требования желательно указывать:

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

Приоритизация проблем и противоречивых ожиданий

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

Для приоритизации используют следующие критерии:

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

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

Пример конфликта интересов

Интерес бизнеса:
Запустить новый цифровой сервис через три месяца.

Интерес службы безопасности:
Провести полный цикл проверок и тестирования.

Интерес финансового отдела:
Не увеличивать бюджет проекта.

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

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

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

Примеры из практики

Оценка стоимости и окупаемости цифровизации

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

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

Ситуация

Проблема:
Согласование закупки занимает до 10 рабочих дней.

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

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

Требования:
- электронный маршрут согласования;
- автоматическая проверка лимитов;
- журнал всех решений;
- интеграция с финансовой системой.

Ожидаемый эффект:
Сокращение ручной работы и более быстрое принятие решений.

При оценке окупаемости учитывают не только цену лицензии, но и:

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

Архитектурный вывод: решение следует оценивать по полному экономическому эффекту, а не только по первоначальной цене продукта.

Ожидание удобной и эффективной рабочей системы

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

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

Вариант архитектурного анализа

Наблюдаемая проблема:
Оператор тратит время на поиск информации
и многократный ввод одних и тех же данных.

Интерес:
Сделать обслуживание клиента быстрым и понятным.

Цель:
Сократить среднее время обработки обращения на 30 процентов.

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

Показатели:
- время обработки обращения;
- количество ошибок;
- число переходов между системами;
- оценка удобства сотрудниками.

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

Выявление рисков информационной безопасности

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

Заинтересованные стороны по-разному смотрят на ситуацию:

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

Пример выявленных вопросов безопасности

1. Как подтверждается личность пользователя?
2. Какие данные доступны мобильному приложению?
3. Как ограничивается доступ сотрудников?
4. Где хранятся журналы действий?
5. Как обнаруживается подозрительная активность?
6. Как отзывается доступ при утрате устройства?
7. Как восстанавливается сервис после инцидента?

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

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

Определение приоритетов модернизации инфраструктуры

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

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

Пример матрицы приоритетов

Компонент: система расчёта заработной платы
Влияние сбоя: очень высокое
Вероятность сбоя: средняя
Приоритет: высокий

Компонент: внутренний новостной портал
Влияние сбоя: низкое
Вероятность сбоя: средняя
Приоритет: низкий

Компонент: система обработки заказов
Влияние сбоя: очень высокое
Вероятность сбоя: высокая
Приоритет: критический

Компонент: архив старых документов
Влияние сбоя: среднее
Вероятность сбоя: низкая
Приоритет: отложенный

Решение:
Сначала модернизировать систему обработки заказов,
затем обеспечить резервирование расчёта заработной платы.

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

«Модернизировать нужно не самое старое, а самое опасное или наиболее значимое для бизнеса».

Похожие понятия

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

Заинтересованная сторона (Stakeholder)

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

Примеры:

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

Заинтересованная сторона — это кто выражает ожидание или обеспокоенность. Интерес или проблема — это что именно её волнует.

Пример различия

Заинтересованная сторона:
Финансовый директор.

Интерес:
Снизить совокупную стоимость владения ИТ-системой.

Заинтересованная сторона:
Сотрудник контактного центра.

Интерес:
Быстро находить информацию о клиенте.

Требование (Requirement)

Требование — это конкретное условие или характеристика, которым должна соответствовать архитектура, система, процесс или компонент.

Интерес обычно описывает более широкий вопрос. Требование переводит его в проверяемую форму.

Пример:

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

Главное различие: интерес помогает понять смысл изменений, а требование задаёт конкретное условие реализации.

Цель (Goal)

Цель — это желаемое состояние или результат, которого организация стремится достичь.

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

Пример перехода от интереса к цели

Интерес:
Ускорить обработку заказов.

Цель:
Сократить среднее время обработки заказа
с 20 до 8 минут до конца текущего года.

Показатель:
Среднее время от получения заказа
до передачи его в службу исполнения.

Один интерес может быть связан с несколькими целями, а одна цель — поддерживать несколько интересов.

Принцип (Principle)

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

Например:

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

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

Например, интерес «снизить зависимость от поставщика» может привести к принципу «использовать переносимые форматы данных и документированные интерфейсы».

Точка зрения (Viewpoint)

Точка зрения — это способ построения архитектурного представления для определённой группы заинтересованных сторон или определённой задачи.

Разным участникам нужна разная информация:

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

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

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

Итоги

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

При работе с интересами важно:

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

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