Эволюция роста системы с точки зрения взаимодействия ее подсистем

Попробуем описать возможную эволюцию роста некоей гипотетической ИС.

Этап 1
Допустим, когда-то была создана система S (см рис.). Эта система состоит из 3-х независимых между собой подсистем (Ss - Subsystem).

Этап 2
На очередном этапе развития системы возникла потребность взаимодействия между Ss1 и Ss2, Ss1 и Ss3.
Разработчик пишет интерфейсы для каждой связи Ss-i <-> Ss-j. Обозначим стрелками направления взаимодействия между подсистемами. Интерфейсы представляют из себя описания вызовов процедур, исполняемых на данной подсистеме. Стрелки - это передача параметров вызова и возвращаемый результат.

Этап 3
Далее, разработчик видит, что интерфейсы к Ss1 содержат пересекающееся множество описаний функций, и он решает объединить их в один интерфейс.

Этап 4
Предположим, что система усложнилась до такой степени, что стало слишком накладно каждый раз писать индивидуальные интерфейсы для новой подсистемы (вернее, ее части, которая обращается к остальным Ss).
Возникает идея создания промежуточного программного слоя-шины, который инкапсулировал бы в себе эту задачу. Назовем его "Middleware" (связующее ПО).

Этап 5
На сегодняшний день уже разработано несколько стандартов такого промежуточного ПО, среди них описываемые ниже OMG CORBA и Microsoft DCOM/COM+. Поэтому в какой-то момент рациональнее будет не изобретать велосипед, а использовать эти стандарты для построения их собственной реализации либо продукты стороних призводителей ПО. Это прямой путь к технической интероперабильности подсистем.
Еще можно добавить стандарт открытых систем и мы получим сегодняшнюю мечту многих разработчиков крупных ИС уровня корпорации.

Этап 6
Заглянем на секунду в будущее. Мы там видим, как подсистемы представляют из себя автономные объекты, которые живут своей жизнью и общаются друг с другом на уровне смысловых понятий их предметной области.
Это уже уровень семантической интероперабильности компонентов. По сложности стоящих перед исследователями задач он приближается к проблемам исскуственного интелекта.

Весьма интресным был бы количественный анализ необходимости перехода от одной версии взаимодействия к другой. Описанные выше критерии затрат на миграцию унаследованной системы частично дают ответ на вопрос, что же нужно учитывать при оценке. При попытке использования какого-либо стандарта на любом этапе появляется потребность сравнительного анализа выбора между разработкой собственного, использования уже разработанного какой-либо авторитетной организацией(-ми), либо программных продуктов сторонних производителей (которые, в свою очередь, тоже могут как использовать, так и не применять общепризнанные стандарты). В реалиях невообразимого разнообразия аппаратного и программного обеспечения становится весьма разумным использовать 2-й подход - использования общепризнанных стандартов. Одним из наиболее известных в этой области является стандарт взаимодействия открытых систем. Но что такое "открытая система"?