Как создать "график зависимостей" для ИТ-активов

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я надеюсь, что это поможет.

Ответ 2

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

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

Это также послужило бы прекрасным документом, который бы сам по себе.

Ответ 11

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

https://www.iteraplan.de/en

Ответ 12

Для организации и представления информации о приложениях, технологиях, активах и т.д. мне очень нравится Iteraplan. Это инструмент моделирования архитектуры корпоративного источника с открытым исходным кодом, ориентированный на "IT Landscaping", который в значительной степени сводится к захвату данных (списков и ссылок) о ваших технологических активах и подготовке отчетов. Поэтому полезно ответить на такие вопросы, как "какие приложения используются для X во всех наших сферах бизнеса" или "какие системы у нас есть запущенные технологии, которые были в конце срока службы" или "какие приложения работают на этом сервер" или "какие системы не прошли проверку безопасности". Дополнительная информация на http://www.iteratec.de.

Для диаграмм UML, Sparx Enterprise Architect является отличным и довольно дешевым. http://www.sparxsystems.com. Подумайте об этом как о Visio, который знает, что он диаграммирует, поэтому вы действительно строите модель своего предприятия/приложений в базе данных, и диаграммы привязаны к этому. Очень могущественный. Дружелюбнее и значительно дешевле, чем Rational.

Ответ 13

Для сбора и управления данными я также использую Iteraplan. Это отлично подходит для сбора данных Enterprise Architecture и для создания определенных видов визуализации.

Для UML-диаграммы мы используем Sparx, что отлично. Мы работаем над инструментом для интеграции двух. Мы заселяем репозиторий Sparx данными от Iteraplan, что упрощает схему.