Continuous everything в инженерии как техно-эволюция ​

Ограничением водопадной модели^[1] была идея однократного однонаправленного прохождения создателями жизненного цикла как набора работ, проводимым по практикам, причём целевая система рассматривалась как пассивно претерпевающая это разовое создание. Поэтому в инженерии развивались agile-подходы, преодолевающие понятие «водопадного» жизненного цикла, в 2001 году появился Manifesto for Agile Software Development^[2]. В 2017 году идея evolvability как основного архитектурного свойства, отражающего идею непрерывного всего/continuous everything закрепилась не только в передовой инженерной практике, но и закрепилась в литературе^[3], а архитектура окончательно выделилась из разработки в отдельную предметную область, ибо литература стала отражать неизбежные «продуктивные конфликты» архитекторов с разработчиками. Архитектура работала над нарезкой системы на минимально взаимодействующие модули для поддержания стабильности общего целого в эволюционном масштабе времени (хорошо известные инженерам -ости/-ilities оказались архитектурными характеристиками), а разработчики заботились о максимизации функциональности, что могло влечь временное ухудшение архитектурных характеристик как накопление технического долга (работ, направленных на поддержание выбранных архитектурных решений, но не затрагивающих напрямую функциональность).

В инженерию пришли идеи техно-эволюции, но они отличались от идеи биологической эволюции тем, что мемом как аналог биологического генома не находился в самой изготавливаемой системе, а хранился в цифровой (то есть подразумевающей точное повторение при репликации без накапливания аналоговой ошибки) форме где-то в системах-создателях. Это позволяло существенно ускорить эволюцию, ибо для какого-нибудь технокраба не надо было ждать, пока умрёт целый краб, чтобы путём мутаций формирующих феном клешни генов заменить неудачный вариант клешни только вместе с крабом. Также можно было использовать умные/smart мутации, получая результаты, то есть в реальной жизни пробовать только варианты клешни, показавшие успешность при моделировании в виртуальном мире --- и менять только клешню, но не всего краба. Это давало высокую скорость техно-эволюции и её результаты, недостижимые только разовым предложением набора новых фич (разовое прохождение «водопада» для одного экземпляра системы) или только эволюцией со случайными мутациями^[4]. Для понимания, насколько удачна система в эксплуатации, появилось моделирование системы для времени операций --- цифровой двойник, отражающий не только мемом, но и феном системы. Так что онтологии системы, ориентированной на два времени (1. эксплуатации и 2. создания одного инкремента/фичи) оказалось недостаточно. Недостаточно было и средств моделирования целой группы систем (product lines^[5], иногда system families) как сосуществующих в один момент времени разных вариантов системы.

Выход оказался в идее непрерывного всего/continuous everything^[6] как бесконечно длящейся разработки с непрерывным вводом в эксплуатацию/continuous delivery всё новых и новых вариантов целевой системы со всё новыми и новыми изменениями, причём незамедление темпов разработки при растущей сложности целевой системы поддерживается как изменяющейся по ходу разработки (evolving) архитектурой, так и изменяющейся структурой команд/teams, которые осуществляют эту разработку (использование обратного манёвра Конвея^[7]). В software engineering эта идея развивалась в рамках подхода DevOps/SRE/platform engineering (инженерия внутренней производственной платформы)^[8], в «железной» инженерии эта идея обсуждается сейчас на традиционных для системной инженерии примерах аэрокосмоса, когда испытания двигателей следующей версии начинаются раньше, чем испытанные двигатели предыдущей версии в составе ракеты улетают в свой первый полёт, а каждый новый экземпляр ракеты имеет новые фичи и/или улучшенную конструкцию по сравнению с предыдущим экземпляром. «Непрерывное всё» означает переход инженерии к техно-эволюционным проектам, то есть умным (неслучайным) мутационным/эволюционным изменениям мемома (информационной модели проекта/design системы), а не только изменениям фенома как «доработке по месту напильником» экземпляра системы. Развитие/evolving системы стараются делать как можно более приближенным к бесконечному, максимально долго приспосабливая систему к неизбежным изменениям как в окружении, так и в ней самой, так и в системах создания. В биологии и науках о жизни аналогичные проблемы приближения к бесконечному по времени развитию обсуждают как бесконечное развитие/open-endedness^[9].

Тем самым в онтологии системы появилось требование отражения идей эволюции --- если бы была развитая онтология эволюции, то её можно было бы использовать для развития третьего поколения системного подхода, который не только бы учитывал системы создания из агентов в их разных проектных/деятельностных ролях, но и работал бы в явном виде с тремя временами: оперирования системы как фенома, создания инкремента фенома из мемома (проектирование/design и изготовление/implementation), изменения мемома (эволюции, continuous everything).