Публикация "SOA. СМЭВ. Электронный обмен или обман" 26 марта 2012 г. на интернет ресурсе "ГосБук" вызвала большой интерес у множества экспертов, участников и читателей данного ресурса. Дискуссия приняла конструктивный предметный характер. В ходе дискуссии были сформулированы некоторые ключевые направления для более детального обсуждения, которые выходили за рамки коротких комментариев.
В связи с этим мы решили дать ответы на поставленные вопросы в отдельной статье.
Почему статья называется "ИЛЛЮЗИИ SOA"?
Дело в том, что наши коллеги утверждают: "SOA - это инструмент проектирования информационных систем", но только тех систем которые: просты, слабо связаны, при своем изменении слабо меняют интерфейсы взаимодействия, для которых интеграция информационных систем "не самоцель" ...
В свою очередь, мы утверждаем, что таких информационных систем управления, а особенно для органов государственной власти и бизнес-структур НЕ БЫВАЕТ. Это иллюзии.
Все мировое сообщество утверждает, что информационные системы управления сложны, динамичны, сильно связаны, слабо детерминированы, широко диверсифицированы, территориально распределены. То есть для реализации таких реально необходимых обществу информационных систем SOA использовать не возможно.
SOA тупиковая ветвь развития информационных систем, которая является маркетинговым ходом для изъятия из карманов заказчиков существенных денежных средств.
Мы постарались все вопросы и комментарии к статье "SOA. СМЭВ. Электронный обмен или обман" систематизировать в таблице и предлагаем Вашему вниманию наши ответы.
Вопрос читателя:
SOA - это инструмент проектирования информационных систем
-информационные технологии - инструмент, позволяющий достигнуть определенного уровня эффективности некоторых бизнес- процессов
-планирование - инструмент управления...
Системный подход, проектное управление - тоже инструменты, но не цели и не задачи.
Не каждый инструмент сделан из металла или написан на языке программирования...
Наш ответ:
Инструмент (лат. instrumentum — орудие) — предмет, устройство, механизм или машина, используемые для воздействия на объект: его изменения, изучения.
Несомненно данный инструмент может быть виртуальным.
Однако SOA не является на сегодняшний момент ни реальным универсальным инструментом, ни используемой единой технологией, ни устоявшейся методологией, а только неким, по разному интерпретируемым, подходом. Сравните инструменты, технологии и методологии используемые Microsoft, IBM, SAP, Oracle. Для этого Вам придется сформировать еще одну новую методологию их сравнения и сопоставления. Кроме того, если бы информационные системы были построены на едином ИНСТРУМЕНТЕ SOA, то они бы были бы между собой "бесшовно" совместимы, как комплектующие в компьютере. Но сами разработчики заявляют, что их информационные системы в SOA несовместимы.
Вопрос читателя:
Интеграция информационных систем.
Это способ построения новых информационных систем на основе набора ранее существовавших систем меньшего уровня агрегирования.
SOA позволяет решать задачи интеграции слабосвязанных информационных систем, а также увеличивать коэффициент повторного использования ранее написанного кода.
Наш ответ:
Итак, предположим, что мы начали выделять отдельные часто употребляемые сервисы в целях "увеличения коэффициента повторного использования ранее написанного кода" с меньшим уровнем агрегирования.
Сколько тысяч сервисов мы получим?
Как найти нужный сервис среди тысяч различных семантических названий сервисов?
Как избежать дублирования написания сервисов, если вы не сидите в одной комнате и организационно не работаете над одним проектом?
Кто, сколько времени, каким образом будет анализировать насколько сервис одного программиста эффективнее сервиса другого программиста и соответствуют вашим текущим требованиям?
Информационные системы управления не бывают слабо связанными, каждая функция включает следующие параметры управления: юридическое лицо/физическое лицо, единицы измерения, адресное пространство, стоимостные характеристики, источники финансирования и т.д. и т.п.
Кроме того SOA не в состоянии создать единого информационно-функциональное пространство даже нормативно-справочная информация, что является общим требованием всех информационных систем.
Вопрос читателя:
Если другой подход или архитектура решают эти задачи эффективнее - здорово, но это не означает немедленную утилизацию SOA, как появление бензопилы "Дружба" не привело к утилизации топоров.
Наш ответ:
Сетецентрическая G3 архитектура информационных систем управления действительно решила задачи формирования единого информационно-функционального управленческого пространства.
Утилизация SOA неизбежна, как переход от парадигмы "земля была плоская и лежала на слонах, слоны на китах, киты в море" к парадигме, что земля круглая…
В целях эволюционного (а не "шокового" революционного) перехода в новую сетецентрическую архитектуру предложен интегратор (G3I) с унаследованными системами. (см. описание G3-Интегратор в статьях)
Вопрос читателя:
"Многократное избыточное несопоставимое описание в различных функциональных информационных системах одних и тех же предметов и процессов предметной области" (Статья: "SOA. СМЭВ. Электронный обмен или обман")
SOA как раз позволяет это избежать. Поставщик сервиса описывает предмет и процесс предметной области, а его потребитель сервиса ссылается на него и использует
так, как считает нужным, выстраивая свою часть предметной области или решая свою задачу.
Наш ответ:
То, что потребитель может выбрать любой набор запускаемых сервисов не вызывает удивления с момента появления графического экрана с пиктограммами сервисов.
Речь не об этом. Главное, как за экраном потребителя сервисов реальные функции, бизнес процессы, объекты управления целостно систематизированы и взаимоувязаны?
А никак!
Как можно связать в целостную картину то, что происходит в выбранном наборе "черных ящиков" отдельных информационных сервисов, написанных различными группами программистов.
Что будет, если программисты перешли в другие компании или с ними что-то случилось?
Новая команда предложит заплатить новые деньги и переписать старые сервисы.
Вопрос читателя:
"различное время внесения изменений в идентичные данные в различных системах, принципиальная невозможность запросами и обменными операциями… синхронизировать по времени и данным всё информационное пространство, следовательно обеспечить достоверность обрабатываемой и передаваемой информации, … единое информационное пространство" (Статья: "SOA. СМЭВ. Электронный обмен или обман")
Продолжение п.1. К SOA это не имеет отношения. Это имеет отношение к безграмотному проектированию конкретной системы.
Здесь нужно помнить область применения SOA - слабосвязанные системы- поэтому задержка в цепочке связанных изменений является нормой и изменения клиента и сервера транзакционно не связываются.
Наш ответ:
Грамотное проектирование "лоскутно-сервисной" информационной системы управления не устранит проблемы синхронизации данных в "разорванном" времени и пространстве.
Нонсенс!
Не будем повторять выше изложенные ответы по "слабосвязанным системам", для которых, вы признаете, "задержка в цепочке связанных изменений является нормой".
Вопрос читателя:
"при каждом изменении требований многократное переписывание, тестирование, ввод в опытную и промышленную эксплуатацию как функциональных программных систем, так и принимающих и передающих сервисов" (Статья: "SOA. СМЭВ. Электронный обмен или обман")
SOA как раз и позволяет сделать возможным независимость доработки сервиса и его использования. Правда, при условии сохранения интерфейса.
Если же заказчик сервиса постоянно меняет требования к его интерфейсу - тупой и должен платить, раз не знает чего хочет.
Это вопрос квалификации.
Наш ответ:
Считаем несправедливым называть "ТУПОЙ" всю законодательную власть РФ: Президент, Госдума, Совет Федерации, Региональные думы…, всю исполнительную власть: Премьер-министр, Правительство, Министерства и ведомства и других.
Вы хотите остановить время и развитие?
А как же оптимизация и модернизация управления?
Обращаем Ваше внимание, что только Государственная дума принимает ежегодно около 3000 законов, которые влияют на изменение сущности сервисов, экранных форм (интерфейсов пользователя) и интерфейсов взаимодействия сервисов.
А сколько законов принимают 83 региональных думы?
Современные информационные системы управления должны динамично отвечать текущим требования времени, быть адаптивными (меняться "на лету")!
Заказчик не должен быть заложником или рабом один раз написанных "жестких" сервисов!
Вопрос читателя:
"обеспечение взаимодействия систем между собой становится еще одним "видом деятельности", превышающим по времени и другим ресурсам сопровождение эксплуатации и развития самих систем" (Статья: "SOA. СМЭВ. Электронный обмен или обман")
Это процесс создания новой системы из набора ранее существовавших подсистем и ее эксплуатации.
В противном случае обеспечение взаимодействия не имеет смысла.
Наш ответ:
Считаем, что при использовании SOA "процесс создания новой системы из набора ранее существовавших подсистем" превышает время создания каждой из объединяемых подсистем. Процесс требует дополнительных колоссальных временных, интеллектуальных и финансовых затрат.
Мы с Вами согласны, что отсутствие взаимодействия, подчеркиваем семантического взаимодействия, множества разработанных информационных систем управления не имеет смысла.
Вопрос читателя:
"замедление и ограничение скорости модификации в ответ на увеличивающийся рост динамики изменений реальных объектов и процессов управления, при увеличении количества интегрируемых систем и повышении их сложности" (Статья: "SOA. СМЭВ. Электронный обмен или обман")
Это к разговору об уместности использования конкретного инструмента в конкретном случае:
все ли изменения внутри реального объекта и процесса должны тиражироваться "наружу"?
мы не забываем про требование слабой связанности?
неужели использованы все возможности для обеспечения необходимой производительности сервиса?
Наш ответ:
Опыт реализации более 700 проектов в интересах крупных бизнес-структур и органов государственной власти показал, что в едином информационно-функциональном пространстве проявляется сетевая рефлексия на любое изменение объекта или процесса управления.
То есть реально работает "эффект бабочки".
Поэтому мы должны Вас огорчить, при изменении, казалось бы "внутри реального объекта и процесса", в архитектуре SOA придется изменять как функциональные сервисы, так и сервисы обмена.
Вопрос читателя:
"проблемы обеспечения интероперабельности программных комплексов приводят к существенному падению работоспособности информационных систем в целом; необходимость согласовывать свои действия с коллегами иногда приводит к потерям времени на это согласование. Но без такого согласования невозможна эффективная деятельность компании. Компания как система требует обучения людей взаимодействовать между собой." (Статья: "SOA. СМЭВ. Электронный обмен или обман")
SOA - система нуждается в том, чтобы ее подсистемы умели между собой общаться. И это требует накладных расходов.
Наш ответ:
В сетецентрической G3 архитектуре данных расходов нет.
Вопрос читателя:
"отсутствие и принципиальная невозможность реализации комплексной системы безопасности фрагментарных программных систем и межсистемного интеграционного информационного пространства" (Статья: "SOA. СМЭВ. Электронный обмен или обман")
Хотелось бы подробнее, какие аспекты ИБ принципиально нереализуемы в SOA?
Наш ответ:
Создание комплексной системы безопасности в SOA не достижимо!
SOA предполагает создание набора множества сервисов, то есть программных продуктов, которые в соответствии с российским и международным законодательством должны быть сертифицированы на требуемый уровень безопасности.
Давайте, например, приведем ориентировочные стоимость и сроки сертификации 100 сервисов в динамически меняющейся (1 изменение в месяц) информационной системе управления.
Данная задача не имеет решения.
Вопрос читателя:
Что касается Вашего GGG - подхода - его преимущества перед SOA для меня совсем не очевидны.
Может вы приведете конкретный пример использования каждого подхода - и на нем разберем все достоинства и недостатки обоих методов?
Или GGG - технологии идеальны?
Наш ответ:
Конкретный пример сравнения подходов: традиционного модульного, сервис-ориентированного (SOA) и сетецентрического приведен в статье на ГОСБУКе от "26" марта 2012г.: "Анализ эффективности использования сетецентрической GGG-технологии на примере реализации проекта "G3-Бюджет РФ".
Приглашаем всех ознакомиться с инновационной G3 (GGG) – технологией на сайтах, семинарах, круглых столах, в учебных заведениях.
Надеемся, что наши ответы помогли приблизиться к пониманию проблем SOA и необходимости поиска новых альтернативных решений.
Одним из таких решений является инновационные теория, методология и технологии новой эволюционной ПОСТвинеревской кибернетики, создания глобальных сетецентрических систем управления.
Впервые создан "станок" по программированию — технология автоматического программирования мультиплатформенных, адаптивных программных приложений пользователя на основе единой эволюционной е-модели знаний о предметной области.
top of page
Недавние посты
Platform V Сбера. Анатомия провала. Что делать Автор: Хохлова М.Н. Федеральное казенное учреждение Государственные технологии – ФКУ...
2 07617
Авторы: Кутин В.Н., Хохлова М.Н. О проблемах цифровой трансформации на примере систем управления производством и промышленного...
5780
АБСТРАКТ Авторы: Кутин В.Н., Хохлова М.Н. Мировой тренд XXI века – «Индустрия 4.0» и цифровые платформы. В 2014 году General Electric...
9510
bottom of page
コメント