Ситуация 2. Вертикальная интеграция

На следующей схеме изображен подход, называемый «вертикальной интеграцией». В соответствии с этим подходом системы интегрируются по принципу функциональных экспертиз [2]. Например, в данном случае выделены две экспертизы: оперативный учет и бухгалтерской учет. При этом бухгалтерский учет находится по вертикали выше оперативного учета. В нашем примере подсистемы оперативного учета поставляют данные подсистеме бухгалтерского учета. Это позволяет существенно сократить трудозатраты на дублирующиеся и бумажные операции, однако, есть два отягчающих момента.

Во-первых, такую систему крайне трудно расширять функционально. Например, компания может захотеть создать подсистему-экспертизу «Аналитика», которая по вертикали будет расположена над экспертизой «Бухгалтерский учет». Эта экспертиза в значительной степени основана на данных «Оперативного учета». Поэтому, помимо собственно разработки подсистемы «Аналитика» придется дорабатывать подсистему «Бухгалтерский учет» для того, чтобы она получала и хранила для нее из «Оперативного учета» дополнительную информацию.

Во-вторых, остаются значительные возможности по интеграции в рамках одной функциональной экспертизы.

Ситуация 3. Интеграция «многие ко многим» (звезда, спагетти)

Интеграция «многие ко многим» не предполагает выделение слоев функциональных экспертиз. При этом подходе каждая из используемых в компании подсистем может при необходимости обращаться к функционалу любой другой подсистемы. С другой стороны каждая из подсистем может использоваться любой другой подсистемой. Такой тип отношений между элементами называется «многие ко многим». Также если подсистем немного, то схема отражающая связи между ними похожа на «звезду». А если систем много, то бесконечные их переплетения образуют «спагетти» [2].

В этом случаем имеем место с практически неограниченными возможностями интеграции подсистем между собой (естественно, если подсистемы технологически позволяют делать это, об этом ниже).

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