Онто-методология: от бизнес-функций и контекстов исполнения к C4-диаграммам

Чтобы связать бизнес-функции с архитектурой системы, важно чётко понимать отличия между бизнес-функцией, бизнес-процессом и бизнес-сервисом (услугой) в контексте BPM(Business Process Management).

Бизнес-процесс – это последовательность связанных действий (шагов) с определёнными событиями начала и результата, направленная на выпуск конкретного продукта или услуги. Процесс рассматривается «снаружи» – как цепочка шагов для удовлетворения потребностей клиента (внешнего или внутреннего)[1]. Его цель – предоставить ценность потребителю, выступая чёрным ящиком: внутренние шаги не видны внешнему наблюдателю[2]. Сложный процесс может включать подпроцессы и пересекать границы отделов. Важно, что за целый сквозной процесс обычно отвечает владелец процесса, обеспечивая координацию между подразделениями[3][4].

Бизнес-функция – это тип деятельности или устойчивый набор работ, сгруппированных по общим критериям: требуемым IT-Capability, навыкам, компетенциям, организационной принадлежности и т.д.. Функция – взгляд «изнутри» на бизнес-активность: она объединяет однородные задачи, обычно выполняемые одним подразделением или ролью, и требует определённых IT-Capability/умений. В отличие от процесса, функция не задаёт жёсткой последовательности шагов, а фокусируется на том, что выполняется и какими средствами. Часто бизнес-функции являются частями бизнес-процессов – процесс состоит из ряда функций различных отделов. При этом одна функция может участвовать в нескольких процессах: между сложными процессами и функциями обычно существует связь «многие ко многим». Иными словами, бизнес-процесс – это цепочка (оркестровка) функций, а бизнес-функция предоставляет определённую способность (capacity), которая может использоваться в разных процессах.

Бизнес-сервис (услуга) – это внешнее отображение возможностей организации. Бизнес-сервис представляет цельную функциональность, дающую ценность потребителю, вне зависимости от того, как она реализуется внутри компании[10]. Услуга — это то, что организация предлагает внешним или внутренним клиентам, опираясь на свои процессы и функции. Принято различать внешние услуги (для внешних клиентов) и внутренние бизнес-услуги (для поддержки внутренних процессов и функций)[11]. Бизнес-функции и процессы реализуют бизнес-сервисы: т.е. сервис – это «витрина» или интерфейс, за которым может стоять либо цепочка шагов (процесс), либо совокупность действий, выполняемых одним звеном (функция)[12]. Например, услуга «Подключение нового абонента» для клиента может реализовываться бизнес-процессом, проходящим через несколько отделов, или через единичную функцию, выполненную одним подразделением – но внешне это единая услуга подключения.

Резюмируя различия: бизнес-процесс описывает как работа выполняется (последовательность действий для достижения результата), бизнес-функция фокусируется на чём выполняется и какими IT-Capability (группировка схожих работ по ответственности), а бизнес-сервис описывает что получает клиент (ценность/результат), скрывая внутренние детали реализации. В контексте BPMN-нотации прямого элемента “бизнес-функция” нет – BPMN оперирует процессами и задачами. Однако при бизнес-моделировании (например, по ARIS или ArchiMate) функции рассматриваются как компоненты процессов или как отдельные единицы поведения, предоставляющие сервисы. Знание этой иерархии важно, т.к. бизнес-функции будем использовать как отправную точку для разработки ИТ-архитектуры.

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

Акторы (исполнители) – роли, сотрудники или внешние пользователи, которые участвуют в выполнении функции. Это могут быть конкретные должности (например, Менеджер по подключению в отделе продаж) или же сами клиенты/пользователи, если функция подразумевает самообслуживание. Актор инициирует или непосредственно выполняет задачи функции в данном контексте.

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

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

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

