Есть сильное подозрение, что это специфика не конкретного банка, а любой крупной организации. С ростом количества человек число связей растёт квадратично, коммуникационные "факапы" начинают превалировать над всем. Чего уж там банк - вы в чатик любого детсада\школы\соседей по району зайдите, посмотрите, как плёвые вопросы разрастаются в многочасовые ночные срачики. И это между людьми, которые друг другу ничего не должны. А когда надо сделать архитектуру, удовлетворяющую все стороны, да ещё в приемлемый бюджет, да ещё чтобы её поняли все одинаково - тут обиды, игнорирование стандартов и постоянные исключения неминуемы. И не важно, какая квалификация у участников, как они замотивированы. В этом отношении архитектору сильно сложнее, чем разработчику - деньги примерно те же, а общения (обычно неприятного) на порядок больше. Всё-таки ругаться с самим собой и своим кодом попроще, чем с парой сотен коллег :)
Хотелось бы услышать, как сделать перешардирование системы, да ещё и без её остановки. Есть, скажем, 20 СУБД-шардов, хотим добавить или убрать одну. Как?
Как обычно, всё зависит от конкретного учреждения и способности договариваться. Я работал, параллельно был в аспирантуре (за копейки), преподавал, пару раз получал намёки о необходимости заплатить нужным людям за успешную защиту. Ну и что? Договорился о небольшой академической нагрузке, платных "решал" послал нафиг, в итоге успешно защитился. Никто никогда мне не повышал зарплату за учёную степень, и это кажется логичным. А вот за полученные при подготовке и защите навыки платят, и неплохо. Так что я со своей стороны рекомендую учиться, защищаться - не ради бумажек, а "прокачки перса" для :)
По моему опыту (в том числе как человека, проводившего собеседования и принимавшего решение о найме разработчика) новомодные фреймворки интересуют в последнюю очередь "при прочих равных". А в первую интересует опыт. Даже если он на легаси и с плохим кодом - интервьюер ни в жизнь этот код не увидит, а технологии можно подучить в свободное время.
Не скажу за весь софт на свете, скажу за свой двадцатилетний опыт в "кровавом энтерпрайзе": в большинстве случаев программы тормозят только потому, что заказчик не обращает на это внимание и не выделяет время разработки. Или выделяет, но когда уже слишком поздно. В таких условиях даже профессиональные разработчики "кладут болт" на качество своего кода и выдают перлы вроде использования заведомо неподходящих типов данных ("ну и что, что GUID в разы больше int, память и диски быстрые") или обращения к СУБД в цикле отрисовки окна ("да, косячок, но сервер выдержит"). По мне, так это непрофессионализм и плохое оправдание, но читать всем морали - гиблое дело.
Переписывать все библиотеки, это скорее всего излишество. Свой бы код сделать не слишком уродливым. И тогда многие практически важные вещи смогут работать на гораздо более слабом железе. Но да, на это нужна воля заказчика, готовность платить и время. А пока подход "всё надо сделать срочно", полезные ископаемые являются идеальным решением.
Помнится, давным-давно просчитывали стратегии для разных роботов. Мы не профессионалы, но и рынок тогда был не такой насыщенный. Выходило, что в среднем робот (если он не скальпер), не зарабатывает почти ничего. А если скальпер, то проигрывает на комиссии или отключается брокером как спамер.
Бывает, обязанности перемешиваются - главное, чтобы они перемешивались за счёт помощи друг-другу, принятия части чужой работы, а не спихивания своей :)
На всякий случай скажу очевидное: не у всех всё так, как у вас. Например, а нашей организации я как архитектор решений делаю многое из того, что у вас делает аналитик: официальную документацию, просчёт нагрузок, определение протоколов, договорённости со смежными системами, сетевые конфигурации и т.д.. За системными аналитиками в основном важнейшая работа по детальному анализу структур данных и потоков (типа откуда какое конкретно поле взять, какое отдать самим). В теории бывают ещё архитекторы информационной системы, которые должны прорабатывать разделение внутри системы вроде определения границ ответственности микросервисов. На практике они есть не всегда, и их работу берут на себя разработчики, согласуясь с архитектором решений. Но чтобы скидывать это на аналитика - пока такого не видел.
"корпоративные словари и классификаторы это порочная практика" - чем это объяснялось? У меня отдельная головная боль как раз с внесением сделанного нами в корпоративные словари и классификаторы. Причём это требование не просто к архитектору - этим даже бизнесовое руководство напрягают.
"Пандемия коронавируса сделала рост спроса на электронные устройства, позволяющие дистанционно работать, развлекаться и общаться, взрывным" - интересно, у кого это до пандемии не было электронных устройств для работы и развлечений, а в пандемию прям срочно потребовались... Из моих знакомых только IT-шники пересели на удалёнку, но у них и так компьютеры были.
Есть сильное подозрение, что это специфика не конкретного банка, а любой крупной организации. С ростом количества человек число связей растёт квадратично, коммуникационные "факапы" начинают превалировать над всем. Чего уж там банк - вы в чатик любого детсада\школы\соседей по району зайдите, посмотрите, как плёвые вопросы разрастаются в многочасовые ночные срачики. И это между людьми, которые друг другу ничего не должны. А когда надо сделать архитектуру, удовлетворяющую все стороны, да ещё в приемлемый бюджет, да ещё чтобы её поняли все одинаково - тут обиды, игнорирование стандартов и постоянные исключения неминуемы. И не важно, какая квалификация у участников, как они замотивированы. В этом отношении архитектору сильно сложнее, чем разработчику - деньги примерно те же, а общения (обычно неприятного) на порядок больше. Всё-таки ругаться с самим собой и своим кодом попроще, чем с парой сотен коллег :)
Хотелось бы услышать, как сделать перешардирование системы, да ещё и без её остановки. Есть, скажем, 20 СУБД-шардов, хотим добавить или убрать одну. Как?
Как обычно, всё зависит от конкретного учреждения и способности договариваться. Я работал, параллельно был в аспирантуре (за копейки), преподавал, пару раз получал намёки о необходимости заплатить нужным людям за успешную защиту. Ну и что? Договорился о небольшой академической нагрузке, платных "решал" послал нафиг, в итоге успешно защитился. Никто никогда мне не повышал зарплату за учёную степень, и это кажется логичным. А вот за полученные при подготовке и защите навыки платят, и неплохо. Так что я со своей стороны рекомендую учиться, защищаться - не ради бумажек, а "прокачки перса" для :)
По моему опыту (в том числе как человека, проводившего собеседования и принимавшего решение о найме разработчика) новомодные фреймворки интересуют в последнюю очередь "при прочих равных". А в первую интересует опыт. Даже если он на легаси и с плохим кодом - интервьюер ни в жизнь этот код не увидит, а технологии можно подучить в свободное время.
Не скажу за весь софт на свете, скажу за свой двадцатилетний опыт в "кровавом энтерпрайзе": в большинстве случаев программы тормозят только потому, что заказчик не обращает на это внимание и не выделяет время разработки. Или выделяет, но когда уже слишком поздно. В таких условиях даже профессиональные разработчики "кладут болт" на качество своего кода и выдают перлы вроде использования заведомо неподходящих типов данных ("ну и что, что GUID в разы больше int, память и диски быстрые") или обращения к СУБД в цикле отрисовки окна ("да, косячок, но сервер выдержит"). По мне, так это непрофессионализм и плохое оправдание, но читать всем морали - гиблое дело.
Переписывать все библиотеки, это скорее всего излишество. Свой бы код сделать не слишком уродливым. И тогда многие практически важные вещи смогут работать на гораздо более слабом железе. Но да, на это нужна воля заказчика, готовность платить и время. А пока подход "всё надо сделать срочно", полезные ископаемые являются идеальным решением.
Помнится, давным-давно просчитывали стратегии для разных роботов. Мы не профессионалы, но и рынок тогда был не такой насыщенный. Выходило, что в среднем робот (если он не скальпер), не зарабатывает почти ничего. А если скальпер, то проигрывает на комиссии или отключается брокером как спамер.
Бывает, обязанности перемешиваются - главное, чтобы они перемешивались за счёт помощи друг-другу, принятия части чужой работы, а не спихивания своей :)
На всякий случай скажу очевидное: не у всех всё так, как у вас.
Например, а нашей организации я как архитектор решений делаю многое из того, что у вас делает аналитик: официальную документацию, просчёт нагрузок, определение протоколов, договорённости со смежными системами, сетевые конфигурации и т.д.. За системными аналитиками в основном важнейшая работа по детальному анализу структур данных и потоков (типа откуда какое конкретно поле взять, какое отдать самим). В теории бывают ещё архитекторы информационной системы, которые должны прорабатывать разделение внутри системы вроде определения границ ответственности микросервисов. На практике они есть не всегда, и их работу берут на себя разработчики, согласуясь с архитектором решений. Но чтобы скидывать это на аналитика - пока такого не видел.
"корпоративные словари и классификаторы это порочная практика" - чем это объяснялось? У меня отдельная головная боль как раз с внесением сделанного нами в корпоративные словари и классификаторы. Причём это требование не просто к архитектору - этим даже бизнесовое руководство напрягают.
"Пандемия коронавируса сделала рост спроса на электронные устройства, позволяющие дистанционно работать, развлекаться и общаться, взрывным" - интересно, у кого это до пандемии не было электронных устройств для работы и развлечений, а в пандемию прям срочно потребовались... Из моих знакомых только IT-шники пересели на удалёнку, но у них и так компьютеры были.