Опыт: Нельзя без стандартов

Дэвид Бикет: SAM – это операционная дисциплина. У нее, как и у бизнес-деятельности, есть определенные результаты. У бизнеса – это продукты или услуги, а результаты SAM – это сервисы. SAM обеспечивает распределение и установку ПО на компьютерах, управление его использованием, удаление, когда оно перестает быть нужным. Таким образом, SAM создает сервисную инфраструктуру, поддерживающую весь жизненный цикл ПО для бизнеса.

В прессе очень много внимания уделяют выполнению регулятивных норм в отношении лицензий (license compliance). Но SAM – это не то же самое, что license compliance. Это лишь компонент общей compliance. Как всякая операционная деятельность, SAM обязательно включает в себя функции управления рисками, в том числе обеспечение соответствия – и это нельзя сводить только к обеспечению соответствия лицензий нормативным требованиям. Есть другие типы соответствия – например, корпоративным политикам использования ПО. Если в вашей компании всех сотрудников обязывают применять только Lotus Notes, то в рамках SAM должно проверяться выполнение этой политики: на рабочих местах не могут появляться продукты Microsoft или системы с открытым кодом. И безусловно, ключевыми для SAM являются вопросы безопасности. Меня поражает, что в компаниях предпочитают изолировать эти области. Наиболее распространенный подход: «Я занимаюсь SAM и не собираюсь общаться с кем-либо еще». А специалистов по безопасности никогда не интересуют проблемы управления программными активами.

Олег Седов: Как сейчас выглядит эволюция стандартов SAM?

Д.Б.: В 2006 г. был принят стандарт ISO 19770-1, который описывал процессы управления программными активами. Это был первый стандарт в области SAM. Вначале он не привлек большого внимания, однако к настоящему времени интерес к нему значительно вырос, и сообщество профессионалов заинтересовано в его развитии.

Сейчас завершается работа над новой версией стандарта, определяющего четыре возможных уровня SAM. Замысел первой версии стандарта был слишком грандиозным. В результате организации, которые хотели сертифицироваться по этому стандарту, должны были соответствовать огромному числу детальных требований. Первая версия стандарта написана как спецификация продукта – «да/нет, да/нет, да/нет». Это не вполне оправданно с точки зрения системного управления. Сертификация по второй версии даст возможность оценивать соответствие относительно заданных целей. Хотя при желании компании смогут сертифицироваться по разным уровням SAM и в соответствии с первой версией. Но каждый стандарт имеет пятилетний цикл обновления, поэтому самое большее через пять лет все стандарты управления будут приведены к единому виду.

О.С.: Не секрет, что CIO и так загружен большим количеством проектов. Зачем ему нужен еще один проект – SAM?

Д.Б.: Это новый уровневый процесс. На первом уровне достаточно получить надежные данные. Когда вы этого достигли, вы получаете возможность определенной степени контроля. Данные вам показывают, что вы покупаете в разных источниках, покупаете неэффективно, покупаете продукты, которые не входят в утвержденный список, или позволяете устанавливать в компании игры и прочий мусор, который может быть зловредным. И когда вы получите все эти достоверные данные, у вас в руках не только набор проблем, но и возможности их устранения.

О.С.: Каким образом на развитие стандарта влияют современные технологии, в частности облачные технологии?

Д.Б.: Что касается SAM и облака, они очень тесно между собой связаны. Процессы управления чем угодно в принципе одинаковы. Но как мы управляем в облаке? Все задачи, которые должны решаться в облаке, существуют уже давно. Люди как-то решали эти проблемы раньше, но они были разрозненными. Нет такого решения, которое было бы чисто облачным и не было бы решением для чего-то еще – будь то безопасность, защита данных, управление лицензиями.

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

Все абсолютно согласны, что необходимо распределять лицензии. Вопрос, до какого уровня вниз. Я считаю, что до того, который вам необходим, чтобы обеспечить управляемость. Наихудший пример – лицензии клиентского доступа (CAL). Если я сегодня пытаюсь управлять этими лицензиями, то ситуацию невозможно качественно проконтролировать. Я могу взять свой компьютер с CAL и получить доступ к серверу в любой облачной среде. Кто бы ни был владельцем сервера, технически эта лицензия мне дает такое право. Но если есть процесс распределения лицензии до уровня индивидуального компьютера, сервер в моей компании будет видеть, что я имею право к нему обращаться. Партнерский компьютер и любой компьютер в облаке тоже может подтвердить мои права. Это пример того, как технологии в управлении лицензиями можно использовать в облаке для решения проблем, которые сегодняшними средствами решить невозможно.