«Золотой ключик» системной интеграции

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

Повторное использование кода: «не изобретать велосипед»
И действительно — зачем в 1001 раз писать собственный бухгалтерский модуль, если на рынке, кроме 1С, ещё полно самых разнообразных бухгалтерских программ. Или модуль для отдела кадров. Или управление складом…
Тезис о «неизобретении велосипеда» — основной конёк интеграторов. Мол, на каждую требуемую функциональность подберём для вас самый подходящий модуль от лучших производителей. Но тут кроется подвох.
На рынке действительно полно типовых программных решений, как в отдельных специализированных системах, так и  интегрированых в ERP-системы. Но! Спектр этих типовых решений как правило ограничен наиболее общеупотребимой функциональностью — то есть тем, что требуется практически каждой компании. Полно бухгалтерских, кадровых, CRM-систем, складских. Но найти что-нибудь подходящее за рамками этого «джентельменского» набора — очень проблематично. Попробуйте найти на рынке модуль планирования и оперативного управления сменно-суточного задания экспериментального цеха опытного производства, особенно под специфику применяемых технологий. Вы окажетесь глубоко разочарованы! Итак, главная проблема «неизобретательства велосипеда» в том, что все «велосипеды» типовые.
Применив типовое решение, вы отказываетесь от собственных конкурентных преимуществ во всех технологиях, и главное — в технологии управления. Вы покорно пристраиваетесь в хвост очереди на бизнес-успех. Зато у вас «типовой велосипед», сертифицированный по РСТ, ISO и т.д. И бизнес придётся вести по-типовому, в соответствии со стандартами управления, навязанными вам «лучшими поставщиками ПО».  Конечно, почти все производители типовых программных решений, особенно «лучшие производители», предлагающие типовые решения, интегрированные в ERP, заявляют об «открытости» решений, о возможности их функционального развития и модификации. Но по большому счёту это лукавство.

Реляционная модель VS предикативная — эффективность VS гибкость
Первая и главная трудность, с которой сталкивается тот наивный, кто поверил в «открытость» типовых решений «от лучших производителей» — это отказ от реляционной модели данных в пользу предикативной. Термин «предикативная модель» не общеупотребимый, я его использую на свой страх и риск, просто в силу моего математического образования :) . Мне довелось «покопаться в потрошках» нескольких систем, использующих предикативную модель вместо реляционной. Это наша 1С и не наши Axapta и OEBS (бывший Oracle Applications). Безусловно, предикативная модель обеспечивает гораздо большую гибкость. Можно, чуть ли не выходя из приложения, добавлять(удалять) поля данных.
Вот только зачем? Поспешность нужна при ловле блох, а вовсе не при проведении бизнес-реинжиниринга.
Декларируется, что такая гибкость обеспечивает снижение трудозатрат при внесении изменений в функциональность. А вот это уже не лукавство, а наглая ложь. Ну то есть, конечно, если понадобилось добавить поле данных, которое на самом деле на функциональность вообще никак не влияет (дополнительное поле комментария, например), то таки да. А ну как это самое дополнительное поле должно ещё как-то осмысленно обрабатываться и действительно менять поведение пользовательского интерфейса или серверных процедур? Тогда беда! Написать, а тем более отладить фрагмент кода, который шарится по таблицам предикативной модели, на порядок сложнее, чем, например, навесить триггер на нормальную реляционную таблицу. Не скажу про 1С, всё же наши писали, вменяемые российские программисты, а вот в Axapte и Oebs есть потаённые подвалы кода, в которые, как в тайную комнату Синей Бороды, вход если не запрещён, то сильно не рекомедуется. Я не шучу, а дословно цитирую из Programmers Guide по Axapte и Oebs.  То есть возможность модифицировать функциональность есть, но ответственность за работоспособность модификаций «лучшие поставщики» не берут на себя ни в каком объёме — даже правила внесения изменений, которые бы всё же гарантировали работоспособность, не публикуют. В Axapte, да и в Oebs, есть так называемые «слои функциональности». Так вот, предыдущие по отношению к последним релизам, особенно самые старые, первоначальные, давно не поддерживаются, и не осталось людей, которые знают, как и почему именно так они написаны. И функциональность новых версий привносят, не внося изменения в предыдущие «слои», а навешивая всё новые и новые слои заплаток. Что, конечно, отнюдь не повышает эффективность. Кстати, об эффективности. Самый простенький запрос на предикативной модели исполняется не в разы, а на порядки медленней, чем на реляционной. Так что незачем удивляться, что в ПО «от лучших поставщиков» какой-нибудь аналитический отчёт строится часами, даже на сверхмощных серверах.