Контекст исполнения фактически описывает вариант реализации бизнес-функции. Одна и та же бизнес-функция может иметь несколько контекстов исполнения, в зависимости от того, кто и с помощью каких средств её выполняет. Например, функция подключения нового абонента в телеком-бизнесе может выполняться: (1) через менеджера в офисе продаж (человек-исполнитель, использующий внутреннюю CRM-систему, канал – офис/фронт-офис, ограничение – рабочие часы, очное присутствие клиента), а также (2) самим абонентом через веб-портал самообслуживания (исполнитель – клиент, IT-Capability – интернет-портал, канал – онлайн, ограничения – доступность интернета, возможно упрощённые тарифы без сложных проверок). Обе реализации достигают одной цели (подключение абонента), но контекст и задействованные сущности различны.

Зачем явно описывать разные контексты? Потому что выбор контекста влияет на архитектурное решение. Как отмечается в подходе Architecture of Business, способность (capability) организации достигается реализацией функции с учётом конкретного бизнес-контекста, и в разных условиях одна и та же функция может требовать разных IT-Capability и давать разные результаты. Иными словами, бизнес-онтология должна зафиксировать, в каком окружении существует функция, чтобы далее правильным образом спроектировать под неё систему. В онтологических терминах, функция должна быть связана с описанием её контекстов – это повышает адаптивность и точность архитектуры. Например, в одном контексте capability “подключить абонента” подразумевает одно наполнение (процедуры, системы), а в другом – иное, и оба надо учесть при проектировании.

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

Бизнес-процессы (процессы) группируют поведение по потоку работ, а бизнес-функции (функции) – по IT-Capability и компетенциям; обе могут реализовывать бизнес-сервисы (услуги). Каждая бизнес-функция может иметь один или несколько контекстов исполнения, связанных с определёнными акторами, IT-Capability, каналами и ограничениями.

На схеме (Рис.2) отражены следующие классы и связи:

BusinessFunction (Функция) – класс бизнес-функций. Атрибуты: название функции, описание цели. Связи: имеет контексты → множество ExecutionContext. Также функция может реализовывать один или несколько BusinessService (бизнес-сервисов), и может быть частью исполнения BusinessProcess.

BusinessProcess (Процесс) – класс бизнес-процессов. Атрибуты: название процесса, результат. Связи: может использовать или включать функции (BusinessFunction), образуя цепочку из них[9]. Процесс тоже может реализовывать бизнес-сервисы.

BusinessService (Сервис) – класс бизнес-услуг. Атрибуты: название услуги, потребитель. Связи: реализуется процессами или функциями. Сервис – то, что получает внешний актор, результат выполнения функции/процесса[10][12].

ExecutionContext (Контекст исполнения) – класс контекстов выполнения функции. Отражает конкретный вариант реализации функции. Атрибуты: идентификатор или имя сценария, описание условий. Связи: принадлежит одной BusinessFunction (обратная связь “имеет контексты”), а также соединяется с элементами среды:

Actor/Role (Актор) – класс акторов или ролей. Представляет человека или внешнюю систему, инициирующую или выполняющую функцию. Атрибуты: имя роли (например, “Менеджер отдела подключений” или “Клиент”). Связи: может быть назначен на функцию (ответственный за функцию) – пунктирной стрелкой на схеме обозначено, что роль может отвечать за выполнение функции как таковой, но в контексте мы фиксируем конкретного исполнителя.

IT-Capability (Способность) – класс IT-Capability/инструментов. Атрибуты: тип IT-Capability (ИТ-система, оборудование, данные и т.п.), название (например, “CRM-система”). Связи: используется в контексте исполнения функции. Одна функция может требовать несколько IT-Capability.

Channel (Канал) – класс каналов взаимодействия. Атрибуты: тип канала (web, мобильный, офлайн и т.д.). Связи: контекст функции происходит через определённый канал.

EnvironmentConstraint (Ограничение среды) – класс ограничений. Атрибуты: описание ограничения (например, “Регламент РФ о персональных данных” или “Доступно в рабочие дни 9–18”). Связи: контекст подчиняется этим ограничениям.

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

Таблица 1: Пример описания бизнес-функции и её двух контекстов исполнения. Каждый контекст фиксирует “картинку” выполнения функции: кто выполняет, с помощью чего и где, а также особые условия. Благодаря онтологической связке, мы можем однозначно проследить: от функции → к контекстам → к задействованным системам и ролям. Далее на основе этой информации можно переходить к проектированию архитектуры.

