Методология 2025. Анатолий Левенчук

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

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

      Предлагаемое прикладным методологом функционально-платформенное описание методов предметной области (функциональное разложение/синтез с возможностями альтернативного выбора видов из родов) должно быть как-то сочетано проектировщиком с реальным конструктивно-платформенным представлением, то есть архитектурным в его новом значении: нарезка на конструктивы в каком-то фреймворке. Это всё будет подробно рассказано в курсе «Системная инженерия» и даны примеры специализации системной инженерии до инженерии личности и системного менеджмента в курсах по этим предметным областям. Правда, в текущей версии инженерного цикла курсов явно роль прикладного методолога в составе разработчиков введена только в «Инженерии личности», но это будет исправлено в следующих версиях курсов.

      Прикладной методолог должен ориентироваться в методологическом разнообразии своей предметной области, чтобы подобрать SoTA методы для своей ситуации, а разработчик (неважно чего разработчик – робота как «железной системы», программной системы AI-агента, мастерства или даже интеллекта каких-то людей, разработчик оргвозможностей в организации) должен обладать недюжинным кругозором, чтобы сделать «изобретение» – предложить самые эффективные для реализации функциональных объектов конструктивные объекты, удовлетворив и методологов («всё будет работать в соответствии с расчётами») и архитектора («это не ухудшит архитектурные характеристики»).

      Есть множество методов (в том числе методов описания системы, удобных для применения этих методов) ведения методической, методологической и архитектурной работы в их взаимоувязке. Для примера мы можем использовать классический фреймворк Wim Gielingh из работы «A Theory for The Modelling of Complex and Dynamic Systems»31, он был использован как один из источников идей для семейства стандартов описания систем STEP, ISO 15926 и далее BIM.

      Gielingh вводит понятия functional unit (функциональный объект, «роль» – то, что будет задействовать метод) и technical solution (конструктивный объект, который выбран как аффорданс для реализации роли, то есть выполнения работы функции/метода) и показывает концепцию

31

https://www.researchgate.net/profile/Wim-Gielingh/publication/228797525_A_theory_for_the_modelling_of_complex_and_dynamic_systems/links/00b7d516e525eab19e000000/A-theory-for-the-modelling-of-complex-and-dynamic-systems.pdf