Модульность — преимущество или недостаток?
В данном случае под модульностью я понимаю функциональную, а не программную модульность. И эффективность модульного программирования, как приёма построения архитектуры, под сомнение не ставлю. Итак, ниже речь идёт только о функциональной модульности.
Почему-то «лучшие поставщики» считают модульность безусловным преимуществом. Наверное, для эффективной лицензионной (ценовой) политики это так и есть — вы платите только за те модули, которые приобрели и используете.
Правда, по факту оказывается, что модули всё же не такие уж независимые, и некоторые вы всё равно вынуждены приобретать «в нагрузку» к тем, которые без них работать не смогут. Так что переговоры о комплектации приобретения решения, например от Axaptы, могут превратиться в увлекательнейший триллер :) .
Но вот преимущества функциональной модульности с точки зрения архитектуры программных решений лично у меня вызывают очень большие сомнения. Представьте себе некую учётную систему, построенную по принципам функциональной модульности. Например, построенную по принципам, изложенным  в статье «Аспекты учета в транспортной логистике«.
Лично я не могу себе представить адекватное функционирование любого из перечисленных модулей общего назначения не в связи с модулями управления транспорта и модулем управления грузами. Или в 1С. Могу себе представить некую настройку, в которой функции бухгалтерии не замыкаются на другие функциональные модули, и остаётся возможность вести проводки не в связи с движением учётных данных в других функциональных модулях. Это дыра. То есть всегда есть возможность сделать проводки по первичке, не учтённой в других модулях. Казалась бы, а что тут страшного?
Ничего. За исключением того, что «интеграция» оказалась дырявой. И денежкам всегда будет куда утекать мимо управленческого учёта бизнеса.
Ну и ещё раз об эффективности реализации. При построении архитектуры программных решений по принципам модульной функциональности, каждый модуль должен сохранять адекватную функциональность как для полностью автономной работы, так и для полной или частичной интегрированности с другими модулями системы. А это дополнительные проблемы как эффективности, так и надёжности реализации. Конечно, это проблемы «лучших поставщиков». Но судя по тому, как они с этим справляются, расплачиваться в конечном счёте приходится конечным пользователям. Извините за каламбур :) .

Проблемы обмена данными между разнородными приложениями
Как я уже констатировал выше, далеко не всегда удаётся найти приемлемое интегрированное решение «от лучших поставщиков». Более того, как правило, ключевые бизнес-функции, содержащие главные конкурентные преимущества, в типовых решениях или вовсе не находят отражения, или средствами используемой ERP-системы реализуются в рамках тех ограничений (порой очень жёстких), которые этими средствами накладываются. Вспомните о «подвалах Синей Бороды«, прежде чем на такое решитесь. Выход есть. Всегда. Даже если вас проглотил лев :) .
И этот выход — интеграция разнородных приложений. Я сам этим пользовался, как говорится: «плавали, знаем».
В частности, мне приходилось пристёгивать к моим приложениям управления транспортной логистикой и 1С бухгалтерию, и специализированные программы расчёта таможенных платежей (ТАКСА). Сталкивался с проблемами, решал их. Чем и хочу поделиться.
В зависимости от наличия возможностей внешнего взаимодействия тех или иных сторонних (по отношению к собственному проекту) программных систем, проблемы решаются по-разному. Наличие хорошо документированного программного интерфейса (API) позволяет программно вызывать стороннее приложение (точнее, его программное ядро, без пользовательского интерфейса) и передавать в него учётные данные, или наоборот, получать данные от него. Но наличие API, тем более хорошо документированного, к сожалению, очень большая редкость. Другой вариант — совместная работа с СУБД. Здесь камнем преткновения может стать предикативная модель данных, используемая сторонней системой. Не то, чтоб организовать доступ к ней было совсем невозможно. Но, во-первых, очень сложно, а, во-вторых, нет уверенности, что не зацепим что-то недокументированное, не окажемся в «запретной комнате Синей Бороды«.
Можно организовать обмен на уровне экспорта-импорта файлов. Как правило, такая возможность есть во всех системах. Но данные, оказавшиеся вне транзакционного поля — постоянная угроза разрушения целостности. Поясню. После того, как одна система экспортировала данные, она ничего не знает об их судьбе. Может, их просто потеряет нерадивый сисадмин, может быть, их по каким-либо причинам не сможет полностью или частично обработать система-адресат. То есть до получения ответа-квитанции об успехе/неуспехе обработки экспортированных данных, их вообще трогать нельзя, даже если вдруг выяснится, что они содержат ошибку или утратили актуальность (устарели). Это вам не репликационный сервер — всю такую «удалённую транзакцию» придётся поддерживать чуть ли не ручками, и не дай Бог, если ручки окажутся кривенькими — костей не собрать!

