Как создать “граф зависимостей” для [закрытых] активов IT

Вы пробовали использовать Graphviz?

Он может построить график на основе зависимостей в текстовом файле. Просто!

Вы можете начать с Graphviz Gallery для базовых примеров и результирующих диаграмм.

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

Если это так, то, что вы использовали бы для графического отображения макета, вероятно, была бы диаграмма развертывания в UML.

Вы наносите на карту системы / серверы / физические активы в виде коробчатых объектов, а затем внутри них отображаете различные приложения, базы данных, компоненты и их взаимосвязи друг с другом.

Проблема с использованием UML заключается в том, что программисты сосредотачиваются в основном на диаграммах классов (из-за их прямого отношения к моделированию данных в программном обеспечении), поэтому трудно найти «хорошие» ресурсы и примеры на диаграммах UML, не относящихся к классам.

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

Для создания диаграммы я использовал диаметр . Если бы мне пришлось делать это снова и снова, я бы определенно использовал Visio, потому что намного проще найти готовые пакеты трафаретов / шаблонов для построения диаграмм в Интернете , и если у них нет того, что вам нужно, это очень легко накатывать собственные трафареты в Visio.

Примечание. У меня большой (сотни часов) опыт работы с Visio в области проектирования электрических систем, поэтому я считаю себя достаточно знакомым с инструментами, чтобы провести объективное сравнение.

Обратной стороной к адаптации хорошо определенного формата является:

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

Мои предложения:

• сделайте диаграммы максимально простыми насколько возможно
• не бойтесь нарушать правила
• делайте диаграммы как можно более простыми
• делайте все, что в ваших силах, чтобы диаграммы были как можно более прямолинейными и простыми
• ... вы поняли.

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

Я бы счел Zachman Framework плохим вариантом, потому что:

• трудно понять «точку», которую диаграммы пытаются передать
• форматы диаграмм слишком сложны
• правила имеют негибкий формат, который ограничивает, а не дополняет структуру системы

Пока вы исследуете варианты, спросите себя об этом. Вы понимаете суть диаграммы?

Проблема с построением схемы проекта в том, что если сделать его неправильно, то создаст больше головной боли, чем его ценность, и никто не будет его использовать. Нет проектного документа обычно лучше, чем плохой проектный документ.

Надеюсь, это поможет.

Я не уверен, нужно ли вам фиксировать только отношения или также роль (зависит от зависимого, как в отношениях родитель-ребенок). Кажется, что следующее делает все, что вам нужно:

_{(источник: heeroz.com)}

В Visual Studio 2010 есть отличная новая функция под названием «Architect Explorer», которая позволяет создавать графики, показывающие зависимости различных классов .net.

Может помочь, если вы скажете, какие технологии вы используете.

Возможно, хорошим решением для хранения ваших данных будет написание простого пользовательского веб-приложения. Если у вас есть четко сформулированные требования, это будет проще простого. Это будет дешевле, чем покупка какого-нибудь огромного настраиваемого инструмента, но может занять некоторое время на разработку. По моему опыту, иногда лучше сделать что-то, что соответствует именно вашим потребностям, чем изучать какой-то новый инструмент общего назначения, который был разработан для того, чтобы делать все и ничего.

О визуализации: Я проверил различные инструменты для UML и связанных диаграмм и нашел два, которые очень хорошо подходят для большинства задач (очень интуитивные, простые в использовании и экономящие время).

1. VisualParadigm - корпоративная вещь, много диаграмм, мощный и довольно простой интерфейс, рекомендуемый для вашего случая, я думаю. Может также иметь поддержку для поддержания данных, с которыми вы работаете.
2. UMLet - мой любимый:) очень прост и умеет делать большинство вещей, которые умеют большие игроки.

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

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

С помощью рабочего процесса, даже приблизительного, должно быть довольно просто проанализировать, какие люди взаимодействуют с какими системами посредством каких действий. Конечно, это не простая задача. Описать задачи каждой работы - это определенно сложная задача. Однако рабочий процесс хорош тем, что его легко понять. Его можно распространить по всей компании, и его гораздо легче поддерживать в актуальном состоянии, потому что это то, что любой менеджер должен уметь поддерживать для себя и своей команды.

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

Это также послужит отличной документацией.

Я знаю как минимум двух клиентов, два крупных финансовых учреждения, которые внедрили настраиваемое веб-приложение, позволяющее достичь той же цели (поиск зависимостей для проведения анализа воздействия), и я скромно считаю, что вам не нужна карта для «визуализации» вещи.

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

Я бы реализовал это, используя среду быстрой разработки приложений CRUD, такую ​​как RoR, Grails и т. Д., Что они (указанные выше финансовые учреждения) и сделали.

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

