Когда в организации, в которой я работал, решили вывести из эксплуатации систему Symantec Altiris, которая занималась, в том числе, сбором информации о установленном ПО на компьютерах, стало понятно, что системы не будет, а информация нужна И тогда я взялся за проектирование, чтобы иметь хотя бы информацию о установленном ПО. Изучил варианты, обсуждаемые в сети, принципы и подходы, и начал. Зная специфику и функционал Symantec Altiris, я, прежде всего ориентировался на него, в том, что касается сбора информации. Был выбран вариант использования PowerShell, возможность собрать информацию о установленном ПО непосредственно запустив некий скрипт на компьютере, так и собрать удаленно с компьютера, подключенного к сети. Так появился первый, наиболее востребованный на тот момент функционал – сбор установленного ПО. Однако, мне стало понятно, что ограничиваться этим не стоит. В своей работе мне чаще требовалась информация не о ПО, а аппаратной составляющей оборудования (компьютеров и серверов). И появилась возможность собирать базовые характеристики оборудования. Сразу стало понятным, что иметь информацию с одного компьютера это хорошо, но, когда компьютеров несколько, надо получать сводную информацию по всем компьютерам, с которых получена информация. Да, забыл сказать, архитектурно было принято решение реализовать максимально просто, без использования СУБД, и хранить информацию в файлах с разделителями (csv). Таким образом, был реализован механизм объединения однотипной информации в плоские таблицы по всем компьютерам. И, вроде бы, можно остановится, но нет. Захотелось собирать больше разной информации. Я понял, что хочется сделать модульную структуру системы, чтобы для каждого типа собираемой информации был свой отдельный модуль. Провел рефакторинг кода и система стала модульной. Но все же меня не устраивал подход к архитектуре, вроде все работает, вот отдельный модуль для сбора, вот отдельный модуль для объединения, вот модуль для локального сбора. Не красиво. И снова рефакторинг после которого система — это один главный командлет, который в зависимости от параметров запуска выполняет локальный или удаленный сбор или объединение информации. Я бы мог еще долго рассказывать про развитие системы, может быт потом. Скажу, что система собирает 19 типов информации, может это делать удаленно или локально, может объединять информации из разных источников (например, собрать в разных доменах и объединить ее). В ходе работы я понял, что меня привлекает не только сам процесс написания скрипта, но и продумать структуру системы, ее функционал, описать и формализовать требования и реализацию. И выбрал для себя следующее направление деятельности - системный анализ. И да, проект доступен на github https://github.com/PavelNovgorodov/Inventory Пишите, буду рад ответить!