?

Log in

No account? Create an account

serge_gorshkov


Сергей Горшков - о бизнесе в сфере ИТ

о семантической интеграции, программировании, управлении...


Previous Entry Share Next Entry
Наши успехи на CeBIT'е
serge_gorshkov
Пришло время для заключительного поста про CeBIT, с рассказом о наших собственных результатах.
Мы были ориентированы не столько на поиск потенциальных клиентов (хотя общались и с таковыми, сейчас ведем по ним работу), сколько на общение с возможными партнерами. Партнеры делятся для нас на две категории: стратегические - производители ПО, с кем можно взаимодействовать по поводу развития нашего продукта (или их продукта); и партнеры по продвижению, на которых можно рассчитывать в плане продаж нашего решения. Еще одной задачей был мониторинг похожих решений, и вообще событий, происходящих в области интеграции данных. Конечно, мы не только ждали гостей на своем стенде, но и ходили общаться сами.

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

Второй подход, "европейский", состоит в использовании различных решений типа "шина обмена данными". Среди таковых наиболее интересны решения от немецкой компании Talend и достаточно распространенная шина Mule (между собой они в достаточной степени похожи). Идея шины тоже далеко не нова, однако по сравнению с "точка-точкой" это большой прогресс. Тем более, что продукты очень качественные. Вот только семантики в них нет совсем. Этих ребят я воспринимаю как возможных стратегических партнеров, и веду с ними соответствующие переговоры.

"Семантическая" тусовка, к сожалению, на CeBITе была представлена слабо (в частности, не было TopBraid'а, с представителями которого очень хотелось поговорить). Наиболее интересные мне люди, с которыми мы сейчас ведем активные переговоры - одна польская компания, производитель чудесного редактора онтологий, а также другого очень интересного семантического софта. Это пока не про интеграцию, в чем и кроется для нас большой потенциал. Кроме них, удалось поговорить с главой европейского консорциума Titan, который много лет занимается разработкой онтологий и методологий обмена информацией в сфере видеоконтента и телевещания, а также с парой компаний, которые делают узкоспециальные семантические решения.

Можно констатировать, что рынок интеграции вообще, а уж семантических методов интеграции в особенности, находится в самом начале своего развития не только в России, но и в мире. Соответственно, его потенциал просто огромен.

Тот же вывод подтверждает общение с потенциальными дилерами, которых набралось больше, чем потенциальных стратегических партнеров. Это, в основном, люди, подходившие к нашему стенду самостоятельно - представители разных компаний-интеграторов и ИТ-консультанты из Европы и Америки. Пообщаться с ними было важно и интересно не только с точки зрения установления возможных партнерских отношений, но и для диагностики готовности профессионалов рынка интеграции к восприятию семантических технологий. Они готовы.

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

А после CeBITа мы на день съездили в Амстердам, чтобы тоже было вполне интересно :)

  • 1
Сергей, полазил по вашему сайту, но так и не понял, зачем мне использовать презерватив, в виде вашего сервера, что бы скрестить банковскую АБС и 1С?
Ни слова о том, что он мне даст.

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

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

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

Еще мы можем подключить SPARQL-сервер, в который будет сбрасываться вся информация, проходящая по шине. Тогда получится, что мы сформируем SPARQL базу знаний о практически всех сторонах бизнеса нашей компании, которая даст нам такие аналитические возможности, которых ни одна ИС в отдельности дать не сможет (см. статьи о семантическом поиске, или поиске по графу).

В общем, применение нашего сервера оправдано в тех случаях, когда объединяются больше двух информационных систем, и/или они имеют часто меняющуюся структуру данных.

У меня получилось ответить на вопрос? :)

Сергей, вы человек серьезный и занятый, и не хочется отвлекать вас по пустякам, и все же...

Для меня, все специалисты по ИТ делятся на:
1. Тех кто имеет большой опыт
2. Тех кто имеет большой опыт и при этом прочитал много книжек
3. Тех кто имеет большой опыт, прочитал много книжек и написал свои
4. Тех кто имеет опыт,книжек не читал, но уже написал свои -- увы, таких сейчас тоже навалом...

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

Есть у нас коллега-"конкурент", Анатолий Левенчук, http://ailev.livejournal.com/
Он рекомендует для погружения в тему две основных книги, которые я с интересом прочел, и которые, собственно, имел в виду в этой фразе. Обе, правда, на английском.

Chris Partridge "Business Objects: Re-Engineering for Re-Use"
http://www.brunel.ac.uk/%7Ecssrcsp/BusObj.pdf

Matthew West "Developing High Quality Data Models"
чтобы скачать, надо погуглить, но я где-то нашел ее в итоге.

На самом деле, их подход можно и нужно критиковать, чем я в ближайшее время собираюсь заняться, в том числе на страницах этого блога. Но очень многое в этих книжках написано правильно (даже почти все).

Больше двух - понятно, но с часто меняющейся - нет.
Ваш сервер в конце концов соединяется с любой другой системой по "точка-точка" Пусть в нем структура не меняется, но если у вас есть 2 часто меняющихся клиента, то в любом случае надо переписывать обмен (ну или переконфигурировать) при каждом изменении в любом клиенте.
Так не все ли равно, что переписывать, обмен в целевую систему, или обмен в ваш сервер?

Да, сервер соединяется с клиентскими системами через интерфейс "точка-точка", но этот интерфейс никак не зависит от структуры данных в каждой конкретной системе. У нас реализован, так сказать, транспортный протокол, который от специфики передаваемых данных вообще никак не зависит.
Конечно, со стороны клиента полученные данные необходимо обработать, а именно - преобразовать из семантической формы обратно в табличную. Для этого используется мэппинг (в простейшем случае, когда элементу схемы - сущности или атрибуту - мы можем однозначно сопоставить элемент БД, таблицу или поле), или пишется скрипт-обработчик, если логика сложнее.
Конечно, если мы добавляем новое поле, клиентский модуль нужно переконфигурировать - определить этот самый мэппинг. Обычно для этого достаточно трех щелчков мышью в админском интерфейсе: выбрать соответствующее поле для нового элемента схемы.
Но если, скажем, поле удалено - то обычный обмен "точка-точка" скорее всего встанет, в нашем же случае ничего не произойдет вообще; удаленное поле просто будет игнорироваться.

Спасибо за разъяснание.

  • 1