Open Graph: Третье поколение глобальной сети

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

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

Facebook Graph API

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

Мобилизация корпоративных информационных систем и дилемма инноватора

Если бы лет пять назад вы спросили программиста, будет ли в будущем его приложение работать на андроиде то, в лучшем случае, он счел бы вас эксцентричным фанатом «Звездных войн». Сегодня вопрос предоставления сотрудникам доступа к корпоративной информационной системе с мобильных устройств звучит вполне обыденно. Вопрос не в том, предоставлять ли такой доступ, а скорее – как это сделать. Очевидный ответ на него: разработать для приложений мобильные клиенты – мне представляется нечестным и трудно реализуемым. На протяжении последних пятнадцати лет мы регулярно переписываем свои корпоративные системы. Сначала мы переписывали их в архитектуру клиент-сервер, потом переписывали на Java, затем готовили к проблеме 2000. С появлением серверов приложений мы снова их переписывали.

Адаптивный кейс-менеджмент и основные данные

Перед отпуском я написал серию сообщений о SOA, ESB, EDA и Master Data Management. Потом я написал о том, как собрать это все вместе. А по возвращении из отпуска позволил себе добавить в эту конструкцию еще и BPM. Но честно говоря, я еще не сказал главного, о чем мне и напомнил доклад Анатолия Левенчука “Между проектами и процессами: адаптивное управление кейсами”. Настоятельно рекомендую его послушать.

Прежде чем перейти к главному, я все же соберу ссылки на все упомянутые выше сообщения:

• 10.07.2011 Event-driven architecture. Размышления о том, является ли SOA архитектурой и нужна ли для её построения ESB.
• 17.07.2011 Как сделать хороший API? О необходимости абстрагирования для построения повторно-используемых программных интерфейсов
• 12.08.2011 Интерес к управлению данными возвращается.
• 15.08.2011 Master Data Management, EDA, ESB, SOA: собираем все вместе. О том, что для управления основными данными нужна и сервисная шина и управляемая событиями архитектура.
• 17.09.2011 … добавляем бизнес-процессы. Несколько рассуждений о BPM и MDM вместо сочинения о на тему «как я провел лето»

Как внести больше смысла в структуры основных данных

На прошлой недели меня пригласили на встречу, организованную для ИТ директоров одним из известных поставщиков решений класса master data management. Значительная часть обсуждения была посвящена вопросу как «продать» бизнес-заказчику MDM решение. Безусловно, у такого рода проектов должен быть именно бизнес-заказчик. Однако, выгоды внедрения новой системы для ИТ тоже должны быть обозначены. Иначе ИТшники будут сидеть и ждать пока бизнес созреет и сам принесет им MDM-проект. Ниже я постарался набросать несколько собственных мыслей на тему зачем нужен MDM ИТ директору.

Интерес к управлению данными возвращается

В конце июля – начале августа этого года Gartner выпустил целую серию исследований посвященных управлению данным:

• Hype Cycle for Data Management, 2011
• Hype Cycle for Master Data Management, 2011
• CIO Alert: You Need Information Professionals
• и еще несколько статей

Интерес к теме управления данными у Gartner присутствовал всегда, но если раньше в исследованиях преобладали рассуждения о роли управления основными данными (master data management) для успеха SOA или BPM проектов, то сейчас тема данных стала вполне самодостаточной. На вершине пика завышенных ожиданий информационной архитектуры предприятия находится Semantic Web. Правда в мэйнстрим корпоративных информационных систем попадет он еще не скоро. О возможностях использования Semantic Mediawiki для отображения архитектуры предприятия я рассказывал некоторое время тому назад на заседании Клуба архитекторов Microsoft и на SOA мероприятии AHConference Архитектура предприятия в формате Semantic Web Подходят к пику ожиданий: Complex-Event Processing, Enterprise Taxonomy and Ontology Management (Таксономия и фолксономия), Data Services, Enterprisewide Metadata Repositories.