Имея онтологически описанные функции и их контексты, мы готовы трансформировать это в конкретные архитектурные представления. Мы используем модель C4 – подход, предлагающий иерархию диаграмм для описания программной архитектуры: уровень контекста (Context), контейнеров (Containers), компонентов (Components) и кода (Code)[16]. В нашем методе мы сконцентрируемся на первых трёх уровнях C4, чтобы проследить путь от бизнес-функции (через контекст) к технической реализации. Ниже описан пошаговый “рецепт” такой трансформации.

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

1.Выделить систему или систему-в-сфокусе, которая выполняет данную бизнес-функцию в выбранном контексте. В онто-модели это соответствует основному IT-Capability/системе, использующемуся в контексте. Например, для контекста “через менеджера” это будет CRM/система управления подключениями, которую использует сотрудник.

2.Определить ключевых акторов – внешних пользователей этой системы. Из контекста возьмём роль исполнителя и, возможно, клиента. На диаграмме контекста они изображаются как пользователи (персоны) вне системы. Например, Менеджер будет внешним пользователем CRM-системы, а также можно отразить Абонента, если он косвенно участвует (через менеджера).

3.Определить внешние системы, с которыми наша система должна интегрироваться в процессе выполнения функции. Эти сведения тоже есть в контексте: например, для подключения абонента CRM может обращаться к биллинг-системе (для создания счёта) и системе активации (OSS, для активации SIM в сети). Такие внешние ИТ-сервисы станут отдельными узлами на диаграмме.

4.Нанести связи (интеграции) между центральной системой, актором и внешними системами. Стрелками показываем, кто как взаимодействует: пользователь → система (выполнение через UI/API), система ↔ внешние системы (обмен данными). На этом шаге достаточно текстового описания взаимодействия (например, “использует интерфейс”, “отправляет запрос на активацию”).

Диаграмма системного контекста помогает сразу увидеть границы ответственности: что входит в нашу систему, а что остается внешними сервисами; кто основные пользователи. Она используется на ранних этапах проектирования для общего понимания окружения[17]. Элементы такой диаграммы – система (наш программный продукт), пользователи (акторы) и внешние системы, а также связи между ними (интеграции, взаимодействия).

Для примера возьмём бизнес-функцию “Управление подключением абонентов” в контексте обслуживания через менеджера. Основная система здесь – предположим, “Backend Service (Application, реализующее IT-Capabilities)”, которая обеспечивает оформление нового подключения. Внешний актор – Менеджер по продажам, использующий эту систему. Внешние системы – Billing Adapter (Application, интеграция с внешним биллингом) (начисление оплаты) и Provisioning Adapter (Application, реализующее IT-Capability «Активация SIM-карт») (включает номер в сети), плюс сама телеком-сеть как инфраструктура.

Пользователь-менеджер (слева) взаимодействует с целевой системой Backend Service (Application, реализующее IT-Capabilities) – условно, модуль CRM для подключения. Система, в свою очередь, интегрируется с внешними: биллингом и системой активации, которая связана с телеком-сетью. На схеме сразу видны границы нашей системы и все внешние взаимодействия.

Следующий уровень – диаграмма контейнеров – раскрывает внутреннюю структуру нашей системы на крупные компоненты-развертывания (containers): приложения, базы данных, микросервисы, пользовательские интерфейсы и пр. Это архитектурный «черчёж» высокоуровневого дизайна системы. Диаграмма контейнеров описывает из чего состоит система, какие технологии используются и как разделены зоны ответственности[18]. Элементы здесь: контейнеры (например, веб-приложение, база данных, API-сервер и т.п.), их взаимосвязи (протоколы, вызовы) и важные технологии/фреймворки[18].

Примечание: В дополнение к стандартным контейнерам добавлен API-GW, через который Agent Web Portal взаимодействует с Backend Service. Это отражает современный паттерн интеграции.

