Почему ИТ-сервисы должны базироваться на архитектуре

На протяжении последних десяти лет ИТ архитектура и управление ИТ-сервисами(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», который их замечательным образом согласует.

Почему ИТ-сервисы должны базироваться на архитектуре: 5 комментариев

  1. >>Почему KPIs остаются в зеленой зоне, SLA выполняется, а пользователи недовольны?

    IMHO, в большинстве случаев ответ на этот вопрос не связан с архитектурой. Встречный вопрос – а что, часто среди KPI можно отыскать связанные с удовлетворенностью пользователей?

    На эту тему вспоминается a) один известный факт и b) один известный анекдот

    a) Автоматизация, в общем случае, вовсе не приводит к облегчению жизни пользователей, а часто совсем наоборот – пользователей вынуждают протоколировать все свои действия в автоматизированной системе, что отнимает у пользователей кучу времени и монополию на корпоративные знания, а, соответственно, и статус незаменимости у ключевых пользователей. От автоматизации выигрывают не сотрудники, а предприятие в целом. Ну а сотрудники почти всегда недовольны

    b) Английский лорд слышит на улице шум и спрашивает дворецкого:
    – “Джон, скажите, что там происходит?”
    – “Женщины легкого поведения бастуют, сэр. Требуют повышения оплаты” – отвечает тот
    – “А что, им действительно мало платят?”
    – “Нет, сэр, вполне достаточно”
    – “Так почему же они недовольны?”
    – “Б…и, сэр”
    Извините за легкомысленный анекдот, но, мне кажется, он вполне характеризует психологию корпоративных пользователей по отношению к автоматизированной системе – они всегда будут ею недовольны.
    По крайней мере мой долгий опыт работы по обеим сторонам баррикад – как руководства ИТ-службой больших организаций, так и руководства ИТ-компанией – об этом свидетельствует

    1. Люди – они разные. Здесь нет какого-то принципиального различия между айтишниками и пользователями. Кто-то простраивает все процессы через себя, чтоб удержать монополию на знания, а кто-то склонен к сотрудничеству и взаимодействию. Отношения первого типа – это лицо современной организации. Отношения второго типа – будущее. Собственно говоря, agile это не о том, как развешивать цветные стикеры на стене, а о том, как расшаривать знания и вносить вклад в общую деятельность. Естественно, современная бюрократия убивает такую возможность. Никакое подразделение не станет делиться компетенциями, зная, что в это же время управление персонала «оптимизирует» оргструктуру.

      Кстати, а пользователи обычно недовольны тем, что сложность информационных систем лежит между ними и айтишниками. Т.е. уровень сложности систем такой, что айтишники что-то с ней могут еще сделать, а пользователи нет. Вот они и недовольны, кто-то осмысленно, кто-то интуитивно. Все дело в доверии.

      1. >>нет какого-то принципиального различия между айтишниками и пользователями

        Полностью согласен, правда в негативном смысле. Работая теперь в айтишной компании, работающей с разными клиентами, хоть и не часто сам общаюсь с клиентами, но уже давно пришел к выводу, что айтишники компании-заказчика ничем не лучше пользователей компании-заказчика, для которых мы вместе с этими айтишниками занимаемся внедрением. Именно айтишники компании-заказчика часто влияют на выбор неоправданно более сложной системы с неоправданно более сложной архитектурой, тем самым укрепляя свою незаменимость. А пользователи интуитивно это чувствуют. Но доказать и поделать ничего не могут. “Вот они и недовольны, кто-то осмысленно, кто-то интуитивно.”

        Известный факт, что сисадмина, у которого все хорошо, никто не замечает, а сисадмина, у которого все ломается, носят на руках, как героя, который всех спасает в критический момент.

        Мне уж давно очевидно, что, предлагая на рынке простой в эксплуатации эффективный продукт со 100%-й гарантией успешного внедрения, ты, возможно, лишаешь себя наиболее крупных заказчиков с многочисленным штатом айтишников, которые по доброй воле такой продукт не выберут – их или жизнь это может заставить сделать позже или собственное начальство, озверевшее от жалоб пользователей на систему, работающую только в присутствии айтишников 🙂

        Так что архитектура, действительно, рулит! 🙂

      2. И еще на тему влияния корпоративной психологии на ИТ-архитектуру. Есть известная поговорка: “Ни одного менеджера еще не уволили за то, что он выбрал решения от IBM”. И чем крупнее компания-заказчик, тем проще принимать такие решения. При этом такие очевидные факты, что “решениям от IBM” и им подобным (“решениям от EMC/Documentum” etc.) свойственны очень высокая стоимость владения (TCO), сомнительный ROI и высокий риск провала внедрения, в расчет не принимаются – ИТ-бюджет позволяет за все заплатить. Фактический провал такого внедрения долго никем не признается – никому это не выгодно – и решение существует в вялотекущем режиме, используется 10% заявленной функциональности. Но архитектура используется очень крутая (ну,и дорогая, соответственно). Виноваты все, кроме принявшего “правильное” решение менеджера.

        Иногда только публике становятся известны удивительные факты судебных исков против поставщиков ERP о возмещении убытков на сотни миллионов долларов.

  2. Здесь стоит заметить то, что конечно есть всякие SysML и т.п. – но как-то мало практических их использований (не сталкивался пока, хотя живо интересуюсь:). Менее формально и более реально обстоит дело с моделями на основе “сервисов ресурсов”, управляющих операций и событий с ними связанных (последние версии ITIL более SOA). На основе, например, стандартов WBEM CIM, WS-Management/WS-Eventing в принципе не сложно смоделировать любое оборудование и политики его использования. Более того, например, открытая реализация http://sourceforge.net/projects/openwsman/ уже входит в поставки RHEL, позволяет прозрачно управлять MS-серверами и др., а мы строим платформу виртуализации IaaS на базе этих стандартов.

    П.С, WS-DM http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm – стоит посмотреть, но он не получил популярность – думаю – из-за сложности базового стандарта WS-Resource

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *