Мешать будут многие факторы - рыночные и нерыночные. Но ваш вопрос как будто подразумевает, что концентрация - это априори вредно. Так ли это, если взглянуть глазами капиталиста?
Монополизация и разделение труда одновременно. Идеальный вариант для многих компаний: найти своё место в отраслевой или экосистемной цепочке ценности, а затем постараться монополизировать эту нишу - стать незаменимой. Размер такой ниши и степень контроля над самой цепочкой зависят от рынка, силы бренда и объема капитала.
Спасибо за подробный анализ, сделанный в комментарии.
Чем дальше мы распиливаем монолиты, тем больше я убеждаюсь, что дилемма монолит/микросервисы лежит больше в технической плоскости. Иными словами, мы можем спроектировать приложение по DDD и развернуть его, как на единой базе, так и из множества сервисов.
Тем не менее, в плюсы правильно приготовленной микросервисной архитектуры хотел бы записать «адаптивность» — например, возможность для одного бэкенда сделать разные фронты с отличающимися сценариями на разных языках. Бэкенд тоже можно сделать компонентным — первую часть реализовать на одном легаси монолите, вторую — на другом, а дополнительные возможности — на сервисах.
Плюс к масштабируемости, упомяну поддержку разных профилей нагрузки при выполнении тех или иных операций, и понятную реализацию highload-паттернов.
Плюс нативная открытость — поскольку API уже созданы, из внутренних их сравнительно несложно сделать внешними. И документировать вместе с развертыванием.
Всю эту историю можно квотировать, логировать и мониторить на базе пропорционально масштабируемого оркестратора.
В части финансовых решений они всегда консервативны — работа такая. Но в отношениях к инновациям — зависит от человека и компании: сейчас наш CFO активно поддерживает трансформацию.
Спасибо за развернутый комментарий! Действительно, в классическом проекте нет бюджетной гибкости, поскольку это из компонентов коммитмента. Соответственно, бюджетные решения принимаются на уровне программы или портфеля. В статье, при делегировании инвестиционных решений, прежде всего подразумевается не прямое наращивание суммы бюджета, а дробление портфелей и относительная свобода выбора содержания бэклогов команд.
Проект превращается в один или несколько эпиков, которые по факту имеют свою стоимость (и желательно бизнес-кейс).
Решения о выделении существенных дополнительных сумм согласовываются более централизовано, тем не менее мы уходим от необходимости единого PMO.
Правильный эксперимент или нет, но суть в деградации роли не только рекрутинга, но в целом функции HR.
КПЭ на экономию, а не на развитие бизнеса. Как следствие, манипуляции с бюджетами, желание снять с себя ответственность.
Отсутствие возможности реально оценивать кандидатов и сотрудников, и официально влиять на принятие решений.
Зато интриговать и проводить непопулярные решения - это часть профессии, что часто подкреплено образованием в сфере психологии.
Есть компании, которые с этим работают и справляются, когда HRD реально продвигают ценности не только рядовым сотрудникам, но руководству компании.
Мешать будут многие факторы - рыночные и нерыночные. Но ваш вопрос как будто подразумевает, что концентрация - это априори вредно. Так ли это, если взглянуть глазами капиталиста?
Монополизация и разделение труда одновременно. Идеальный вариант для многих компаний: найти своё место в отраслевой или экосистемной цепочке ценности, а затем постараться монополизировать эту нишу - стать незаменимой. Размер такой ниши и степень контроля над самой цепочкой зависят от рынка, силы бренда и объема капитала.
Чем дальше мы распиливаем монолиты, тем больше я убеждаюсь, что дилемма монолит/микросервисы лежит больше в технической плоскости. Иными словами, мы можем спроектировать приложение по DDD и развернуть его, как на единой базе, так и из множества сервисов.
Тем не менее, в плюсы правильно приготовленной микросервисной архитектуры хотел бы записать «адаптивность» — например, возможность для одного бэкенда сделать разные фронты с отличающимися сценариями на разных языках. Бэкенд тоже можно сделать компонентным — первую часть реализовать на одном легаси монолите, вторую — на другом, а дополнительные возможности — на сервисах.
Плюс к масштабируемости, упомяну поддержку разных профилей нагрузки при выполнении тех или иных операций, и понятную реализацию highload-паттернов.
Плюс нативная открытость — поскольку API уже созданы, из внутренних их сравнительно несложно сделать внешними. И документировать вместе с развертыванием.
Всю эту историю можно квотировать, логировать и мониторить на базе пропорционально масштабируемого оркестратора.
Спасибо за развернутый комментарий! Действительно, в классическом проекте нет бюджетной гибкости, поскольку это из компонентов коммитмента. Соответственно, бюджетные решения принимаются на уровне программы или портфеля. В статье, при делегировании инвестиционных решений, прежде всего подразумевается не прямое наращивание суммы бюджета, а дробление портфелей и относительная свобода выбора содержания бэклогов команд.
Проект превращается в один или несколько эпиков, которые по факту имеют свою стоимость (и желательно бизнес-кейс).
Решения о выделении существенных дополнительных сумм согласовываются более централизовано, тем не менее мы уходим от необходимости единого PMO.