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

Заметки с полей

Облачный подход, или, другими словами, коммодитизация (commoditization), – это этап развития процесса или технологии, на котором они становятся достаточно значимыми, инновационными и конкурентоспособными, чтобы превратиться в общедоступный продукт. Два хороших примера – веб- и почтовые серверы. Также в последнее время создавать и поддерживать собственный кластер серверов баз данных стало дороже, чем заказать БД-как-услугу (database-as-a-service) у одного из крупных облачных провайдеров, то есть базы данных тоже перемещаются в облако. Раньше у вас была целая команда администраторов баз данных, которая занималась резервным копированием, оптимизацией и аварийным восстановлением, а сейчас все это можно сделать одним щелчком мыши в браузере. Некоторые считают, что при этом утрачивается контроль, но на самом деле это означает, что теперь есть целый ряд технологий, которыми больше не нужно управлять.

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

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