service architecture

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

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