Метка: CMDB

Вторая половина шахматной доски

chess masterТот энтузиазм, с которым компьютерное сообщество обсуждает сейчас тему Big Data, свидетельствует о том, что они сами не ведают, что творят. Футуролог Рэймонд Курцвейл, известный книжками по технологической сингулярности (гипотетический момент, по прошествии которого, технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию см. википедию ) ввел в обиход термин вторая половина шахматной доски. Как известно, изобретатель шахмат попросил в качестве награды положить на первую клетку доски одно зерно, на вторую – два, на третью четыре и т.д. Общее количество зерен на шахматной доске составит 2 в 64 степени без 1, а это очень и очень много. Однако, количество зерен, которые следует разместить на первых клетках шахматной доски, не кажется таким большим. Даже на 32 клетке будет всего 2 гигабайта зерен. Это примерно сто тонн риса. Это полтора современных железнодорожных вагона, предназначенных для перевозки зерна.  Термин вторая половина шахматной доски  сейчас активно используется в экономике и управлении, например в книжке “Race Against The Machine” By Erik Brynjolfsson and Andrew McAfee. Продолжить чтение «Вторая половина шахматной доски»

Facebook Graph API

Я довольно давно не затрагивал тему adaptive case management. Не затрагивал, не потому что она мне стала не интересной. Просто последние несколько месяцев у меня очень много работы, связанной с практической реализацией ИТ поддержки такого рода процессов. В первую очередь, речь идет о процессах решения телеком инцидентов. Это тысячи тикетов ежедневно, необходимость оперативного доступа к данным о клиентах, договорах, адресах подключений, данным по сетевому оборудованию и предоставляемым сервисам. Все это по-разному работает для разных типов услуг, линий бизнеса, в разных информационных системах. Этот практический опыт подтверждает мои предыдущие наблюдения. Если бы мне сейчас пришлось писать Adaptive Case Management Manifesto я бы начал с того, что гибкость бизнес-процессов достигается разделением приложений для совместной работы и приложений управления данными.
Продолжить чтение «Facebook Graph API»

Service Knowledge Management System

Недавно, в заметке О том как вендоры и аналитики победили ITIL я поспешил посетовать на технологическую отсталость баз данных управления конфигурациями CMDB. Безусловно, я был не прав. Нельзя по одной системе от конкретного вендора, используемой в нашей конкретной организации судить о всех системах подобного класса. Немного погуглив я наткнулcя на ряд интересных статей Hank Marquis-a:

Продолжить чтение «Service Knowledge Management System»

О том как вендоры и аналитики победили ITIL

Наверное, я один из немногих читателей книжки Роба Ингланда «Овладевая ITIL», которым эта книжка не нравится. Не нравится не потому, что я не согласен с приводимыми автором фактами и выводами. Наоборот, с большинством суждений о роли, месте и истинных мотивах популяризаторов ITSM я согласен. Мне не нравится подход IT sceptic-а. На протяжении всей книжки автор пишет о том, что построение ИТ-сервисов в соответствии с ITIL это очень дорого не всегда нужно, и потому предлагает действовать более прагматично. В одном направлении немножко поработать с процессами, в другом – немножко, вот всем и станет немного лучше. Продолжить чтение «О том как вендоры и аналитики победили ITIL»

Таксономия и фолксономия

Прошедшие выходные я провел за «увлекательным» занятием классификации информационных систем нашей компании. Выгруженные из Configuration management database (CMDB) приложения и из Human Resource management system (HRMS) сотрудники были подвергнуты различным inner, outer и cross join-ам . Естественно, делал это я не в трудовом порыве, а по служебной необходимости. Чтоб время, эмоции и силы были потрачены не совсем зря, изложу своё понимание терминов таксономия, фолксономия, агрегация и композиция в применении к современным информационным системам, в частности к CMDB.

Традиционно под таксономией понимали жесткую классификацию объектов, управляемую централизованно, а под фолксономией классификацию, задаваемую пользователями. В качестве примера часто приводятся метки(теги) и категории. Т.е. добавление тегов к сообщению в блоге – это фолксономия, а категорирование статей – это таксономия. На самом деле, этот пример немного неряшливый. Большинство блогов позволяет менять метки(теги) только автору сообщения (или админстратору), поэтому называть это фолксономией не верно. С другой стороны, категории сообщений довольно похожи на метки и допускают свободное включение сообщений одну или несколько категорий.

Данная гибкость существенно отличает социальное ПО от традиционных бизнес-приложений. Для корпоративных справочников речь даже не идет об использовании тегов или категорий. Ситуация значительно хуже. Сплошь и рядом при разработке корпоративных информационных систем происходит подмена понятий агрегация и композиция. Напомню, что согласно UML агрегация – это такое отношении между классами, при котором один класс является частью другого (обозначается белым ромбиком), а композиция – это частный случай агрегации, когда часть и целое не могут существовать друг без друга(обозначается черным ромбиком). Т.е. программист, пришедший на работу, состоит с ней в отношении агрегации. А вот мысли этого самого программиста находятся с его головой в отношении композиции. Тем не менее, извечной практикой проектировщиков баз данных является прибивание гвоздями объектов, не состоящих друг с другом в отношении композиции.

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

На самом деле, разница между таксономией и фолксономией следующая. В случае таксономии, решение о включении или не включении определенного объекта в группу(отнесении к категории) принимает владелец этой группы. Т.е. если компания считает необходимым категорировать документы атрибутом «важно!», то в случае таксономии должен быть назначен сотрудник, отвечающий за присвоение документам данного атрибута. Категорий, подкатегорий и видов классификации, и ответственных за них, может быть произвольное количество. Одни отвечают за иерархию категорий «важно!» , другие за иерархию категорий «срочно!» и т.д. Если же категорирование отдается на откуп авторам документов, то это фолксономия (что, впрочем, не исключает возможности  учета принадлежности объектов  категориям). Возвращаясь к корпоративным справочникам. Если классифицирующие объект поля вносятся в структуру данных объекта, то это – плохая архитектура данных. Никакого отношения ни к таксономии ни к фолксономии такая архитектура не имеет.