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

Можно много говорить о том, что есть лучший продукт в данной области. Можно оперировать понятием цены, а можно еще раз посмотреть на картинку от уважаемого во всем мире экспертного издания Gartner. Можно создать свой продукт, который будет лучше решать мелкие оперативные задачи, а можно “жизнь положить”, дабы понять, как же работает этот “замечательный” BizTalk. Но, повторю еще раз: ни одно программное обеспечение не может и не должно стоить дороже, чем оно позволит вам сэкономить/заработать. Не занимайтесь overengineering-ом, реально смотрите на вещи: какие процессы берут больше всего времени? что можно автоматизировать? какая коммерческая выгода может стоять за возможностью быстро менять условия бизнеса?

Это для бизнеса. Для разработчиков выгода очевидна: пускай бизнес занимается бизнесом. Компании, правила валидации, расчеты скидок – это их головная боль. Вы хотите создавать новую функциональность, интегрировать решения, оптимизировать работу базы данных – пожалуйста. Найдите подходящую вашим условиям BRMS (Business Rule Management System) – и научите других ею пользоваться. Найдите именно BRMS, а не простой BRE (Business Rule Engine), коим сейчас является JBoss Drools. Причины очевидны: ни одна секретарша не поймет смысл кода правила. Она поймет обычное выражение на понятном и привычном языке. Она поймет, когда ей графически пояснят, кто, где и зачем изменил что-либо. Она же понимает Word и Excel, да? Так пускай она создает бизнес-правила в Office и сохраняет их в Sharepoint? (Речь идет, например, о продукте ILOG Rules for .NET)

Что остается вам? Ведь вам чем-то придется заниматься; не просто же вы инсталлируете систему, пойдете пить кофе и выдумывать новый изящный алгоритм интеграции пива с водкой путем синхронизации их потоков в желудке.

Вам придется решить некоторые вопросы по инфраструктуре (в скобках ответы для ILOG):
1) куда вы “поставите” BRMS? (три варианта: stand-alone application, embedded container, jar в вашем приложении)
2) как вы будете “общаться” с BRMS? (поддерживаются все необходимые стандарты с точки зрения SOA)
3) какую модель данных вы используете для создания правил? (в случае множества приложений есть возможность использования динамической модели, основанной на HashMap-ах; все модели создаются и вербализируются в Rule Studio (модуль для Eclipse), а правила можно создать, напимер, и через удобный вэб-интерфейс с помощью мышки и меню в стиле drag-and-drop)
4) какие языки должна корректно поддерживать вербализация этих объектов, что бы та самая секретарша поняла, о чем речь? (out-of-the-box: английский, немецкий, французский, испанский, японский, упрощенный китайский; в разработке есть и другие языки, как то русский, например; каждый будет видеть необходимое правило на том языке, который ему наиболее понятен)
5) как организовать систему доступа и безопасности? (не имеет по умолчанию своей системы доступов; вы можете использовать или LDAP, или ActiveDirectory, или чего-нибудь еще на свое усмотрение. используя общую систему допусков для всей фирмы, кто-то сможет лишь создавать правила, кто-то – проверять их, кто-то – ставить им статус “к исполнению”)
6) что делать, если модель разрастется до невероятных размеров и станет тяжело определять, какое свойство необходимо в данный момент? (есть поддержка domain-ов, т.е. при определении конкретной категории (domain), wizard правила будет давать только используемые в данной категории объекты)
7) как избежать дублицирования кода, когда многие процессы схожи в каких-либо деталях? (есть возможность переписывания выполнения каких-либо правил, исходя из контекста; создается общий алгоритм, и, в зависимости от предопределенных условий, выполняются те или иные правила, написанные один раз каждое)
как тестировать полученные правила? (а почему бы не через тот же самый Excel?)
9) как скалировать систему при увеличении потока информации? (не имеет ограничений по скалированию; с точки зрения нагрузки, системе все равно, сколько в ней правил – 1000 или 100; она работает одинаково быстро, выбирая оптимальный алгоритм запуска в зависимости от задачи приложения)
10) как проверить систему на целостность и правила на адекватность? (встроенный аналитический tool найдет и те правила, которые взаимно исключают друг друга, и те, которые никогда не выполняются)
11) как получить поддержку? (профессиональные консультанты всегда подскажут наилучшее решение в той области, где вы хотите применить BRMS. ведь найти неизведанные до вас места достаточно трудно: опыт работы с eBay, VISA, JPMorgan, FannieMae, First Union, Nokia, FedEx, US Department of Homeland Security, Mexican Tax Department, Lufthansa, British Airways, Nissan, Hallmark, Pfizer работает на вас, а front-line support, например, находится на расстоянии одного телефонного звонка по Эстонии)

