Эта статья изначально была опубликована в журнале Архитектура и управление

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

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

Чтобы добиться успеха, вы сосредотачиваетесь на трех ключевых областях:

1. Знайте код

2. Сделайте архитектуру видимой для всех.

3. Наведите мосты между командами.

Продолжайте кодировать

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

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

Найдите время, чтобы периодически объединяться с членами каждой команды. Разработчики часто не без оснований полагают, что архитекторы «посттехнологичны» и больше не могут понимать мир, в котором они живут. Демонстрация разработчикам, что вы заинтересованы в их работе, и что вы все еще можете идти в ногу, укрепит ваши отношения с ними. Это также поможет вам понять их болевые точки и узнать о слабых местах в архитектуре. Эти знания сделают вас лучшим архитектором и помогут лучше обслуживать вашу организацию.

Видение и видимость

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

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

Чтобы не быть единственным источником этих знаний, сделайте архитектуру видимой для всех. Периодически создавайте плакаты всей архитектуры или ее частей и размещайте их на видном месте. Оставьте материалы людям, чтобы они могли размечать плакаты и оставлять отзывы. По мере развития архитектуры обновляйте дисплеи, чтобы каждый всегда мог видеть, что создается и что изменяется. Цифровые артефакты, такие как вики и слайдеры, - это нормально, но их легко игнорировать или забыть. Я лично написал сотни страниц документов, которые никогда не читались, но плакат размером 3х4 дюйма в комнате для команд нельзя игнорировать.

Наводить мосты

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

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

То же, но другое

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