SOA-архитектуры? В такой ситуации надо создавать микросервисы, которые обеспечат распределенность, а то по факту просто системы заменили платформами!» И принципиально внимательный читатель будет прав: фактически значимая доработка продукта, созданного в подобной архитектуре, будет весьма схожа с его доработкой при реализации принципов SOA. Действительно, столь разная организация автоматизации каждого уровня продукта, предоставляемого организацией клиентам и/или партнерам, потребует фактически выделенной продуктовой команды на каждом уровне. Да, в случае простого продукта можно составить продуктовую команду, отвечающую принципам гибких практик, но современные продукты (а особенно если речь идет о кросс-продуктах) крайне сложны, требуют привлечения специалистов разных компетенций. А потому даже на одном уровне автоматизации (при приведенном выше примере принципиально различных технологических и организационных требованиях к базису каждого) может оказаться весьма затруднительным собрать единую команду гибких практик, развивающую соответствующий продукт. После чего возникнет необходимость синхронизации работы команд для обеспечения качества создаваемого продукта, дабы последний не стал подобен лоскутному одеялу из слабо связанных между собой доработок, что в свою очередь может повлечь как рыночную слабость продукта, так и нарушение непрерывности его предоставления. При этом команда развития каждого уровня автоматизации продукта реализует требуемые доработки с разной скоростью, зависящей от функциональной и нефункциональной составляющей, например:
• Доработки могут проводиться на некотором подмножестве уровней автоматизации продукта: доработки фронтального представления, например, не затрагивать учетные составляющие.
• Различный технологический базис уровней автоматизации приводит к разной скорости их развития в соответствии с нефункциональными требованиями.
Добавим сюда еще и возможное попадание в ментальную ловушку, рассмотренную в главе «Архитектуры цифрового мира», посвященной цифровым платформам, а именно создание выделенных команд разработки и развития платформ. В случае масштабирования указанной ошибки на рассматриваемую в примере организацию может оказаться вероятным, что продукт разрабатывается набором команд гибких практик разработки, при этом для каждой платформы в организации существует отдельная команда развития. Получается, что в общем случае (при условии высокой сложности автоматизируемого продукта) мы можем столкнуться с ситуацией, при которой в реализации значимой продуктовой доработки могут быть задействованы до восьми (!) команд разработки. Синхронизация их деятельности становится весьма нетривиальной задачей. И даже совмещение платформенных и продуктовых команд в отдельных случаях (например, это вполне возможно для случая автоматизации функций синтетического учета) не привносит принципиального