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 системы), а не только изменениям фенома как «доработке по месту напильником» экземпляра системы. В ходе эволюции система рассматривается уже не как экземпляр (возможно, промышленная серия с одинаковыми экземплярами), а как вид — где конфигурация каждого экземпляра может быть уникальной, непрерывно обсуждаются умные мутации/smartmutations[9],** с наибольшей вероятностью ведущие к успешности системы (в дарвиновской эволюции — это случайные мутации при репликации) и даже в отличие от естественного отбора ведётся промышленное A|B тестирование, (и даже больше, ибо тестируются не только два варианта, а во множестве подсистем множество вариантов сразу) как направленная селекция таких мутаций. Развитие/evolving системы стараются делать как можно более приближенным к бесконечному, максимально долго приспосабливая систему к неизбежным изменениям как в окружении, так и в ней самой, так и в системах создания. В биологии и науках о жизни аналогичные проблемы приближения к бесконечному по времени развитию обсуждают как **бесконечное развитие/**open-endedness[10].
Тем самым в онтологии системы появилось отражение идей эволюции и её начали развивать в рамках третьего поколения системного подхода, который не только учитывает системы создания из агентов в их разных проектных/деятельностных ролях, но и учитывает в явном виде с тремя временами: оперирования системы как фенома, создания инкремента фенома из мемома (**проектирование/**design и изготовление/implementation), изменения мемома (эволюции, continuous everything).
Waterfall model, https://en.wikipedia.org/wiki/Waterfall_model ↩︎
Manifesto for Agile Software Development, https://agilemanifesto.org/ ↩︎
Neal Ford, Rebecca Parsons, Patrick Kua, Building Evolutionary Architectures, 2017, https://www.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/ ↩︎
Joel Lehman, Jonathan Gordon, Shawn Jain, Kamal Ndousse, Cathy Yeh, Kenneth O. Stanley, Evolution through Large Models, 2022, https://arxiv.org/abs/2206.08896 ↩︎
Software Product Lines matures into the next generation of Systems and Software Product Line Engineering, https://www.softwareproductlines.com/ ↩︎
The Continuous Everything (CE) concept defined, https://en.itpedia.nl/2021/06/02/het-continuous-everything-ce-concept-gedefinieerd/ ↩︎
Nicole Forsgren, Jez Humble, Gene Kim, Accelerate, 2018, https://www.oreilly.com/library/view/accelerate/9781457191435/ ↩︎
Aeris Stewart, How Is Platform Engineering Different from DevOps and SRE?, 2022 https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre/ ↩︎
Kenneth O. Stanley, Joel Lehman and Lisa Soros, Open-endedness: The last grand challenge you’ve never heard of, 2017, https://www.oreilly.com/radar/open-endedness-the-last-grand-challenge-youve-never-heard-of/ ↩︎