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

Question

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

Идея (еще на этапе прототипа) заключается в создании своего рода Карты на основе Visio или аналогичного инструмента, который отслеживает связь и взаимозависимости между всеми ИТ-активами в компании, так что, когда кто-то просит изменения они могут получить обзор воздействия.

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

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

NB: Вопрос не «У меня есть все эти данные я собирал о ИТ-активов и я не могу позволить себе Visio или Google для Graphviz или преобразовать его в инструмент MindMapping или создать пользовательский навигатор с использованием JGraph и т.д. .и т.д.". Проблема заключается в том, «как мне собрать соответствующую/полезную информацию и как ее организовать, учитывая, что мне, возможно, придется регулярно обновлять данные из-за изменений интерфейса, версии и пакета?»

Это не проблема визуализации, или еще нет. Сначала нам нужно начать с сбора данных и организации. Если вы хотите предложить инструмент, он должен также включать часть сбора данных и управления (например, Rational System Architect). Но в этом случае, пожалуйста, предложите его, если у вас есть какой-то фактический опыт, или если вы уверены, что это совершенно ниша и не очень хорошо знаете (я могу сказать, что спасибо Google). Если вы хотите предложить некоторые книги/методологии, это тоже полезно (я знаю только о Zachman Framework и не уверен, что это действительно подходит).

«Просто создайте файл Excel» или «Вы можете использовать SmartDraw, мужчина !!!» Боюсь, не очень помогаю.

---

Найдено Iteraplan, который выглядит очень хорошо!

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

alt text http://heeroz.com/depends.png

Answer 4

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

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

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

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

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

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

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

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

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

Мои предложения являются:

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

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

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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

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

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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

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

Answer 10

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

https://www.iteraplan.de/en

Answer 11

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

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

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

Answer 12

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

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

Answer 13

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

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