Сервис-ориентированная архитектура — полёт за облака
Лет 10 назад понятие SOA стало притчей во языцех — очередная «серебряная пуля» для решения всех проблем системной интеграции. Но что-то как и после каждой «серебряной пули» восторги поутихли. И причин тут несколько.
Первое, это то, что мотивы возникновения SOA не столько технические, сколько коммерческие. Удобно потреблять услуги некоего внешнего сервера в объёме, качеству и по цене согласованном в контракте и SLA (Service Level Agreement — соглашение об уровне сервиса). И многие «облачные» сервисы действительно могут эффективно использоваться приложениями. Например, сервис прогноза погоды может успешно использоваться системой управления ЖКХ на предмет управления отоплением или системой противодействия паводкам и лесным пожарам МЧС. Можно было бы создать сервисы по техническим расчётам для САПР, например расчёт прочности несущих конструкций. Но тут возникает сложность следующей природы. Для эффективного расчёта надо передавать на сервер огромные  массивы данных. А если хотите сэкономить на пересылке при корректировке данных — организовать их хранение на сервере. Кроме чисто технических аспектов нагрузки на линии связи и базу данных сервера, возникает проблема согласования протокола. Сервер должен принимать данные в строго оговоренном формате, а забота на переформатирование данных ложится на пользователя. Существуют вполне успешные попытки предоставления сервиса по хранению и обработке учётных данных для управления бизнесом. Но в свете откровений Сноудена, мне кажется, этот успех не будет шириться.
Итак, «облачные» сервисы это, конечно, хорошо, хотя и не беспроблемно. Хорошо, в первую очередь тем, что сервисы могут конкурировать, и у потребителя возникнет возможность выбора.
Но зачем создавать «облачные» сервисы для самого себя??? То есть если вы создаёте систему, зачем вам создавать и поддерживать собственные сервисы, если потреблять их будет только ваша же система? То есть зачем использовать SOA, если все сервисы не сторонние, а собственные? Кто бы объяснил? То есть я, конечно, читал и слышал много всяких объяснений, но ни одного вразумительного так и не попалось. Ведь SOA- это доведенный до абсурда, до абсолюта всех недостатков подход к функциональной модульности. Посудите сами — гораздо проще, а главное надёжней, организовать взаимодействие функциональных модулей по базе данных, реализовав общие триггеры, хранимые процедуры, пакеты хранимых процедур как в Oracle, наконец, чем искусственно преодолевать нагороженные барьеры инкапсуляции, обмениваясь немыслимыми объемами данных, которые и так лежат себе в БД и всегда доступны. Где уж тут «бесшовность» интеграции! А уж во что обойдётся бизнес-реинжиниринг — просто страшно подумать! Одно дело подкрутить хранимую процедуру и совсем уж другое — по-новой отлаживать протокол обмена сервисов. И BPEL тут не подмога: буквально, чтоб два байта переслать, на бипеле приходится ваять навороченную XML-структуру. А уж о том, чтоб на нём сервисы учётной системы реально обменивались данными — и речи быть не может!
Конечно, SOA имеет свои ниши. О некоторых, в связи с сервисом прогноза погоды, я уже упоминал. Можно ещё упомянуть о мультиагентных технология для организации B2B взимодействий. Но не использовать же её для корпоративной учётной системы, в самом деле!

