|
...починяю примусПромежуточные XML-преобразования отпадают очевидным образом: преобразовывать гигабайты данных в XML для временного хранения - сомнительное (и дорогостоящее по ресурсам) удовольствие По поводу неэкономности XML. В XML было принято радикальное проектное решение: не экономить байты. Некоторым по-видимому трудно принять такой подход, но он сегодня доминирует. И не потому что его пропагандируют; нет тут никакого заговора. А потому что он себя оправдывает. Простой пример: сравните EDI с XML. Первый намного (вероятно, на порядок) экономнее в длине сообщений (и как, следствие, в полосе пропускания), но этот выигрыш многократно перекрывается гибкостью XML.
Поэтому пусть даже будут преобразовываться гигабайты. Ведь это не длина одного сообщения, а скорее годовой объем передаваемой информации. Если так, то я никакой проблемы с производительностью не вижу. Пусть железка молотит, главное -- разгрузить мозги, а не интеловский процессор. У меня на линуксовом сервере уровня ниже среднего xsltproc непрерывно молотит xml, и его производительность ни разу узким местом не стала. Узкое место -- это sql-запросы с соединением таблиц числом более десяти.
...починяю примусДа и зачем в статичную, в функциональном контексте, задачу привязывать BPM ? Динамика там в другом разрезе идет - в приведении различных по структуре данных к общим структурам для последующей обработки (тарификации, анализа нагрузки "по направлениям", загрузки оборудования и т.п.); Если я правильно понял, Вы предлагаете промежуточное хранилище, я же считаю что достаточно промежуточного формата, а хранит данные пусть каждая система у себя. Проблема взаимодействия каждого с каждым решается и у Вас, и у меня.
...починяю примусУвольте меня от "инструментов для широких масс" - сыт по горло... На мое сугубое HO, "широкий" инструмент - инструмент, оказывающийся, в конечном итоге, никому не нужным. BPMS, опять-же сугубо личное мнение, тем и ценен, что никаким не "широким массам" адресован, а вполне конкретным специалистам - бизнес-аналитикам. Так именно их я и понимал под "широкими массами"!
...починяю примусНа рассматриваемом в данном случае уровне абстракции бизнес-анализу делать, пока-что, нечего. Я согласен, ради этого "городить огород" с BPMS смысла нет. Но я исхожу из того, что BPMS -- это просто полезная вещь . Ну типа как DBMS. Ведь если у вас есть СУБД, вы зачастую создаете БД там, где в принципе можно было бы обойтись чем-то попроще. Но зачем обходиться, если есть правильный инструмент? Я, поработав некоторое время с разными BPMS, теперь отношусь к ним именно так. Временно оставаясь в меньшинстве :)
Немного отвлекусь от основной темы: еще о "широких массах".
В отечественной авиации есть такая легенда. Туполев в свое время выплачивал премии за экономию веса конструкции самолета. Платил любому: конструктору, мастеру, простому клепальщику. Причем премии выплачивались очень солидные. Окупалось сторицей, ведь сэкономленный килограмм веса пассажирского лайнера за время его эксплуатации -- это, грубо говоря, килограмм золота.
Так вот, меня давно уже терзает вопрос: как в процессном управлении дать реализоваться российской ментальности? Возможный ответ: в разработке схемы бизнес-процесса полагаться не только на продвинутого руководителя или владельца, не только на грамотных консультантов, но и на "солдатскую смекалку" людей, которые тянут эту лямку. Управленец без навыков программирования, но с мозгами, вполне способен освоить рисовалку бизнес-процессов.
Русская смекалка никуда не делась, только увы, слишком часто она направлена только на поиски того что плохо лежит. Ее только направить в правильное русло -- и никакие японцы со своим перманенетным самосовершенствованием нас просто не догонят! Уже даже есть потенциальный клиент, на котором собираюсь эту идею опробовать...
|