Полноценный тренинг и для разработчиков, и для аналитиков длится 4-5 дней. Это не сложно и намного проще, чем запустить ракету в космос. Но о деталях имплементации стоит задумываться не раньше, чем родится финансово обоснованная мысль об изменении модели построения системы. Ведь бесплатных решений не бывает – это все блеф. У одних – платная поддержка, а для других требуется серьезное инвестирование ресурсов, дабы понять, как заставить это работать в текущей среде. А еще и “заплатки” самому писать…

И последнее: сейчас везде популярно вставлять такие словечки как BPM (Business Process Management) и SOA (Service-Oriented Arhitecture). Да, для BPM третьего поколения BRMS является неотъемлимой частью. А знаете ли вы, что в мире, например, у Oracle нет ни одного примера решения формата world-wide enterprise-wide BPM? Рефакторинг систем с точки зрения SOA – это огромные затраты и “много крови”. Очень много. Поэтому, если уж и следовать трендам, то стоит начать с выбора BRMS, а дальше… может, вам и не потребуется ничего больше.

Ку всем!

Итак, вчера, 30 января сего года мы все имели удовольствие побывать в стенах славной фирмы Ericsson и обсудить, для чего нужны прагматичные экспертные системы для суровых сибирских мужиков.

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

Всего было 3 доклада – 2 о JBoss Drools и один про ILOG.

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

Небольшое резюме про Drools.

Drools – это прежде всего так называемый rule engine, который может исполнять правила закодированные на Drools-specific диалекте. Начиная с 5й версии Drools позиционируется как интеграционная платформа, и тем самым патается вклиниться в нишу уже довольно сильно занятую ILOG-ом.

Drools вкрючает в себя 4 модуля:

1. Expert – это ядро Drools, с помощью которого правила компилируются и исполняются.
2. Flow – движок для поддержки workflow.
3. Guvnor – web-based система управления правилами, которая включает в себя средства разработки правил, тестирования и администрирования оных.
4. Fusion – модуль поддержки событий, на базе которого можно будет реализовывать системы для сбора статистики, мониторинга и тд. К сожалению этот модуль пока ещё не задокументирован, поэтому на встрече я о нём не рассказал.

Блог разработчиков JBoss Drools находится тут.

Когда использовать Drools? Вам нужно реализовать возможность изменений “на лету”, при этом бюджет проекта ограничен. В идеале это будет правильным подходом только в том случае если вы можете описать логику приложения в декларативной манере с помощью if-then предложений. Если нет – советую поискать что нибудь другое.
Когда не использовать Drools? Drools находится постоянно в разработке и его исходной код очень часто меняется до неузнаваемости. Если у вас солидный клиент, которому требуется солидное ИТ-решение, тогда думаю, что Drools стоит отложить до лучших времён.

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

Кстати, Артём сделал хороший обзор того, о чём мы весь вечер говорили (по большей части об ILOG), прямо во время встречи, за что ему можно дать почётное звание стенографиста девклуба .

Зя презентация от Андрея Солнцева про реальный пример использования JBoss Drools в его проекте. Это хороший пример того, что системы такого рода имеют право на жизнь.

Теперь о мыслях которые возникли в связи с презентациями и вопросами.

Номер Ноль. Было видно что люди собрались креативные и здравомыслящие, поэтому вопросы которые сыпались очень часто опережали события. Это хорошо! Значит все в теме и никто не спит. Можно взять за правило, что если у докладчика в презентации через несколько слайдов будет как раз ответ на этот вопрос, то можно так и сказать – оббожите!. Иначе если начать отвечать на вопрос, то частенько это превращается в цепную реакцию, или как ктото заметил в “битьё морд”

Номер Раз. Глупые вопросы – самые классные – не бойтесь их задавать. Это дайт докладчику возможность почувствовать себя умным

Номер Два. Народ хочет видеть код. Однозначно! Возьму себе за урок, что в другой раз надо для начала сделать демку, а потом уж нарисовать пару слайдов. Так интересней.

Номер Три. Не стоит пытаться подобрать тему именно в по какой то технологии. Многим было бы интересно узнать о решении реальной проблемы, а-ля – вот проблема, вот грабли, наступили – шишка, вот так то лечили… Это входит в сущность technology exchange, когда мы можем поделиться реальным опытом, а не гипотелическими решениями на базе мега-фреймворков.

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

Номер Пять. Для наведения порядка и слежением за временем было предложено, что будет введена “должность” модератора (ака “хост”), который должен быть в теме докладов и гасить ненужные вопросы. Есть ещё предложение что этот же модератор и будет открывать вечер такой же зажигательной речью как Захар в пятницу

ИТОГО
Думаю, все поддержат мысль, что следующей встрече быть! Было видно, что всем понравилось. Я даже слышал восклики восторга – “Это же круто!”. Ну и на фотках видно, что все довольны

Вобщем, комментируйте, господа!