• Эволюционное проектирование
• Эволюционая архитектура
• Определение Фитнес Функции
• Контролируемая эволюция
• Эволюционные характеристики
• Проблемы

Несмотря на нашу позицию разработчика или архитектора, мы не можем знать как удовлетворить всем требованиям до того, как эти требования будут определены, описаны, высказаны в любом доступном и понятном всем участникам виде. С точки зрения функций и задач, мы знаем часть, которую можно решить программно. На стыке задачи и реализации возникает уровень, где объединяются между собой код и сама идея - бизнес идея и требуемая функциональность.

Мир не стоит на месте. Все меняется и меняются также условия существования любой реализации. Вместе с этим меняются и условия ведения бизнеса - меняются деловые партнеры, меняются цены, условия лицензирования, а вместе с ними и отношения. Это условия реального мира. Законы бизнеса, в отличие от физических законов природы, дают нам более динамическую и менее предсказумую среду. Изменения происходят постоянно и нужно уметь правильно на них реагировать. Если в природе выживает самый сильный, то в бизнесе выживает самый гибкий.

Программная инженерия бизнеса нацелена не только на реализации главной функции системы, но и на удовлетворение изменяющимся условиям самого бизнеса. В качестве инструментов выступают процессы. Сами по себе программы статичны - это строки кода, выполняющие свою задачу. Процессы декларируют способ внесения изменений в программы. Более того, процессы описывают способ определения необходимых изменений и их качеств. Каждая система обаладает рядом критериев, которые ценны для бизнеса: надежность, устойчивость, быстродействие и другие. Изменения кода и окружения влияют на критерии системы. В качестве двигателя изменений выступают ресурсы: технические, человеческие, временные. Изменения потребляют ресурсы и производят дельту изменений критериев системы. Производство систем также использует в качестве ресурсов инструменты, фреймворки, другие системы. Все это образует экосистему, которая характеризует среду существующей системы.

Элементы системы меняются, меняется среда существования - это условие эволюции.

• Можно ли предсказать изменения в системе заранее?
• Частично - да.

• Можно ли бы готовым к любым изменениям?
• Нет, все предвидеть невозможно.

• Можно ли предсказать изменения в системе вообще?
• С большой долей вероятности - да, это возможно. Более того - все точно изменится, но мы не знаем что конкретно и в какой момент времени.

• Что нас ограничивает в точности?
• Время. Мы не можем гарантированно давать прогноз на долгий промежуток времени.

• Насколько точно мы можем планировать в условиях постоянно непредсказуемо меняющихся условий среды системы?

Последний вопрос - один из важнейших вопросов, с которым приходится сталкиваться в программной инженерии бизнеса.

Есть и другой не менее важный вопрос. Как добиться постоянства достигнутых бизнес критериев: audability, performance, security с одной стороны, и data, legality, scalability с другой так, чтобы система соответствовала требованиям?

Как предупредить деградацию критериев системы с изменением архитектуры системы? Все постоянно меняется.

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

• Чем оперирует эволюционный способ?
• Единицами изменений в различных измерениях.

Эволюционая архитектура (ЭА) базируется на определенных инкрементных изменениях в различных измерениях.

Фитнес функция (ФФ) - функция, определяющая насколько текущая архитектура соответствует необходимым критериям.

Изменение должно быть определено. ФФ определяет что работает хорошо, что изменилось в измеримых пределах в архитектурных характеристиках.

Инкремент - одно изменение, влияющее на поведение системы. Изменения могут быть как операционного уровня, влияющие на среду выполнения, так ифункциональные, влияющие на поведение системы. Изменение влияет на общие критерии, а также на бизнес критерии системы.

ФФ может быть определена через любой способ измерения, дающий метрики: метрики производительности, количество успешных или провальных юнит тестов, связность модулей, зацепление модулей, результаты AB тестов в виде подтверждения или провала гипотез, динамика физических критериев системы.

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

Принцип эксперимента - одно изменение за шаг. Таким образом можно сравнить результат влияния изменения итерационно. К изменениям относятся обновления среды выполнения, изменение версии элемента системы (изменение в коде), обновление библиотек. Изменение должно позволять проверить результат. Это характеристика возможности проверки. В коде возможны юнит тесты, интеграционные тесты при обновлениях библиотек зависимостей. В платформе возможно сравнение в логах до и после обновления.

Deployment pipelines позволяют последовательно применить проверки после обновления кода. Это тесно соотносится с CI, CD. Механизм тригеров позволяет использовать преимущества автоматизации.

Некоторые ФФ проектируются для проверки кода с архитектурной точки зрения до деплоя. Целостные ФФ запускаются уже после деплоя, возможно, даже после масштабирования. В результате могут быть проверены такие критерии: scalability, integration with other servers, security, auditability.

Главная системная ФФ включает в себя все возможные и проверяет результат на соответствие необходимым критериям. Комбинация критериев в различных значениях может позволять запрет релиза до исправления результата соответствующей ФФ.

Какие характеристики важнее других? Требования длолжны идти от бизнеса, который решает задачу. В разрезе задачи может проявиться необходимость в таких характеристиках, как гибкость, модульность, надежность, сколрость, защищенность, расширяемость, экономность. От этого тоже может зависеть будущее проекта, команды, бизнеса, людей, скорости развития.

Экономность не всегда выступает главной характеристикой, но мы вполне можем услышать, что достижение другой характеристики слишком дорого и это неприемлемо. Характеристики не существуют сами по себе. Всегда есть влияние, в той или иной мере.

Скорость прохождения цикла выпуска релиза зависит от всех тестов, которые запускаются перед деплоем.

Цикличкеские зависимости.

Тооллерантность к ошибкам.