О странностях отношений между SOA и BPM

Бойтесь своих желаний

Если с высоты птичьего полета посмотреть на развитие hype-ов SOA и BPM, и сделать это с некоторой долей юмора, то ситуация будет выглядеть так.

Сначала появилась сервис-ориентированая архитектура. SOA базируется на идее выделения типовых бизнес-операций в отдельные компоненты – сервисы. Проникнувшись этой идеей, ИТ-шники направились в двух направлениях: создавать сервисы и «продавать» идею бизнесу. В первом начинании они, безусловно, преуспели существенно больше чем во втором. Уже в начальные годы шествия SOA мы услышали от ИТ отделов множество репортов о десятках разработанных сервисов.

Затем на сцену вышла идея управления бизнес-процессами (BPM). Одним из составляющих этого движения явилось появление систем управления бизнес-процессами (BPMS). Непременным атрибутом таких систем является движок для оркестровки сервисов, т.е. разработки некоторых «больших» бизнес-процессов из «маленьких» подпроцессов-сервисов.

А потом появился Adaptive Case Management (он же dynamic case management по версии Forrester и он же advanced case management по версии IBM). Одну из основных идей этого течения я бы озвучил так: «BPMS нам не нужен! Дайте нам сервисы, и мы сами будем складывать из них бизнес-процесс, адаптируя его под каждый конкретный случай по своему разумению». Т.е. бизнес проснулся (сам или же разбуженный вендорами – не так важно) и наконец, осознал все преимущества сервис-ориентированного подхода. И не просто осознал, но уже желает самостоятельно, на лету собирать из кубиков лего-сервисов необходимые ему процессы.

А разве не об этом мечтали несколько лет назад первопроходцы SOA?! 😉

Glassfish ESB v2.2

Вообще-то, версия 2.2 интеграционной шины GlassFishESB появилась еще в январе 2010 года. Но, по целому ряду причин, переходим мы на неё только сейчас. Переходим из-за того, что в это релиз вошел ряд критичных для нас исправлений. Но рассказать я хочу как раз не об исправлениях, а о появившемся в 2.2 новом функционале. Читать далее Glassfish ESB v2.2

Enterprise architecture в Клубе Архитекторов Microsoft

Вчера выступал и, что более содержательно, слушал чужие доклады и обсуждения, в Клубе Архитекторов Microsoft. Несколько наблюдений по горячим следам Читать далее Enterprise architecture в Клубе Архитекторов Microsoft

Enterprise architecture vs. BPM

В блоге Анатолия Белайчука появилась заметка Граница между инструментарием EA и BPMS. Желание провести такую границу абсолютно уместно. Не выполненных обещаний архитектуры предприятия, BPM сообщество  просто не потянет. С другой стороны, накопленный Enterprise architecture опыт реальной деятельности в компаниях, тоже не стоит сбрасывать со счетов. Тем более, что ошибки у корпоративных архитекторов и специалистов по управлению бизнес процессов одинаковы: Читать далее Enterprise architecture vs. BPM

Вершки и корешки

Не смог побороть кодировки  на сайте Intellegent enterprise потому и написал комментарий к статье  Ольги Мельник Полезные зерна Enterprise 2.0 в своем блоге

Вполне ожидаемые выводы экспертов. Предприятия воспринимают Enterprise 2.0 пока очень односторонне. Я бы охарактеризовал это восприятие как Интранет 1.0. В Enterprise 2.0 пока видят всего лишь внутренний веб-сайт, дополненный возможностью писать комментарии и статьи. Отличие от традиционного и давно знакомого интранет сайта, разве что в скорости публикации, да и то не всегда.

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

RESTful и Enterprise 2.0

В 2006 году профессор Andrew McAfee, по аналогии с термином Web 2.0, придумал термин Enterprise 2.0. Для пояснения этого термина он использовал аббревиатуру SLATES (Search, Links, Authorship, Tags, Extension, Signaling), описывающую набор требований к Enterprise 2.0 решению. В дальнейшем это понятие стали развивать, улучшать и трактовать в разных смыслах, что существенно затуманило понимание вопроса. Зато дало большой простор для дискуссий не темы типа: является ли Sharepoint решением Enterprise 2.0.

В 2000 году Roy Fielding придумал и описал архитектурный стиль RESTful, который частенько позиционируют как стиль Web 2.0. Понять, что же Филдинг подразумевает под «REpresentational State Transfer» могут не многие. Поэтому, в отличии от истории с Макафи трактовки REST, как самим Филдингом, так и его приверженцами оказали бы вполне кстати. Объединяя обоих авторов, я предлагаю свою трактовку приложений Enterprise 2.0: Читать далее RESTful и Enterprise 2.0

[За]метки на полях

Я давно собирался написать о том, почему метки (они же ярлычки, они же тэги) являются не только удобным способом классификации сообщений в блоге и инструментом эффективного поиска. За этим механизмом скрывается намного более мощная идея. Идея структурирования данных «на лету». Сейчас стало модным к любому понятию приписывать слово dynamic. Так вот метки – это механизм реализации динамических структур данных. Только мы, вскормленные на  реляционной модели данных, об этом совершенно не задумываемся.

Читать далее [За]метки на полях

Петли обратной связи

Управляющие процессы изобилуют корректирующими петлями (запросами на проверку и уточнение)

Не маленьких размеров камешек забросил в огород любителей тяжеловесных формализованных процессов Алистэр Коуберн в работе «The New Face of Software Engineering». Алистэр очень педантичный исследователь и потому, разбирая ту или иную тему, докапывается до сути. Его рассуждения интересны и поучительны.

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

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