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

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

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

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

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

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

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

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

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

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

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

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

Пример схемы интеграций между информационными системами для реализации аналитики интернет-магазина (источник: https://biarch.ru/analytic)
Пример схемы интеграций между информационными системами для реализации аналитики интернет-магазина (источник: https://biarch.ru/analytic)

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

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

Итак - РКМ

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

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

  • ИС области;

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

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

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

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

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

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

Правила

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

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

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

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

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

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

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

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

Эксперимент

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

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

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

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

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

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

 

РКМ

ММ

Применимость (субъективно)

Много ИС и у них много связей с окружением

Одна ИС и нужно отразить только ее связи с окружением

Масштабируемость

Бесконечная, за счет наращивания контуров и количества ИС

Ограниченная, в какой-то момент станет невозможно читать

Сложность чтения

Придется научиться читать, создать минимальную систему правил

Легко и привычно читать даже без правил, но правила никогда не помешают ;)

Скорость добавление новых интеграций

Одинаковая (небольшая) при любом количестве ИС

Возрастает с увеличением количества ИС и связей

Устойчивость к изменениям

Максимальная, не зависит от количества ИС и их относительного расположения на схеме

Сложность изменений растет с увеличением количества ИС и связей, относительное расположение важно учитывать

Информативность (количество информации на единицу площади)

Максимальная, вокруг одной ИС сосредоточены все интеграции, в которых она участвует

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

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

Комментарии (7)


  1. kasiopei
    30.09.2022 17:10
    +1

    А теперь добавляем колец(шин) и скрещиваем с макаронами))


  1. saipr
    30.09.2022 17:26

    Сейчас, заканчивая IV-ую часть своих воспоминаний, я просматривал одну из своих книг "Основы построения систем автоматизации проектирования", которая была издана в 1989 году, и вот что мне попалась на глаза:
    image


    Так получается, что я вольно или невольно писал о или применял РКМ — радиально-кольцевой метод проектирования архитектуры. Бывает.


    1. click0
      30.09.2022 23:20
      +1

      Эта книжечка существует в электронном виде? Поделитесь?


      1. saipr
        01.10.2022 12:59

        Не встречал, но теперь сделаю и выложу.


  1. NightShad0w
    30.09.2022 21:52

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


  1. sophist
    01.10.2022 13:13
    +2

    А в чём преимущество замыкания "шин" в кольцо? Почему нельзя было представить типы ИС в виде слоёв, разделённых прямолинейными "шинами"? (В принципе, наверное, это можно сделать даже средствами ММ, если просто соответствующим образом конфигурировать стрелочки).


  1. GLK9000
    03.10.2022 13:40

    Уже нашёл один явный минус такого подхода, но вопрос в том насколько он кому критичен.
    Всё же всегда зависит Для чего и Для кого мы делаем ту или иную диаграмму.
    Если говорить о ММ, то там на стрелочках можно указать и сущности, и цифрой отразить "этап"/"шаг" процесса. То есть заложить порядок вызовов в том числе (если пойти дальше - можно направлением стрелочки указывать направление вызова, а надписью на стрелочке указывать уже направление движения сущности).
    в РКМ это не реализуемо вовсе. То есть нарисовать "кто с кем" - понятно, но не понятно в каком процессе и кто за кем.

    Да и что делать если интеграция идёт не через какую то общую шину?

    Если Интеграция - не шина, то что мешает отразить это квадратиками, которые связаны через один большой прямоугольник в центре? (это я пытаюсь понять выгоду именно от радиального изображения)