separation of concerns, SOC

Разделение сущностей — это принцип проектирования, который помогает управлять сложностью ИТ-услуги или решения за счёт осознанного разбиения на относительно независимые части. Обычно он применяется при проектировании услуг, сервисной архитектуры, процессов и организационных взаимодействий: сначала фиксируется, какой результат нужен заказчику и пользователям, какие требования полезности и требования гарантии должны быть выполнены, какие сервисные операции требуется поддержать, а уже затем выбираются конкретные технологии, компоненты и способы реализации. В ITSM это особенно полезно, когда услуга предоставляется несколькими командами или партнёрами и поставщиками: разделение сущностей позволяет согласовать границы ответственности, снизить связность между компонентами, упростить изменения и развёртывание, а также сделать управление уровнем услуг более прозрачным. Термин не означает «разделить всё по отделам» или «разнести системы физически»; он также не заменяет практику управления архитектурой или проектирование услуг, а является подходом, который эти практики применяют для более понятного и управляемого дизайна.

Разделение сущностей часто неверно понимают как чисто техническую модульность (например, «микросервисы»), хотя смысл шире: отделяются потребности и результаты на стороне заказчика от способов их реализации на стороне поставщика услуги. Типичная ошибка — пытаться разделить части так, что они остаются тесно связанными общими данными, общими изменениями или единым графиком изменений; формально «кусков» становится больше, но независимость не появляется, и управление изменениями усложняется. Ещё одна путаница возникает с «слоями» или «компонентами» в ИТ-инфраструктуре: слоистая архитектура может помогать разделению сущностей, но не гарантирует его, если, например, бизнес-правила «просачиваются» в интерфейсы или операционные технологии диктуют, какие результаты доступны заказчику. В контексте управления услугами важно помнить, что разделение сущностей не отменяет необходимость end-to-end ответственности владельца услуги: даже при независимой разработке и развёртывании частей итоговая ценность, полезность и гарантия остаются едиными для потребления услуги.