Введение
ArchiMate, являясь языком проектирования архитектуры, предоставляет чёткую систему взаимосвязей между объектами. Эта система задаёт возможные варианты отношений для конкретной ситуации и контекста. Учитывая универсальность языка, это огромное преимущество — с его помощью можно описать как бизнес-архитектуру, так и системную, и технологическую.
В данной статье я приведу пример моделирования в нотации ArchiMate для ситуации, когда необходимо смоделировать бизнес-процесс сложной и противоречивой предметной области. Такая задача часто встречается при автоматизации процессов государственных органов и организаций, работающих в строгих законодательных рамках.
Представьте: вам поручили спроектировать систему, обрабатывающую персональные данные. Требования размазаны по пулу статей НПА, а за ошибку грозят миллионные штрафы. Как структурировать эту сложную область и убедиться, что вы ничего не упустили? В этой статье я на примере положений ФЗ «О персональных данных» (далее по тексту – ФЗ) покажу, как язык ArchiMate помогает превратит�� юридический текст в четкую архитектурную схему. Такой подход помогает выявить пробелы в требованиях, наглядно согласовать их с заказчиком и заложить основу для проектирования ИТ-решений.
Обращаю внимание, что я не претендую на исключительность подхода и не сравниваю его с аналогичными. Результат моделирования не будет конечным, так как предметная область выделена из всего контекста ФЗ и смежных норм. Это демонстрация методов моделирования, цель которой — показать сам процесс, а не представить завершённую модель. Основной контекст моделирования — слой бизнес-архитектуры.
Предмет
Раздел ФЗ с терминами и определениями — это концептуальный «костяк», на который в последующих положениях любого закона наращивается «мясо» процедур и конкретных норм. В идеале термины и определения должны формировать непротиворечивую и полную картину регулируемой предметной области. Именно этот «костяк», содержащийся в статье 3 ФЗ, будет основной для моделирования.
Одно из ключевых преимуществ ArchiMate заключается в том, что его строгая система связей помогает выявлять скрытые противоречия и смысловые пробелы уже на этапе работы с терминами — до того, как они перейдут в регламенты процессов, архитектуру решения или код.
Первый шаг архитектурного анализа — инвентаризация сущностей. Я выделил прямо в тексте статьи 3 и пронумеровал ключевые понятия, которые станут объектами в модели. Важно: я фиксирую каждый уникальный объект только один раз, даже если он встречается в разных пунктах:
«Статья 3. Основные понятия, используемые в настоящем Федеральном законе
В целях настоящего Федерального закона используются следующие основные понятия:
1) персональные данные (1) - любая информация (2), относящаяся к прямо или косвенно определенному или определяемому физическому лицу (3) (субъекту персональных данных (4));
1.1) персональные данные, разрешенные субъектом персональных данных для распространения (5), - персональные данные, доступ неограниченного круга лиц (6) к которым предоставлен (7) субъектом персональных данных путем дачи согласия (8) на обработку (9) персональных данных, разрешенных субъектом персональных данных для распространения в порядке, предусмотренном настоящим Федеральным законом;
2) оператор (10) - государственный орган, муниципальный орган, юридическое или физическое лицо, самостоятельно или совместно с другими лицами организующие и (или) осуществляющие обработку персональных данных, а также определяющие цели (11) обработки персональных данных, состав (12) персональных данных, подлежащих обработке, действия (операции), совершаемые с персональными данными;
3) обработка персональных данных - любое действие (операция) или совокупность действий (операций), совершаемых с использованием средств автоматизации или без использования таких средств с персональными данными, включая сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение (13) персональных данных;
4) автоматизированная обработка (14) персональных данных - обработка персональных данных с помощью средств вычислительной техники;
5) распространение персональных данных - действия, направленные на раскрытие персональных данных неопределенному кругу лиц;
6) предоставление персональных данных - действия, направленные на раскрытие персональных данных определенному лицу (15) или определенному кругу лиц (16);
7) блокирование персональных данных - временное прекращение обработки персональных данных (за исключением случаев, если обработка необходима для уточнения персональных данных);
8) уничтожение персональных данных - действия, в результате которых становится невозможным восстановить содержание персональных данных в информационной системе персональных данных и (или) в результате которых уничтожаются материальные носители персональных данных;
9) обезличивание персональных данных - действия, в результате которых становится невозможным без использования дополнительной информации определить принадлежность персональных данных конкретному субъекту персональных данных;
10) информационная система (17) персональных данных - совокупность содержащихся в базах данных персональных данных и обеспечивающих их обработку информационных технологий и технических средств;
11) трансграничная передача персональных данных - передача персональных данных на территорию иностранного государства органу власти иностранного государства, иностранному физическому лицу или иностранному юридическому лицу.»
Объекты
Теперь я классифицирую выделенные сущности по типам объектов ArchiMate. Это ключевой шаг, который превращает текст ФЗ в структурированную архитектурную модель:
(1) персональные данные - бизнес-объект (Business Object);
(2) любая информация о ФЛ – бизнес-объект (Business Object), специализация объекта «персональные данные»;
(3) физическое лицо – роль (Business Actor);
(4) субъект персональных данных – роль, специализация физического лица (Business Actor);
(5) разрешенные для распространения данные – бизнес-объект (Business Object), специализация объекта «персональные данные»;
(6) неограниченный круг лиц – роль (Business Actor) или бизнес-коллаборация (Business Collaboration), для простоты приму за роль. Вероятно, это тот же объект, что и «Неопределённый круг лиц» согласно п.5, для упрощения приму это за данность;
(7) предоставленный доступ - бизнес-объект (Business Object);
(8) согласие на обработку – бизнес-объект (Business Object);
(9) обработка персональных данных - бизнес-процесс (Business Process);
(10) оператор - роль (Business Actor), с вариантами определений;
(11) определение цели обработки персональных данных - бизнес-процесс (Business Process);
(12) состав персональных данных - бизнес-объект (Business Object);
(13) сбор, запись, систематизацию, накопление, хранение, уточнение (обновление, изменение), извлечение, использование, передачу (распространение, предоставление, доступ), обезличивание, блокирование, удаление, уничтожение – бизнес-процессы (Business Process), подвиды процесса «Обработка персональных данных», включая (видимо) трансграничную передачу;
(14) автоматизированная обработка данных - бизнес-процесс (Business Process), специализация бизнес-процесса «Обработка персональных данных»;
(15) определённое лицо - роль (Business Actor);
(16) определённый круг лиц - роль (Business Actor) или бизнес-коллаборация (Business Collaboration), для простоты приму за роль;
(17) информационная система персональных данных – приложение (Application Component).
Моделирование
Итак, я определил 17 ключевых объектов. Для наглядности я сгруппировал их по типам, чтобы увидеть общую структуру будущей архитектуры.
В данном примере получилось 4 группы объектов, связь между которыми в рамках нотации может быть такой:
То есть: роли назначаются (или выполняют) процесс, процесс порождает бизнес-объекты, приложения поддерживают (оказывают сервис) процессы при их автоматизации.
Эта связка — каркас будущей модели. Теперь нужно «наполнить» его жизнью, то есть выстроить процессную логику. Здесь возникает главная аналитическая задача: ФЗ описывает не последовательность шагов, а статичные понятия. Соответственно, необходимо самостоятельно реконструировать эту логику, определить границы процесса, его старт и завершение.
Сначала «раскидаю» на схеме уже имеющиеся объекты в каком-то соответствии другу другу по принципу: сверху роли, ниже процессы, ещё ниже бизнес-объекты, внизу – приложения (ранее я приводил пример моделирования процесса в нотации ArchiMate в сравнении с процессом в нотации BPMN https://habr.com/ru/articles/955332/ , принцип расположения объектов на схеме в данном случае тот же):
Получилась статичная расстановка объектов. Чтобы модель «ожила», нужно сделать два следующих шага: во-первых, соединить объекты явными связями, а во-вторых — выявить и добавить недостающие элементы, без которых процесс неполон.
Начну с первого. В рамках определённых на рис.2 отношений, а также составных отношений и отношений специализации объектов одного вида, определю явные связи, считываемые из определений.
При взгляде на связанные объекты на схеме можно сделать вывод, что общий контекст определений в статье — это логика обработки персональных данных. В этом контексте уже можно определить границы процесса и выявить недостающие на схеме элементы — дополнительные шаги процесса и бизнес-объекты (на схемах далее добавленные объекты будут подкрашены серым цветом).
Некоторые из них очевидны из логики определений. Например, ясно, что нужны начальные и конечные события процесса. В качестве начального определю «Обновилась информация о ФЛ» (здесь и далее: наименование и суть добавленных элементов - мой взгляд, вполне вероятно, что при выполнении аналогичной задачи у вас были бы иные варианты). Также видны недостающие шаги, выполняемые ролью «Субъект персональных данных», а именно: «Владеть персональными данными» и «Разрешить персональные данные для распространения (дать согласие на обработку)». Становится очевидной и поддержка шага автоматизированной обработки «Информационной системой».
После добавления этих элементов появляется прикидка сквозной процессной логики:
Построенная модель на основе статьи 3 — это каркас. Теперь нужно в рамках этого каркаса выстроить недостающую сквозную процессную логику: определить все возможные триггеры и конечные события, недостающие шаги процесса и бизнес-объекты (входы и выходы шагов процесса) в полном объёме. Этот этап — самый сложный, и здесь потребуется анализ других положений ФЗ (а зачастую - и других, межных ФЗ, НПА и подзаконных актов), которые раскрывают недостающие нюансы.
Я не буду проводить здесь столь же детальный разбор каждой статьи, но ключевые положения, уточняющие и дополняющие модель, я вынесу на финальную схему в виде стикеров-пояснений. Это позволит связать формальные юридические нормы с конкретными архитектурными объектами, показывая, как законодательство «ложится» на спроектированную архитектуру.
В результате получается архитектурная схема, объединяющая два типа объектов. Первые — буквально извлечены из текста ФЗ, вторые — выявлены аналитически (выделены серым цветом). Именно это разделение и представляет главную практическую ценность.
Объекты из определений — это отправная точка. Даже с ними возникают вопросы на стыке терминов (как в случае с «неограниченным» и «неопределённым» кругом лиц), но их разрешение — задача предметных экспертов.
Аналитически выявленные объекты, их связи и бизнес-логика — это и есть ключевой предмет обсуждения с заказчиком и владельцами процессов. Каждый элемент — недостающее звено в логике, и его можно детально разобрать на основе связей: какие роли его выполняют, какие данные потребляет и создаёт, какие системы его поддерживают.
Заключение
Ценность ArchiMate в подобных задачах — не в идеальной визуализации, а в создании строгого каркаса для предметного диалога. Этот язык позволяет восстановить и формализовать бизнес-логику, скрытую в нормативных текстах (или любой другой анализуруемой документации), и на основе моделей задавать структурированные, осмысленные вопросы. Такой подход даёт аналитикам и архитекторам практичный инструмент контроля связанности объектов и непротиворечивости требований проектируемых решений.
Надеюсь, этот практический пример окажется для вас полезным. Используйте данный подход для работы с любыми сложными, плохо структурированными требованиями — и вы неизбежно увидите, как терминологический хаос превращается в ясную и управляемую архитектуру, где каждая связь имеет значение.
Спасибо, что прочитали до конца. Коллеги, про архитектуру, методологию и анализ (и не только) я решил завести тематический телеграм-канал. Если интересно - заходите, читайте и принимайте участие в обсуждениях: https://t.me/arma_frame
