Как стать компонуемым предприятием с помощью автономных команд и программного обеспечения, основанного на компонентах
Привлекательность автономных команд заключается в их способности быть более гибкими, творческими и отзывчивыми, а значит, более конкурентоспособными и инновационными.
Предоставляя командам возможность независимо нести определенные бизнес-обязанности, предприятие становится более компонуемым. В Composable Enterprise программная архитектура обеспечивает быструю компоновку настраиваемых приложений с использованием модульных компонентов, создаваемых и поставляемых автономными командами.
Gartner прогнозирует, что эта эволюция архитектуры постепенно станет новым стандартом, обеспечивающим непрерывную доставку при одновременном повышении производительности и снижении затрат:
«Динамичный опыт компонуемого бизнеса станет преобладающей архитектурой, интеграцией и моделью доставки для инноваций в программном обеспечении».
В этой статье рассказывается, почему сложно сделать команды более автономными, и как программное обеспечение, основанное на компонентах, может стать мощным инструментом компонуемой трансформации предприятия.
Автономные команды полезны для бизнеса
Сегодня компании ожидают, что их команды будут иметь все большую автономию для внедрения инноваций и достижения бизнес-результатов за счет:
- Быстрая доставка. Автономные команды работают быстрее за счет устранения ненужных процессов, зависимости и зависимости от других команд и общих ресурсов, что делает их более эффективными и действенными.
- Близость к рынку. Независимая команда, имеющая очень конкретную бизнес-ответственность, хорошо осведомлена о своих клиентах и пользователях, что дает ей больше возможностей для предоставления индивидуального обслуживания.
- Лучшее реагирование.Автономная команда может раньше замечать тонкие изменения на рынке и быстрее реагировать, внося необходимые изменения для поддержания конкурентного преимущества.
- Более высокая устойчивость. Взаимозависимости могут создавать точки отказа, в которых одна команда может поставить под угрозу способность организации достигать своих целей. Автономные команды работают как независимые ячейки, что делает систему более устойчивой.
- Большая масштабируемость. Наличие слабо связанных автономных команд с определенными бизнес-обязанностями упрощает добавление дополнительных команд и управление ими. Как и в случае с программными системами, модульную и распределенную организацию легче масштабировать.
Предприятиям часто сложно ускорить разработку из-за структуры команды и архитектуры программного обеспечения. В результате непрерывная доставка ценности для бизнеса ограничена, когда автономия низка.
Согласно закону Конвея, архитектура программного обеспечения отражает структуру организации, которая его создала. Компонуемое предприятие будет разрабатывать компонуемые приложения. Монолитное программное обеспечение и автономные команды несовместимы.
Почему предприятия борются с автономными командами
Успешная автономная команда должна иметь возможность действовать быстро, не дожидаясь других команд или общих ресурсов. Вы можете думать об этом, используя следующую метрику:
Сколько времени команда тратит на ожидание ресурсов или других команд?
В идеале мы хотели бы, чтобы это было равно нулю. Однако некоторые взаимозависимости необходимы и служат определенной цели, поэтому мы хотели бы, чтобы команды не теряли времени впустую, но при условии соблюдения организационных стандартов.
Мы можем разделить взаимозависимости команд на две части: горизонтальную и вертикальную:
- Горизонтальная связь возникает между разными командами разработчиков в рамках их совместной работы над конкретным проектом: совместное использование кодовой базы, версии и конвейера CI/CD. Устаревшие инструменты связывают команды по общим ресурсам, создавая веб-монолит, ограничивая возможности каждой команды создавать и выпускать продукты независимо друг от друга.
- Вертикальная связь возникает между командой разработчиков и централизованной корпоративной командой, выполняющей функции контроля, такие как безопасность, соответствие требованиям, обеспечение качества или проектирование. Существующие процессы поддерживают согласованность в программном обеспечении предприятия, но потребляют время и ресурсы в качестве накладных расходов.
Наличие множества разных команд, работающих над одним и тем же приложением, означает, что они конкурируют за ресурсы (кодовую базу, версию, конвейер), что замедляет доставку.
Наличие множества разных приложений создает еще одну проблему, поскольку команды создают дублирующие друг друга усилия и дублируют код. Разработка одних и тех же функций в нескольких приложениях тратит время и ресурсы в краткосрочной перспективе и создает растущий технический долг и несогласованность в долгосрочной перспективе.
Итак, как мы можем перейти от сильно связанных команд к слабо связанным командам в рамках одного приложения? Как команды могут выполнять свои бизнес-обязанности независимо друг от друга, сохраняя при этом стандарты и согласованность?
В этом вся разница между отдельными программными компонентами — они позволяют командам создавать и поставлять код независимо друг от друга, а также интегрировать каждый компонент и использовать его в нескольких приложениях для обеспечения согласованности.
Используя компоненты, стареющие монолиты можно заменить составными приложениями.
Прощай, Monolith, здравствуй, Composable Enterprise!
От автономных команд к компонуемым предприятиям
«Мы хотим, чтобы наши команды и службы были тесно связаны, но слабо связаны», — Дайэнн Марш, технический директор, облачные инструменты, Netflix.
Компоненты по сути становятся строительными блоками для создания корпоративных приложений, поскольку каждый из них выполняет определенную бизнес-задачу. Наличие групп, которые могут независимо создавать и поставлять эти компоненты, — это то, что в конечном итоге делает возможным компонуемое предприятие.
Использование компонентно-ориентированного программного обеспечения для перехода к компонуемым предприятиям требует нескольких факторов:
- Отдельная кодовая база, версия и конвейер. Масштабируемое, эффективное и единообразное создание приложений зависит от несвязанных и готовых к интеграции компонентов. Для этого каждый компонент должен быть независимо разработан в своей кодовой базе, а затем независимо собран, протестирован, проверен и выпущен в производство.
- Совместная работа и интеграция. Чтобы эффективно создавать приложения, команды должны иметь возможность совместно работать над компонентами друг друга и постоянно интегрировать их. Это включает в себя обнаружение существующих компонентов, их документацию и возможность визуализации зависимостей для понимания потока компонентов в масштабах всей компании.
- Демократизация управления. Компоненты дают предприятиям возможность стандартизировать разработку, например настраиваемые шаблоны разработки, среды разработки и конвейеры сборки. Их можно использовать для определения и контроля того, как компоненты разрабатываются, тестируются, публикуются, совместно используются, интегрируются и документируются каждой командой в отдельности в рамках проектов.
Использование платформы для компонентно-ориентированного программного обеспечения, такого как Bit, может иметь большое значение для создания компонуемого предприятия. С помощью Bit автономные команды могут создавать компоненты и обслуживать их для производственной линии программного обеспечения организации, помогая разработчикам создавать, компоновать и совместно работать над компонентами и создавать приложения, предоставляя при этом корпоративным инструменты для управления и стандартизации разработки.
Переход на программное обеспечение, основанное на компонентах, создает экономику компонентов в масштабах всего предприятия. Это больше, чем просто наличие рынка компонентов, на котором команды разработчиков и разработчиков могут находить компоненты и стимулировать их внедрение.
В экономике компонентов каждый компонент служит всему предприятию и создает экспоненциальную совокупную ценность — повторное использование компонентов экономит время и ресурсы разработки, предотвращает дублирование кода, ускоряет доставку, сокращает обслуживание кодовой базы, повышает производительность. , повышает согласованность и ускоряет адаптацию новых разработчиков.
Более того, повторное использование компонентов позволяет предприятию рассматривать каждую бизнес-ответственность изолированно и принимать более обоснованные решения «создавать или покупать»: должны ли мы создавать компонент для обмена сообщениями или использовать Twilio в качестве компонента? Должны ли мы создавать компонент для платежей или использовать Stripe?
Это позволяет организации использовать только те компоненты, которые ей необходимы, от сторонних поставщиков и беспрепятственно интегрировать их в свои приложения. Каждая часть программного обеспечения становится взаимозаменяемой — и при необходимости может быть передана на аутсорсинг.
Заключение
Автономные команды добиваются лучших бизнес-результатов, двигаясь быстрее, находясь ближе к рынку и лучше реагируя на изменения в динамике рынка.
Но автономия команды — это не только структурная или культурная черта. Она тесно связана с архитектурой корпоративного программного обеспечения: модульная архитектура позволяет автономным группам самостоятельно разрабатывать и поставлять компоненты. Монолитная архитектура не позволяет им приносить пользу бизнесу.
Уменьшение взаимозависимости команд друг от друга — как вертикально, так и горизонтально — является ключом к реализации преимуществ компонуемого предприятия, заменяя устаревшие монолиты быстро компонуемыми приложениями.
Компонентно-управляемое программное обеспечение может помочь предприятиям перейти к компонуемости: пусть автономные команды создают версии компонентов независимо друг от друга в своей собственной кодовой базе для совместной работы и совместной разработки приложений — и все это при стандартизации процесса разработки.
Не стесняйтесь комментировать и предлагать свои собственные идеи о том, как осуществить переход на компонуемое предприятие и внедрить компонентную экономику в свою организацию.
