И вот почему: 

• От устаревшего багажа пора отказаться. Мы видим, что специалисты негативно относятся к CMDB. У многих просто не хватает воли, для того чтобы сделать последний шаг. Но нужно двигаться дальше, исправляя сделанные ошибки и глядя в будущее.

• Это не база данных. О монолитной базе данных здесь речи не идет. Скорее имеет смысл говорить об объединенной модели репозитариев, разбросанных по всей системе. Данные в них представлены в самом разном виде, зачем же искусственно формировать из них единую крупномасштабную БД? Не стоит питать иллюзий по поводу того, что единая БД будет работать!

• В модель нужно включать не только сведения о конфигурациях. Когда в 2007 году была представлена третья версия библиотеки ITIL, в качестве модели CMDB была предложена система управления конфигурациями (configuration management system, CMS). И авторы ITIL поступили правильно. Вариант с CMS гораздо лучше, но и этого еще недостаточно. Термин «система управления конфигурациями» не вполне корректен. Ограничения CMDB (и даже CMS) связаны с упоминанием о конфигурациях. Конечно, сведения о конфигурациях важны, но информационная модель будет обладать гораздо большим потенциалом, если мы расширим рамки ее действия. Она должна включать данные о производительности, кодифицированные процессные модели, политики и другую полезную информацию. Не ограничивайтесь одними лишь конфигурациями.

• Чтобы добиться точности данных, нельзя полагаться на людей. В некоторых случаях обновление данных вручную необходимо, но наша зависимость от этих обновлений слишком сильна. Новый подход к управлению сервисами предусматривает автоматизацию, которая должна обеспечить требуемые скорость и качество выполнения процедур. Всякий раз когда человек прикасается к CMDB, возникает риск ошибки. Нужна интеграция с автоматизированными технологиями. Например, при переносе виртуальной машины с одного сервера на другой все обновления должна выполнять автоматизированная система. Уберите человека от CMDB там, где это возможно. Автоматизируйте все, что поддается автоматизации.

• Сервисный каталог должен быть включен в базу данных, а не отделен от нее. Как правило, сервисный каталог отделен от CMDB. Если рассматривать CMDB в терминах иерархической структуры, контекст и смысловая нагрузка представлены на различных уровнях этой структуры. Уровни связаны друг с другом, и вы можете перемещаться по ним вверх и вниз точно так же, как увеличиваете и уменьшаете масштаб в картографических системах. Убедитесь в том, что сервисный каталог является неотъемлемой частью всей информационной архитектуры.

Как же должна называться модель? В результате долгих споров аналитики пришли к выводу, что наиболее подходящим названием для нее будет Service Information System (SIS) – сервисная информационная система. О'Доннелл призывает отказаться от термина CMDB, но не от концепции. Модель, описывающая реальность, обладает высокой ценностью, но термин CMDB тянет всех назад. В условиях повышения уровня автоматизации и перехода к более динамичным сервисам растет потребность и в достоверной контекстной информации. Термин SIS пока не вошел в употребление, но у него есть для этого все необходимое. Убедить поставщиков перейти от CMDB к SIS непросто. Ведь если клиенты хотят получить CMDB, поставщики должны им это предоставить, иначе они потеряют деньги. Глупые требования порождают глупые продукты. Но надо набраться мужества и преодолеть силу инерции, отказавшись от конформизма. Бесстрашным принадлежит будущее.