1.Выявить основные компоненты системы, которые понадобятся для реализации функции в данном контексте. Вспомним требования контекста: какой канал используется? Если, например, канал – веб-портал для менеджера, очевидно нужен контейнер фронт-энда (веб-приложение) и контейнер серверной логики (бэкенд). Если есть хранилище данных – будет контейнер базы данных. Фактически, на основе IT-Capability/системы из контекста мы декомпозируем её на части: пользовательский интерфейс, серверную часть, БД, интеграционные модули и т.д.

2.Определить взаимодействия между контейнерами внутри системы. Например, фронтэнд обращается к бэкенду (REST API), бэкенд к базе данных (SQL запросы). Если в системе несколько приложений, показать связи между ними.

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

4.Добавить технические детали (по возможности): типы контейнеров и технологии. Например, отметить что веб-приложение – это Angular SPA, бэкенд – Spring Boot, база – Oracle DB. Это помогает понимать стек. На методологическом уровне можно оставить технологии шаблонно (например “Web Application”, “Database”) как роли контейнеров, если конкретика не известна.

Диаграмма контейнеров даёт картину высокоуровневой архитектуры системы: какие приложения и хранилища задействованы и как они общаются. Она полезна архитекторам и разработчикам для разбивки системы на модули и выбора технологий[18].

Примечание: В дополнение к стандартным контейнерам добавлен API-GW, через который Agent Web Portal взаимодействует с Backend Service. Это отражает современный паттерн интеграции.

Продолжим наш пример “Управление подключением абонентов” – теперь детализируем Backend Service (Application, реализующее IT-Capabilities) из Рис.2. Предположим, это классическое веб-приложение для сотрудников: у менеджера есть веб-интерфейс (портал) для ввода данных клиента, есть сервер приложений, который обрабатывает бизнес-логику подключения, и база данных, где сохраняются заявки и данные абонентов. Бэкенд-сервер также интегрируется с внешними системами (биллингом и системой активации).

Такой уровень детализации основан на знаниях о контексте: например, мы знали, что канал – веб, поэтому появился контейнер Web Portal; знали о внешних интеграциях – поэтому на бэкенде предусмотрены взаимодействия с биллингом и OSS. Важно: диаграмма контейнеров для другого контекста той же функции могла бы отличаться. Если бы функция выполнялась клиентом через мобильное приложение, вместо “Agent Web Portal” был бы контейнер “Mobile App”, и, возможно, иной набор контейнеров (например, потребовался бы API-шлюз). Поэтому преобразование делается для каждого контекста исполнения отдельно, чтобы учесть специфику каналов и IT-Capability.

Третий уровень C4 – диаграмма компонентов – детализирует внутреннее устройство отдельных контейнеров системы. Обычно фокус идёт на одном из контейнеров, раскрывая его на составные компоненты кода/модули и показывая, как они взаимодействуют друг с другом и внешним окружением[19]. Диаграмма компонентов помогает разработчикам понять распределение ответственности внутри приложения и точки интеграции. Элементы: компоненты (функциональные части внутри контейнера, например, классы, модули, службы), их взаимосвязи (вызовы, зависимости), используемые технологии и внешние зависимости (базы, внешние сервисы)[19].

Примечание: Все компоненты (Subscription Manager, Billing API Client, Provisioning API Client, Data Access) являются частью Application Backend Service. Их интеграции с внешними системами реализуются через Applications типа Adapter (например, Provisioning Adapter).

1.Выбрать контейнер для детализации. Обычно выбирают наиболее сложный или ключевой контейнер. В нашем примере это Backend Service, т.к. в нём сосредоточена бизнес-логика подключения. (Отдельно можно было бы детализировать и Portal, но предположим, что фронтэнд типовой.)

2.Выделить основные компоненты внутри контейнера, исходя из функциональности, которую он реализует. Для бэкенда “подключение абонента” логично выделить, например: компонент, управляющий процессом подключения (орchestrator), компоненты-интеграторы для каждого внешнего сервиса (например, Billing API Client, Provisioning API Client), а также компонент доступа к базе данных (DAO или репозиторий). Также могут быть компоненты валидации, логирования, но мы фокусируемся на бизнес-функциях.

