На протяжении последних десяти лет ИТ архитектура и управление ИТ-сервисами(ITSM) следуют параллельными курсами. Не то чтоб они не пересекаются, пересекаются они на каждом шагу, я бы даже сказал, не пересекаются, а скорее сталкиваются, высекают друг из друга искры и снова расходятся на безопасное расстояние. При этом оба обозначенных направления изначально не являлись целостными и крайне друг в друге нуждаются. Проблема ИТ архитектуры заключается в её статичности. Архитектурные модели, вырванные из процессов ИТ, не актуализируются и довольно быстро устаревают. Архитекторам, зачастую приходится заниматься тем, что Гради Буч назвал software archeology, раскопками утраченных знаний о том, что представляет собой ИТ система и как она работает. В свою очередь, ИТ процессам очень не хватает четкой классификации объектов и отношений между ними. Определяемые ITIL понятия ИТ-сервис и конфигурационная единица(КЕ) не особо конкретны. Любое существительное можно назвать КЕ, однако сколь либо стандартизированных классификаторов КЕ не существует и организациям их приходится придумывать самостоятельно. С ИТ-сервисом ситуация не лучше. Про него по большому счету известно то, что он предоставляется и то, что он обладает(или должен обладать) соглашением об уровне сервиса (SLA). Попробуем «подружить» архитектуру информационных систем и управление ИТ-сервисами
Напомню, что точкой отсчета современной ИТ архитектуры можно считать опубликованную в ноябре 1995г. работу Philippe Kruchten The “4+1” View Model of Software Architecture. С работой Фила перекликаются стандарты IEEE 1471-2000, ISO/IEC 42010:2007, естественно язык моделирования UML и другие архитектурные фреймоворки. Все они предлагаю рассматривать информационную систему с нескольких точек зрения. Причем для каждой точки зрения четко определены используемые в модели данного типа сущности и отношения между ними. Как минимум 4+1 модели присутствуют во всех архитектурных подходах. Нас же будут интересовать физическая модель, дающая представление о том из каких материальных объектов состоит система, варианты использования (use case) – классификация пользователей системы и предоставляемых им возможностей.
Проще всего дела обстоят с физической моделью. UML предлагает нам оперировать понятиями компонент и узел (node). Компонент – это физически выделяемый элемент информационной системы, реализующий один набор интерфейсов и использующий другой. Узел, это то на чем развертывается компонент. Есть два момента, на которые следует обратить внимание. Во-первых, концепция узлов и компонентов рекурсивна. Компьютер выступает узлом для развертывания операционной системы. Операционка, установленная на компьютере, может являться узлом для развертывания java-машины, являющейся в этом случае компонентом. Все это вместе является узлом для развертывания конкретного java-приложения, например, интерпретатора какого-либо скриптового языка. А конкретный скрипт, в этом случае, является компонентом, развернутым на упомянутом выше приложении, выступающем теперь в роли узла. Второй момент – UML предоставляет механизм стереотипов, т.е. определения типов узлов и компонент. Как его использовать мастерски обрисовал Джим Коналлен в работе Разработка Web-приложений с использованием UML. Однако, разработка стереотипов для определенной программной платформы является задачей довольно творческой. Выбор стереотипов в значительной степени определяет прозрачность архитектурного описания. Но вернемся к ИТ-процессам, в которых тема классификации конфигурационных единиц не менее актуальна, чем в архитектуре. Очевидно, что стереотипы узлов и компонентов должны совпадать с классами конфигурационных единиц. Невыполнение этого требования приводит к самым печальным последствиям, как для архитектуры, так и для управления ИТ.
Следующий, не менее важный момент это соответствие модели вариантов использования(use case) и ИТ-услуг. Напомню, что модель вариантов использования включает действующих лиц (actors) и непосредственно сами варианты использования. Действующим лицом может выступать клиент, сотрудник, внешняя информационная система и так далее. Хороший архитектурный анализ предполагает аккуратную классификацию действующих лиц. Для каждой группы пользователей определяется та или иная роль, профиль доступа, группа в каталоге пользователей. Есть все резоны уравнять действующих лиц, являющихся сотрудниками компании с ИТ услугами из ITSM. Тогда, при проектировании информационных систем уместно оперировать не абстрактными actors, а уже существующими группами пользователей. Переходя на язык бизнес-процессов такая группа является функцией.О том что такое функция и как она соотносится с бизнес-процессами, на мой взгляд, довольно понятно рассказано в Concepts for Architectural Description» ArchiMate Deliverable 2.2.1 v4.1 не буду на этом останавливаться.
Конечно, не все ИТ-услуги можно соотнести с действующими лицами программных систем. Для разовых услуг (услуг по запросу), архитектуру разрабатывают не всегда. (Что, в общем, по большому счету, не правильно.) Модель вариантов использования (use case) подходит для разработки сервисов наилучшим образом. А связь между действующими лицами и функциями (профилями доступа, группами,..) является не менее важным этапом развертывания релиза, чем размещение программных компонент по серверам.
И наконец, про всякие SLA-и, KPI-и и прочие важные штуки, являющиеся неизменным атрибутом управления ИТ-процессами. Как их считать единообразно для каждой из услуг, не потеряв при этом специфики конкретной услуги? Как сопоставить объем предоставляемой услуги с затратами на те или иные активы? Почему KPIs остаются в зеленой зоне, SLA выполняется, а пользователи недовольны? Ответить на эти вопросы без архитектуры попросту невозможно. Use-case модель, на самом деле, является точкой входа в архитектуру. За овалами вариантов использования скрываются диаграммы взаимодействия, показывающие как типичный ход событий по обработке пользовательского запроса, так и поведение системы при возникновении исключений. Участниками взаимодействия являются те самые компоненты, что были нарисованы нами ранее в физической модели. А под ними, как мы уже обсуждали, расположены сервера и другие элементы ИТ-инфраструктуры. По диаграмме взаимодействия несложно соотнести количество использования use-case-а с нагрузкой на конкретные узлы и компоненты. Архитектурные модели великолепно согласуются между собой. И модель вариантов использования является тем самым пятым элементом из формулы «4+1», который их замечательным образом согласует.