В статье предложен радиально-кольцевой метод проектирования архитектуры области (в частности - интеграционной схемы), состоящей из нескольких информационных систем, проведены общая оценка применимости этого варианта в различных ситуациях и его сравнение с классическим «макаронным» представлением. Взгляд сугубо субъективный и прикладной. Если вдруг статья привлечет очень много профессионалов – прошу придерживаться культурных о(б)суждений ????

Как всё началось

Началось все очень просто – в норе под землей с постановки прикладной задачи, а именно: требуется разработать интеграционную схему области, состоящей из 10 информационных систем (ИС), при этом:

1. Необходимо:

• отразить все интеграционные связи каждой из 10 ИС (интеграции возможны как с ИС области, так и с ИС смежных областей (их 8));

• понимать содержание интеграционных потоков.

2. Желательно:

• понимать все вышеперечисленное быстро;

• иметь возможность масштабировать архитектуру.

Примечание: предлагаю не демагогить по поводу понятий «область», «ИС», «архитектура», «интеграция» и прочее, сведем все к базе – есть объекты и связи между ними, по которым течет какая-то данная, которую надо понимать. Вот это все безобразие и надо показать.

Еще немножко истории - и перейдем к сути.

Первое, что пришло мне на ум – пойти стандартным путем: нарисовать квадратиков и начать рисовать между ними стрелочки с подписями. Вроде того, как представлено на рисунке:

Так я и сделал (10 ИС области + 8 ИС смежных областей = 18 действующих лиц), однако очень скоро я уткнулся в проблему топологии – где-то после 25 стрелочек рисовать их стало некомфортно, при этом интеграции требовалось отразить на уровне атрибутов, а не смысловых потоков данных.

Я сел и начал думать на тему универсальности, и, кажется, что-то получилось… Получился радиально-кольцевой метод (далее – РКМ) проектирования архитектуры .

Итак - РКМ

Метод реализует представление архитектуры в радиально-кольцевой структуре, где радиально направлены потоки данных, а кольца (контура) играют роль шины (на схеме залита зеленым).

При этом сами ИС делятся на 2 типа:

• ИС области;

• ИС смежных областей.

База под наши исходные данные такая:

В качестве инструмента отсюда и далее я использовал confluence (draw.io). Как видите, каждой ИС я также присвоил свой цвет. Решение не совсем масштабируемое (цвета так-то не бесконечные, знаете ли) и совершенно не обязательное, но в рамках моей задачи было весьма неплохое. 

Главная особенность данного представления — возможность «убирать» линии связей (потоки данных) в контур интеграций, благодаря чему значительно экономится место и упрощается поиск и понимание связей, относящихся к конкретной ИС. То есть поток может в любом месте войти в контур и из любого места выйти.

В нашем случае схема с нанесенными связями выглядит так (исходные данные абсолютно реальные):

Как видите, на схеме появились стрелочки с надписями, поэтому пришла пора заявить о правилах.

Правила

Первое, что необходимо для любой успешной работы в целом — это задать правила. Поехали.

Правило №1 – «Названия». Каждый поток данных должен иметь уникальное название/номер. При разработке РКМ я формировал названия так «первая буква системы – порядковый номер потока», пример – «В-1». При этом название потока дается по системе-потребителю (в случае, если источник – ИС области) или по системе-источнику (если потребитель – ИС смежной области).

Правило №2 – «Без таблиц – никуда». Каждому поток соответствует описательная таблица. При разработке РКМ применялась таблица вида:

Правило №3 – В рамках связи «система - система» может быть максимум два интеграционных потока, они разнонаправлены. В случае необходимости добавления нового атрибута в интеграцию — просто изменяем соответствующую таблицу соответствующего потока.

На самом деле дальше перечислять не буду, так как правила – результат договоренностей в каждой конкретной ситуации, я просто хотел показать, что они всегда нужны и всегда важны! И да, вы правильно заметили, что правила я привел универсальные, что для РКМ, что для макаронного метода (далее - ММ).

Для сравнения — вот схема, нарисованная ММ со всеми теми же связями, что я приводил на схеме выше для РКМ:

Отмечу, что при отрисовке макаронной схемы я не халтурил, а прямо сел и потратил время для чистоты эксперимента, старался то бишь ???? Сразу прошу меня простить – названия потоков не нанес.

В целом обе схемы выглядят вполне нормально, читаемо, не перегружено.

Эксперимент

Теперь попробуем проверить каждую из них на масштабируемость. Добавим одну новую ИС (ИС-Х, выделена красным), на которую навесим 4 двусторонних связи «система-система» и еще 8 произвольных связей «система-система», которые навесим на старые системы.

Вот так будет выглядеть архитектурная схема, нарисованная по РКМ:

А вот так будет выглядеть схема, нарисованная по ММ:

Как видите, «макаронная» схема стала выглядеть значительно нагруженней, в том время, как схема, нарисованная по РКМ, не сильно изменила своего внешнего вида.

Выводы (напоминаю, субъективные)

Оформлю выводы в виде таблички сравнения двух методов. Что хуже, что лучше в абсолюте — решать вам.

Ищите удобное вам, совершенствуйтесь, и да прибудет с вами kaizen!