Как-то встретил я умную мысль, что для успешного использования инструмента программирования надо понимать что он делает на один уровень ниже, чем работаешь. Скажем - программируя на C - понимать во что это выльется на ассемблере, рисуя формы в Delphi - какой код на Pascal стоит за ними, приограммируя на ассемблере - что это будет в машинных кодах. И тогда создаваемая система сама получится быстрой и нетребовательной к аппаратуре. Так сказать - строя очередного колосса - подумать из чего у него ноги.
Теперь попробуем применить этот подход к теме, об которую в последние пару дней посетители сайта изломали копий столько, что хватит на небольшой пионерский костер - к SOA. Ладно, пускай все вердоры вдруг завтра сели - и меж собой договорились, что с послезавтра у них все бизнес-объекты стандартные и друг-другом понимаются. Ну вот приключилось с ними такое, вследствие роста солнечной активности и прохождения над Калифорнией озоновой дыры. И написали, для простоты всего три разных вендора, три системы - один HR, другой CRM и третий - управление складом (тоже наверно мудреная аббревиатура есть, забыл). А четвертый к ним интеграционную платформу присобачил, чтобы они могли друг-друга как им заблагорассудится вызывать. Само собой - все три решения - лучшие в своём классе - и как раз ложатся в реинжиниринг нашего бизнеса, чтобы кучу новых возможностей создать. Не, ну должно же быть в жизни место для идиллии?
В общем - покупаем мы все эти три и интеграционную платформу к ним до кучи. В HR ведем сотрудников наших, в CRM - клиентов и заказы, в складской - само собой склад - ну и фактуры по этим заказам выводим. Не жизнь - малина. Не понравился блок CRM - щас его и заменили, остальным его внутреннее устройство неважно, все бизнес объекты из новой CRM торчат идентичные, в смысле стандартные.
А что же там должно быть внизу?
Вот, скажем, ввел кто-то клиента неверно - и хотим мы его удалить. Не вопрос, идем в CRM, находим клиента, жмем Delete. И насторожились читавшие когда-то литературу по БД ИТ-шники ... И правильно насторожились, потому что не знает наша CRM - а есть ли в сладской системе уже введенные на этого клиента операции. В БД это называется FOREIGN KEY и делается на нем REFERENCE INTEGRITY, нарушение которой к добру, как известно, еще никого не приводило. А значит - наша распределенная, на Web-сервисах, система должна поддерживать распределенную ссылочную целостность ... Уже веселее? А если у нас клиент не только в складской системе используется, но и в бухгалтерской и еще там пятке каких-то, о которых CRM знать не знает? Надо, стало быть каждую новую систему как-то регистрировать, чтобы CRM не позабыла не только по её запросу данные выдавать, а и при попытке этих данных модификации - у всех у них поинтересоваться - не возражают ли?
Ладно, положим поддерживает, логика такова, что вместе с таким клиентам надо его операции почистить ... А если они почему-то не могут быть удалены - так и клиента удалять не стоит. И опять насторожились БД-шники, ибо это уже называется транзакция. А у нас она получается распределенная и по произвольному количеству произвольных систем учета. Асинхронно бы это сделать - да ACID, ити его не одобряет, значит хорошо бы синхронно. Хорошо бы также, чтобы все перечисленные системы обладали при этом одинаковыми взглядами на уровни изоляции и версионность бизнес-объектов. Желающие осознать задачу могут попробовать замутить распределенную транзакцию между Oracle, MSSQL, DB2 и Interbase одновременно. То-то будет весело ...
Ну да Бог с ним с удалением, рисуем мы просто фактуру в складской системе. Опа, реквизиты клиента надо и номер договора. А они в CRM. Не вопрос, для этих полей вызываем веб-сервис "дай реквизиты клиента". Дал, нарисовали. Но тут приходит отдел маркетинга и говорит, что в плане повышения социальной ответственности продажников надо на фактуре написать фамилию и телефон менеджера этого клиента (а они в HR, а привязка одного к другому - в CRM), а еще - хорошо бы телефон его начальника отдела (он тоже в HR есть и привязка в HR). Хочется, очень хочется предположить, что в CRM таки есть веб-сервис "дай привязку клиента к другой системе", да еще и можно указать к какой, да еще и при смене HR-системы - он эту привязку сумеет снова понять, что надо её в новую HR переадресовать. В общем - рисование фактур становится процессом уже творческим, требующим знания распределенной архитектуры системы. Кстати - асинхронно - опять-таки нехорошо это делать - всё-таки процесс вывода фактур требует интерактивности и в асинхронную очередь его так просто не поставишь.
Теперь вернемся чуток к реалиям.
Разумеется, на нынешнем уровне развития науки и техники все перечисленные задачи по-отдельности более чем решаемы. Но! Кто видел реальную ERP - тот знает, что она как правило работает на пределе возможностей дорогущего железа и быстродействием транзакций при этом не блещет. Сильно не блещет. Имея все перечисленные проблемы в одной БД. Каким чудом оно начнет работать в распределенном режиме поверх небыстрых веб-сервисов - для меня более чем тайна. Поскольку чудес в области железа пока не предвидится, то закон Мура догонит подобные запросы ох нескоро ... Готовьте ваши денежки ... Что там говорили следующее? Виртуализация? Да, да, своевременно ;-) Начальству бюджет понравится ...
Опять же - о стабильности работы. Ладно, положим все инфраструктурные компоненты, количество которых удесятеряется будут работать безупречно. Но замена или модернизация одного "лучшего в своём классе" компонента, как мы успели заметить пролезет во все возможные и невозможные, а потому неожиданные места. HR модуль обновили - фактуры отвалились. То-то будет радости. Внутри одной ERP подобное еще как-то отслеживается при модернизациях (хотя и из рук вон плохо), что будет при независимых компонентах?
Ну и напоследок - заведомо неизвестная вендорам конфигурация системы - заведомо гарантирует, что отчетный модуль мы будем делать сами и уникальный под каждое предприятие. Не то, чтобы это обязательно плохо - индивидуальная отчетность - это здорово, но это означает, что отчетный блок - ляжет на CIO. Причем - отчеты, которые OLAP - сделаются несложно, а вот те, которые должны в online делаться - делать непонятно как. Писать на каждый программу, вызывающую кучу веб-сервисов? Кстати. как там в стандартах со стандартами запроса коллекций объектов? Или хотя-бы с запросом объекта по условию? Вот надо мне в отчет всех сотрудников с фамилиями на "М". Будет в любой произвольной HR системе веб-сервис, позволяющий одинаковым образом подобное запросить? Ну, о быстродействии отчетов, которые online выполняются в подобной среде уж умолчу ...
Еще один, кстати, "напоследок" - наверно специалистов по конфигурированию "лучших" решений тоже понадобится немало? Внутри-то они все разные, свои языки настройки, свои параметры - значит свои курсы для ИТ-шников, свои "узкие" специалисты. Причем - поскольку всё интегрировано - то передача каждого решения своему поставщику на поддержку кажется плохой идеей. Поменяют одни чего в CRM - печать фактур в складе отвалится - кто будет разбираться? Сколько это времени займет? Кого и как в это время будет любить начальство?
Выводы
Даже на уровне технической реализации - на настоящем этапе попытка "жить по SOA" вызывает кучу нерешенных, а то и вообще нерешаемых на сегодня проблем. Очевидно падение быстродействия, рост требований к железу, все проблемы с зоопарком программ (обслуживание, специалисты), распределенное программирование отчетов (и вообще снижение возможностей по отчетности). Сложность взаимосвязей неизбежно повлечет труднонаходимые глюки на стыке систем и непредсказуемые сбои. Общие стандарты - либо повлекут использование "лучших" систем в режиме наименьшего общего знаменателя (кто писал "независимые" от движка БД приложения - тот поймет) либо - невозможгность их независимой модификации. В общем - пока невеселый рай получается.
P.S. Всё сказанное отнюдь не означает, что аффтар - злобный враг SOA. Подходы нормальные, мысли здравые, во многих случаях они вполне могут работать и сейчас. Автор - злобный враг подачи SOA как панацеи. Ибо это уже - навешивание на уши лапши, а автор этого не любит. Особенно, когда уши его.