Процессы vs. сервисы.

В недалеком прошлом я активно занимался тематикой workflow. Так вот, я всегда считал процессный подход исключительно эффективной методикой и средством для разработки корпоративных приложений. Попробую кратко описать, в чем он состоит. Термин «бизнес процесс» из числа тех, которые имеют очень широкую трактовку. В зависимости от того, кто его употребляет, каждый вкладывает в него свой смысл. Для менеджера и бизнес аналитика бизнес процесс - это согласованная, управляемая и систематическая (повторяемая) совокупность активностей участников (действующих лиц), направленная на достижение определенных бизнес целей предприятия. Для проектировщика или архитектора, бизнес процесс это совокупность бизнес объектов (данных), бизнес операций (функций), исполнителей и бизнес правил, описывающих последовательность исполнения и взаимосвязи исполнителей операций и данных. Естественно, что первые оперируют реальными бизнес процессами, а вторые - их отражением в информационных системах.
Процессный подход подразумевает, что разработка системы строится вокруг реальных бизнес процессов предприятия. Начиная с фазы анализа, проектирования и заканчивая сдачей в эксплуатацию и дальнейшей поддержкой и модификацией системы. Что делает такой подход эффективным? Первое, бизнес процессы направлены на реализацию бизнес целей предприятия. И это очень важно, ведь таким образом, создаваемая система имеет прямой выход на конкретные бизнес цели. Заказчику понятно, что система делает для его бизнеса. Второе, это комплексный подход. Бизнес процессы обычно пронизывают несколько функциональных областей, таких как закупки, производство, сбыт, управление взаимоотношений с клиентами, управление персоналом и т.п. На границах этих областей обычно возникают проблемы, которые снижают эффективность информационных систем. Процессный подход – хорошее средство от подобных проблем. Кроме того, сила процессного подхода в грануляции функционала на элементарные бизнес операции, и отделение бизнес операций от логики самого процесса (такой как, например, последовательность исполнения операций). Как результат высокая адаптивность системы. Операции могут компоноваться в новые и новые процессы, а сами процессы могут легко изменяться в соответствии с изменчивыми потребностями бизнеса.
Вот здесь лежит очень важная точка соприкосновения двух концепций: процессного и сервис ориентированного подхода. Вы не находите?
Слабо связанные, автономные и независимые сервисы идеально подходят на роль поставщиков бизнес операций для процессного подхода. А среда исполнения бизнес процессов замечательно смотрится как надстройка над SOA, или вернее как ее составная часть. Я считаю, что, например, в роли сервисной шины предприятия (ESB), workflow ориентированная среда исполнения бизнес процессов будет намного эффективней традиционных шинных архитектур основанных на очередях сообщений.
В общем, как ни крути, а получается вот она, серебряная пуля – «SOA + процессный подход», на основе которой будут создано новое поколение корпоративных информационных систем.
К сожалению, практические опыты серьезно омрачили этот светлый образ будущего благоденствия. Основные проблемы возникли в степени адаптивности получаемых решений, т.е. именно там, где предполагалось пожать самый большой урожай бенефитов от нового подхода.
Вот, к примеру, разрабатываем систему управления оплатой счетов на текущие расходы компании (accounts payable). Начинаем анализ с определения бизнес процессов, которые собираемся автоматизировать. Бизнес процесс не сложен: все текущие расходы, как-то: канцелярские принадлежности, транспортные, рекламные, представительские, и другие расходы связаны с оплатой выставленных счетов. Заявки на эти расходы должны быть согласованы, а счета своевременно оплачены. Бизнес цели тоже понятны: оптимизировать расходы, обеспечить своевременную оплату счетов, увязать расходы с бюджетами и финансовым планированием. В соответствии с процессным подходом, выявляем действующих лиц и исполнителей, источники и потребителей информации, информационные потоки и основные бизнес операции. Компонуем полученные бизнес операции по функциональным признакам в сервисы, реализуем их. Отдельно реализуем бизнес правила потока исполнения работ (т.е. самого бизнес процесса). Компонуем все это вместе и получаем в результате замечательную, структурированную и эффективную работающую систему.
На нашу беду, в этот момент в организации сменяется финансовый директор, а вместе с ним меняются принципы финансового планирования и соответствующие изменения надо внести в нашу систему управления оплатой счетов. Вот тут-то и наступает момент истины. По идее, благодаря процессному подходу и сервис ориентированной архитектуре, мы легким движением руки изменяем настройки соответствующих бизнес процессов и, вуаля, наша система работает по новому. Реально оказывается, что изменение логики бизнес процесса тянет за собой «небольшие» изменения в бизнес операциях, которые «наши программисты сделают максимум за неделю». Но какого дьявола? Мы приложили столько усилий для того, чтобы отделить реализацию наших сервисов от реализации бизнес правил потока исполнения, и первое же изменение в процессе тянет за собой изменения в сервисах. Где же адаптивность? Ситуация крайне неприятная, и к сожалению, довольно типичная. Если вы в нее не попадали, то это означает одно из двух: либо вы никогда не создавали подобных систем, либо вам удается виртуозно управлять ожиданиями заказчика (customer’s expectations).
Пытаясь проанализировать причины неудач, я поначалу искал их в архитектурных просчетах, потом - в несовершенстве используемых платформ и технологий, полагая, что они не могут обеспечить должный уровень адаптивности. Сейчас я склоняюсь к тому, что причина лежит в несовершенстве методологии анализа, а уж затем в изъянах проектирования и в последнюю очередь в несовершенстве технологий.
Начиная анализ с модели бизнес процессов, выделяя бизнес операции и сервисы из этой модели, мы на самом раннем этапе закладываем обратную корреляцию между полученной в результате моделью сервисов и моделью бизнес процессов. А ведь именно на разделении этих двух моделей, на достижении их независимости их друг от друга, базируется высочайшая адаптивность сервис ориентированных систем. Получается, мы сами закладываем эту зависимость на самых ранних этапах анализа и проектирования, попросту не замечая этого. Иными словами мы проектируем сервисы заточенными под конкретные процессы. Ничего удивительного в этом нет. Полученные в результате анализа модели сервисов и бизнес процессов отвечают всем формальным критериям полноты, непротиворечивости, однозначности, etc. Лишь потом мы обнаруживаем, что любое сколь ни будь значительное изменение бизнес процессов, требует внесения изменений в сервисы, чего по идее быть не должно.
Как, же избежать этой порочной зависимости? Я не имею пока четкого ответа на этот вопрос. Возможно, начинать анализ все же надо традиционным способом, с предметных областей, а модель процессов формировать на самом последнем этапе анализа после модели сервисов? Говорят, именно такой подход использует новая методология Motion от Microsoft. Но это тема для совсем другого разговора.