Как принять решение, когда все опции плохие?
Если жить в мире паттернов и лучших практик, то всегда можно натянуть сову на глобус и не переживать за выбор альтернатив. Но есть плохие новости – AI это умеет делать хорошо и без человека 😆
А вот при выборе решения прагматично архитектору часто приходится выбирать между "Клизмой и Сэндвичем" 😄
Надежное решение при этом очень дорогое. Дешевое решение очень хрупкое. Быстрое решение усложняет поддержку. А медленное решение никогда не одобрит бизнес.
В одной из моих прошлых компании у CEO была дилемма – как получить дешевую бизнес аналитику.
Ему предлагали серьезные решения и его пугала финальная цена. В итоге он решил нанять джуна без комплексов и страхов, который на коленках дал ему бизнес аналитику.
Джун понятия не имел как устроен мир дата архитектуры. Он покрыл весь код продукта генерацией событий, которые постоянно слались в вебморду для дашбордов.
Дашборды мимикрировали под реальные как могли, у них не было исторических данных а были только реактивные события.
Исходный код был загажен мусорными событиями, которые усложняли разработку продукта с каждым событием все сильнее и сильнее.
То есть полученное решение формально было как бы очень простым и дешевым а по факту было безумно дорогим (постоянное ухудшение развития продукта) и нефункциональным.
Джун понял, что что-то не то и решил это исправить, засунув ручки в продовую БД (соединить дашборды и продовую БД продукта 🤣). Тут и подключился я, отрубив доступы к проду, и предложил альтернативу.
Вместо "сэндвича" я предложил ему "клизму" – реплицировать продуктовые данные в DWH и отвязать аналитические запросы от прода. Ну и конечно удалить его мусорные события из кода.
Да, полноценная дата архитектура стоит достаточно дорого, требует время на реализацию и требует специальные скилы и найм, но она дает полный функционал и исключает экспоненциальное удорожание развития за счет загрязнения кода мусорными событиями.
Как часто вам приходится выбирать наименее худшее решение?
Если жить в мире паттернов и лучших практик, то всегда можно натянуть сову на глобус и не переживать за выбор альтернатив. Но есть плохие новости – AI это умеет делать хорошо и без человека 😆
А вот при выборе решения прагматично архитектору часто приходится выбирать между "Клизмой и Сэндвичем" 😄
Надежное решение при этом очень дорогое. Дешевое решение очень хрупкое. Быстрое решение усложняет поддержку. А медленное решение никогда не одобрит бизнес.
В одной из моих прошлых компании у CEO была дилемма – как получить дешевую бизнес аналитику.
Ему предлагали серьезные решения и его пугала финальная цена. В итоге он решил нанять джуна без комплексов и страхов, который на коленках дал ему бизнес аналитику.
Джун понятия не имел как устроен мир дата архитектуры. Он покрыл весь код продукта генерацией событий, которые постоянно слались в вебморду для дашбордов.
Дашборды мимикрировали под реальные как могли, у них не было исторических данных а были только реактивные события.
Исходный код был загажен мусорными событиями, которые усложняли разработку продукта с каждым событием все сильнее и сильнее.
То есть полученное решение формально было как бы очень простым и дешевым а по факту было безумно дорогим (постоянное ухудшение развития продукта) и нефункциональным.
Джун понял, что что-то не то и решил это исправить, засунув ручки в продовую БД (соединить дашборды и продовую БД продукта 🤣). Тут и подключился я, отрубив доступы к проду, и предложил альтернативу.
Вместо "сэндвича" я предложил ему "клизму" – реплицировать продуктовые данные в DWH и отвязать аналитические запросы от прода. Ну и конечно удалить его мусорные события из кода.
Да, полноценная дата архитектура стоит достаточно дорого, требует время на реализацию и требует специальные скилы и найм, но она дает полный функционал и исключает экспоненциальное удорожание развития за счет загрязнения кода мусорными событиями.
Как часто вам приходится выбирать наименее худшее решение?