Моё понимание (которое я там и высказал) не выделяет особо "управление жизненным циклом" из системной инженерии. Все дисциплины системной инженерии нужны, все практики важны и связаны, а "управление жизненным циклом" не представляет из себя отдельной профессиональной дисциплины.
Очень смешно звучало несколько докладов, в которых центральным был термин PLM с многократным указанием, что "PLM не сводится к чисто IT-решениям". Сам факт, что "PLM -- это не IT" требуется указывать специально, означает встроенную в данный подход "управления жизненным циклом" проблему. Без рассмотрения в рамках системной инженерии PLM представляет собой произвольно выдергиваемое подмножество практик, инструментов, профессиональных позиций.
В кулуарах убедился, что вопрос об архитектуре не проходится в темпе "лифтового объяснения". Архитектура -- это набор описаний/моделей, показывающий связь между функциями (назначением) системы и ее конструктивными элементами. Архитектура готовится системным архитектором в плотном взаимодействии с инженером по требованиям (ответственным за согласование набора функций с многочисленными заинтересованными сторонами) и инженерами по специальностям (теплотехниками, электриками, механиками и т.д.).
Это, вроде, просто -- но на самом деле очень сложно. Само определение функции (в некоторых школах слово "функция" вводится чуть ли не как синоним системы -- см., например, тут выражения типа function/system: http://15926.info/representing%20a%20system/index.htm), но само по себе инженерное употребление слова "функция" включает пять разных позиций (работы Andries van Renssen). Архитектура не обсуждается иначе, нежели через архитектурное описание, заключённое в набор различных архитектурных артефактов. Конструкция (структура, материал) -- не менее сложный объект. На всё это накладывается иерархия разбиения системы на элементы (на каждом уровне этой иерархии возникает пара "функция-конструкция" -- http://15926.info/functional-physical-object/index.htm). Тем самым функции и конструкция путаются, архитектура не документируется в каких-то оговоренных артефактах с нужным набором моделей, омонимы затрудняют понимание, а отсутствие инженерной рамки (инженерии архитектуры, создания набора архитектурных артефактов/рабочих продуктов) не позволяет обсуждать архитектурную деятельность.
А мы ещё не добрались до подробного обсуждения инженерии системной архитектуры, всё продолжаем разбираться с инженерией требований.