Резюме:САПР для «велосипедов»
Итак, снова вопрос — стоит ли «изобретать велосипед»? Стоит, если вы хотите быть первым в гонке!
Собственно, на чём строится апология «неизобретательства велосипедов»? В первую очередь это чисто маркетинговый ход «лучших поставщиков»- типа, даже не думайте, что с нами можно конкурировать!
Второе — это неудачная примерка западных реалий на отечественную почву. На западе программист (особенно русский) — это очень высокооплачиваемый сотрудник. И продукты его труда стоят очень дорого. А какой-нибудь «аналитик HR-модуля» — низкооплачиваемый технический сотрудник. При таких реалиях конечно дешевле внедрить что-нибудь «от лучших поставщиков», чем создавать собственное оригинальное решение. У нас же всё ровно наоборот. «Аналитк ХХ-модуля» получает в разы больше, чем вполне приличный программист. А если учесть затраты на приобретения лицензий на ПО «от лучших поставщиков», то окажется, что за такие деньги всю внедряемую функциональность можно реализовать с нуля под индивидуальный заказ, безо всяких системных интеграторов.
Ну и третье — это сроки разработки и надёжность эксплуатации и сопровождения. Да, увы, это реальные проблемы. Но их можно и нужно решать, а не отказываться от нового в пользу устаревшего типового. Устаревшего не в том смысле, что на наш рынок попадает только старьё-берьё, а в том, что развитие бизнеса требует постоянного обновления решений, и заказанное системным интегратором решение «под ключ» устаревает ещё до внедрения в опытную эксплуатацию. Кстати, упомянутая мной проблема сроков-надёжности- сопровождения в равной мере относится и к решениям от «лучших поставщиков». Только для них всегда наготове отмазка:»А что вы хотите? Мы же лучшие, лучше вам уж никто не предложит!».
Итак, как же быть? А очень просто! Ничто не ново под Луной! Когда-то люди добывали огонь трением и кодили в машинных кодах :) . В уме проектировали таблицы распределения памяти, таблицы переходов по циклам и обращения к подпрограммам. Потом появился Фортран, который все эти распределения вычислял сам. Когда-то и таблицы баз данных люди прописывали на DDL-SQL, пока не появился ER-WIN и S-Designer (ныне PowerDesigner), которые по нажатию волшебной кнопки Generate порождали все DDL-скрипты со всеми Create Table, Create Index и т.д. А потом и вовсе попёрло, как из рога изобилия: Delphi, C-Builder, PowerBuilder — то есть RAD-технологии встали на крыло.
Суть в том, что самые рутинные операции, требующие наибольших трудозатрат в смысле плющенья клавиш, автоматизируются проще всего. Просто понятие «исходный код» обретает всё более высокий уровень. И, если сначала это был действительно просто машинный код (нули и единички), потом тексты на языках высокого уровня, а там глядишь к понятию «исходники» будет относиться только набор диаграмм, полностью и однозначно описывающих структуру и функциональность учётного приложения.
Особое, самое почётное место среди RAD-систем занимал Oracle-Designer под Oracle-7. Он объединял возможности и ER-диаграммера, и Forms, и Reports. Поколдовав над диаграммами в разных нотациях, можно было получить готовый полнофункциональный рабочий прототип, просто нажав волшебную кнопку Generate. Непонятно только, почему в 8-ом и более поздних Ораклах от всего этого отказались? Может, не хотели конкуренции для своего Oebs (тогда ещё Oracle Applications)?
Но прогресс не остановить такими гнусными инсинуациями! :) Даёшь RAD-ERP! :)
И, в заключение, о названии этой статьи. Недаром в него вошло название культового произведения А.Толстого, также именуемого «Приключения Буратино». Просто уж больно системные интеграторы вкупе с «лучшими поставщиками» зачастую похожи на бессмертных персонажей этого бессмертного произведения — Лису Алису и Кота Базилио. Ну а заказчики системной интеграции «под ключ» — соответственного самого Буратино, закапывающего свои золотые на Поле Чудес в Стране Дураков :) .

2 комментариев на “«Золотой ключик» системной интеграции”

  1. Маймурия

    еще и дерутся за Буратин!

    Дата: Декабрь 13th, 2014 | 18:49
  2. Александр Широков

    Ну да. На всех котов Базилио и лис Алис Буратин может и не хватить!

    Дата: Декабрь 14th, 2014 | 17:59

Оставить комментарий