А вот Master Data Management покинул пик ожиданий и начал сползать в котлован разочарований. Т.е. интерес к MDM будет угасать, а недовольство высокой стоимостью MDM решений – расти. На мой взгляд, это совершенно несправедливо, т.к. практической пользы от MDM можно получить существенно больше, чем например от сервисов. Master Data Management – тема не очень новая и не очень сложная. Введение в тему можно почитать в статье Задачи управления мастер-данными Некоторое замешательство могут вызвать русскоязычные аналоги этого понятия «управление основными данными» и «нормативно-справочная информация». Но, в общем и целом большинству людей понятно, что речь идет о синхронизации справочников из различных информационных систем предприятия. Есть транзакционные данные, т.е. записи о конкретных операциях и есть справочники, на которые ссылаются транзакционные данные. Под мастер-данными (основными данными) и понимают справочники в широком смысле, т.е. существительные, отвечающие на вопросы «кто?» (клиенты, сотрудники, партнеры), «что?» (продукты, услуги), «где?» (адреса) и т.д. Наведение порядка в справочниках – задача скорее организационная, чем техническая. Впрочем, технические проблемы, являющиеся в данном случае прямым следствием организационно-политических причин,  присутствуют тоже

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

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

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

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

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

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

О навешивании ярлыков

В то время как корпоративным блогам и вики уделяется достаточно много внимания, про corporate tagging говорится намного меньше. Да и решений таких практически нет, быть может, за исключением нескольких расширений для SharePoint. Но тема, на мой взгляд, более чем перспективная. Я немного писал уже о тегах в сообщении [За]метки на полях Не стану повторятся о том что роднит их с ссылками, особенно семантическими ссылками. Напомню лишь о похожести меток и внешних ключей в реляционных базах данных. Так в чем же скрывается польза использования корпоративных тегов?

Дело в том, что корпоративные информационные системы просто изобилуют справочниками. Внутри каждой системы их огромное количество. Есть справочники типов документов, адресов, продуктов и услуг, сотрудников, ролей и т.д. и т.п. Системы не могут работать без справочников. Значительную часть вводимых данных пользователи выбирают из выпадающих списков, заполнение которых и производится из справочников. Проблема в том, что ведение справочников является довольно трудоемкой задачей. Кроме того, когда систем становится много, неизбежно возникает задача синхронизации справочников в различных системах. Задача интеграции приложений это, как минимум наполовину, задача интеграции справочников. И делается это вполне незатейливым способом – периодическим копированием данных из одной системы в другую. Ирония в том, что одна из базовых веб-технологий, а именно технология гиперссылок URL/URI давно решила проблему адресации объектов. Причем решила её не в рамках корпоративной сети некоторой компании, а в глобальном масштабе. В корпоративных базах данных давно пора поменять половину внешних ключей на гиперссылки. Однако бизнес-приложения базируются на закрытых технологиях и ожидать в ближайшее время такого подарка от жадных вендоров нам вряд ли стоит.

Если что-то и можно сделать в краткосрочной перспективе, так это организовать единую в рамках предприятия систему, поставляющую теги и категории другим системам. Даже такой простой шаг существенным образом снизит затраты на интеграцию и уменьшит неразбериху в корпоративной среде

Семантическая сеть предприятия

Последнее время мне все чаще хочется каких-то странных вещей. Хочется дождя, хочется снега, хочется новую  информационную систему. Систему похожую, то ли на twitter, то ли на wiki, одним словом хочется следующего:

Система, под условным названием Links должна хранить семантические отношения между всеми объектами компании: сотрудниками, проектами, задачами, документами и т.д. Принцип очень простой. Система Links, во-первых, вытаскивает списки объектов из разных систем, а во-вторых предоставляет программный интерфейс для всех этих систем.

Пример варианта использования такой системы:
Руководитель проекта создает новый проект в корпоративной системе управления проектами. Для назначения ролей участникам рабочей группы проектная система вызывает соответствующий программный интерфейс Links и предоставляет список, ну например архитекторов. Руководитель проекта выбирает архитектора, что приводит в системе Links к образованию семантической связи между проектом и конкретным сотрудником. Естественно, система работы с персоналом может запросить у Links список проектов, в которых участвует конкретный сотрудник. В общем, механизм прямых и обратных ссылок из MediaWiki, только вынесенный в отдельное хранилище и независимый от остальных систем.

Может кому-нибудь доводилось видеть что-то подобное? Поделитесь, пожалуйста, знанием

Почему архитектура нуждается в социальном ПО

В предыдущей заметке я позволил себе назвать появление UML основным событием в современной архитектуре информационных систем. Сегодня я подробней коснусь реализующих UML инструментов. Вернее, не существующих на сегодняшний день инструментов, а инструментов какими они должны быть.