Вы можете рассмотреть возможность построения SADT модели. Ячейки в SADT-моделях представляют процессы. Маркированные дуги ввода данных показывают, какая [возможно, составная] информация/ресурсы поступает в процесс; маркированные дуги вывода показывают данные/ресурсы, произведенные им. Управляющие дуги указывают на "большие" сигналы, которые управляют процессом. Дуги ресурсов/механизмов показывают, какие ресурсы требуются для осуществления процесса (например, аппаратные системы, сети, ...).

Для вашей задачи вы будете рассматривать приложения и деятельность компании как процессы SADT (коробки). Дуги входа/выхода данных и управления соединяют приложения (ящики SADT) с другими ящиками SADT или с внешними источниками и поглотителями данных (внутренние отделы, персонал, продажи, доставка, например, корпоративные заинтересованные стороны). Таким образом, вы можете моделировать информационные потоки в компании через различные приложения и то, какую информацию они потребляют/обрабатывают/производят/используют, и какие агенты производят/используют данные. (Выполнение всего этого называется "Структурированный анализ").

[Для сложных моделей SADT каждый блок процесса может быть полезно рекурсивно разложен на поддиаграммы SADT. Я не думаю, что это нужно для моделирования только зависимостей приложений; вам не нужно знать, как приложения работают внутри, если только они не являются действительно сложными и не разделяют потоки данных.]

Любое изменение ввода/вывода информации, удаление приложения будет иметь очевидное соответствие в диаграмме SADT, и таким образом приведет к лучшему пониманию последствий.

Это большая работа, и вам придется работать над тем, чтобы поддерживать ее в актуальном состоянии, что, скорее всего, приведет к неудаче, если только все не будут подписаны на долгосрочную перспективу.

Для тех из вас, кто еще не пробовал использовать SADT, это удивительно простая для понимания система (это соответствует диктуму других ответов keep it simple), и удивительно эффективная в разбиении сложных задач обработки на части, где вы можете увидеть (и фактически передать) практически все, даже менеджерам! Ключ к тому, чтобы заставить SADT работать, - это избегать небрежности; определяйте дуги и узлы тщательно и не пропускайте источники и поглотители информации. Если вы сделаете это, SADT будет хорошо оплачиваться. [Большинство диаграмм с ящиками и стрелками на доске ужасны: невозможно определить, что на самом деле является действием, что на самом деле является данными, вся ли информация на самом деле показана и кто ее использует].

ИМХО интересно отметить, что модели SADT отражают интуицию, лежащую в основе цветных сетей Петри, которые моделируют произвольно сложные асинхронные вычисления, обобщение сетей Петри, которые являются обобщением конечных автоматов состояний.

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

https://www.iteraplan.de/en

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

Затем вам нужно собрать информацию. К счастью, клиент не слишком велик, так что вы можете преуспеть в этом, но в крупных организациях часто бывает так, что они не имеют представления о реальных зависимостях между различными частями их ИТ-инфраструктуры. (Они вполне могут думать , что они знают, и будут упорствовать в этой иллюзии до тех пор, пока они что-то не изменят, и закон неожиданных последствий не укусит.) Хотел бы я порекомендовать некоторые продукты (бесплатные или коммерческие), которые мог бы помочь с этим, но все, что у меня действительно есть, - это смесь военных историй и неудовлетворенности. В частности, многие из более традиционных инструментов для такого рода вещей, похоже, плохо справляются с виртуализированными серверами. Если есть что-то с открытым исходным кодом для такого рода вещей, я бы хотел услышать об этом!

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

@p.marino диаграммная часть продуктов EAI/ESB обычно не стоит того для любой умеренно сложной системы. Самая большая проблема в том, что я до сих пор не видел ни одного продукта, который мог бы показать общую картину и значимые фрагменты системы без чрезмерной ручной настройки.

Возможно, вы захотите проверить реестр/репозиторий ОС, такие как Mule Galaxy, WSO2 Registyry или аналогичный продукт JBoss.

У меня есть опыт создания чего-то подобного с помощью Mule Galaxy. Вы можете определять сущности с атрибутами и зависимостями различных типов. Каждое изменение отслеживается аудитом и может быть продвинуто в соответствии с жизненным циклом. Сущность может быть абстрактной или файлом (например, основным конфигурационным файлом приложения). Также каждая сущность или домен может иметь разрешения на доступ.

Это позволяет вам описать логическую структуру вашей системы удобным для обслуживания способом. Для визуализации вам нужно будет развернуть ее самостоятельно. Вы можете получить данные через простой API в стиле REST.