3.Показать взаимодействия компонентов между собой. Например, orchestrator вызывает компонент интеграции с биллингом и компонент доступа к данным. Компоненты интеграции, в свою очередь, взаимодействуют с внешними системами (эти внешние системы можно указать на диаграмме для наглядности). Все связи подписываем: чем именно обмениваются или через какой интерфейс (например, REST вызов, JDBC запрос).

4.Указать внешние элементы, с которыми компоненты работают. Это могут быть: база данных (которая уже была отдельным контейнером на уровне выше), внешние системы, а также, возможно, компоненты в других контейнерах. На компонентной диаграмме допускается показать, что, скажем, BillingClient компонент вызывает внешний Billing System API. По сути, мы детализируем одну “коробочку” (контейнер) из предыдущего уровня, не забывая о его связях наружу[20].

Таким образом, диаграмма компонентов – это углубление внутри одного контейнера, показывающее реализацию функции на уровне архитектурных классов/модулей. Её используют при проектировании и документировании внутренней реализации системы, распределяя ответственность по компонентам[19].

Продемонстрируем на нашем примере детализацию Backend Service для подключения абонента. Предположим, серверная логика состоит из следующих компонентов: Subscription Manager (основной компонент, управляющий процессом подключения: проверяет данные, orchestrates), Billing API Client (класс/модуль, отвечающий за взаимодействие с биллингом), Provisioning API Client (модуль для связи с OSS/сетью) и Data Access (компонент доступа к базе, например репозиторий, обеспечивающий сохранение/чтение заявок).

Здесь контейнер Backend разбит на компоненты: SubscriptionManager, ProvisioningAPIClient, DataAccess. Основной компонент SubscriptionManager вызывает компоненты Billing и Provisioning для выполнения внешних операций, а также использует DataAccess для работы с базой (стрелки “calls”). Показаны и внешние системы: BillingAPIClient общается с Billing System (REST API), ProvisioningAPIClient – с Provisioning Adapter (Application, интеграция с SIM capability) (SOAP), а DataAccess – с Subscription DB (SQL запросы). Внешние элементы (БД и внешние сервисы) отмечены пунктиром, указывая, что они не являются частью данного контейнера.

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

Примечание: Все компоненты (Subscription Manager, Billing API Client, Provisioning API Client, Data Access) являются частью Application Backend Service. Их интеграции с внешними системами реализуются через Applications типа Adapter (например, Provisioning Adapter).

Шаблоны и повторное использование: Представленный подход можно оформить как шаблонную последовательность действий. Для каждой бизнес-функции:

Предложенная методология – своего рода “кухня” построения архитектуры на основе знаний о бизнесе. Начав с четких определений бизнес-функций, мы помещаем их в контекст выполнения (акторы, IT-Capabilities, каналы, ограничения), формализуем в виде онтологии, а затем пошагово преобразуем каждый контекст в систему и её компоненты с помощью C4-нотации. Такой подход обеспечивает трассировку: от бизнес-целей и способов работы (что делает бизнес) – к конкретным модулям программной системы (как это поддерживается технически). Он понятен бизнес-аналитикам (они видят, как их функции “переводятся” в софт), системным архитекторам (они получают исходные точки для проектирования систем под каждый сценарий), и разработчикам внешних решений (они получают наглядные схемы, какие компоненты нужны и как они взаимодействуют).

Методология Онто + C4 способствует тому, чтобы архитектура отвечала потребностям бизнеса: каждый элемент системы можно вывести из бизнес-функции и её контекста. Это уменьшает разрывы между описанием процессов и реализацией ИТ-решений. Применяя данный “рецепт” на практике, вы сможете последовательно и обоснованно проектировать системы, обеспечивая нужный функционал в нужном контексте – будь то подключение абонентов в телекоммуникациях или любая другая бизнес-функция в вашей предметной области. Каждый шаг – от слов к схемам – прозрачен и обоснован, а результатом являются чёткие C4-диаграммы, служащие понятной документацией архитектуры внешнего продукта.