Comments 18
«Поскольку бизнес компании — продажа товаров и услуги через Интернет, а не производство ПО, то айтишники в ней — обслуга, и, полагаю, что они составляют не более 5% от общей численности.»
aws.amazon.com, да и множество других сервисов, не привязанных к этой платформе. Конечно, большинство сотрудников это все же работа со складами и прочим, но продажа услуг через интернет требует разработки и поддержания того, что ты пытаешься продать через интернет(подразумеваю их сервисы, а не физические товары).
aws.amazon.com, да и множество других сервисов, не привязанных к этой платформе. Конечно, большинство сотрудников это все же работа со складами и прочим, но продажа услуг через интернет требует разработки и поддержания того, что ты пытаешься продать через интернет(подразумеваю их сервисы, а не физические товары).
SAP HANAВот кстати вопрос, почему сберу не перейти на SAP? Такие компании, как The National Bank of Canada, Royal Bank of Scotland, Deutsche Bank вполне хорошо себя чувствуют.
Вполне себе надежная система, уж для банка функционала с головой хватит, ничего нового и придумывать не нужно.
Нет же, нужно угробить еще n млрд рублей на разработку системы, которая все равно окажется неактуальной
потому что кастомизация SAP потребуется и потребует она столько бабла, что становится грустно всем. А еще она потребует специалистов по САПу в количестве, которого на рынке просто нет. Возможно поэтому решили написать своё.
Ну и есть подозрение, что санкционные дела играют свою роль.
Да ладно, специалистов немало. А если уж они решили с иностранными компаниями работать, то уж точно найдут подходящую конторку
И уж точно кастомизация готового продукта потребует меньше, чем создание нового, даже если речь о кастомизации SAP ERP
И уж точно кастомизация готового продукта потребует меньше, чем создание нового, даже если речь о кастомизации SAP ERP
Что, вот прям так на рынке есть пара тысяч квалифицированных саперов? У них и так зарплаты поднебесные, а если ВНЕЗАПНО начать нанимать людей тысячами, то рынок труда взорвётся. ФОТ на эту ораву нужен будет безумный. А программистов проще нанимать, всё-таки.
Ну и далеко не факт, что человеко-часов на кастомизацию сапа под нужды сбера требуется меньше, чем на разработку с нуля своей платформы.
Ну и далеко не факт, что человеко-часов на кастомизацию сапа под нужды сбера требуется меньше, чем на разработку с нуля своей платформы.
Зарплаты у саперов вполне себе сравнимы с другими айтишниками, что в России, что в Европе.
Насчет тысяч, думаю вы погорячились, а даже если и нет — сап как-то используется очень большим числом крупных и очень крупных компаний по всему миру, и как-то внедрение ERP в каждой из них не вызвало рынка труда
Насчет кастомизации — на то она и кастомизация. Но проще, имхо, накрутить вокруг саповского FI модуля (который заведомо работает, и работает хорошо и стабильно) свои хотелки, чем строить систему с нуля, при этом ставя под угрозу основные процессы, ошибка в которых может произойти с той же вероятностью, что и в менее критичном месте.
Все-таки сап существует уже сорок лет, и пока не потерял актуальности, даже наоборот — активно внедряет модные фичи, вроде In-Memory Database и облачных технологий.
Стоит учитывать не только стоимость внедрения/разработки, но и стоимость дальнейшей поддержки. Если первая цифра, может, и сопоставима, то вторая, в случае использования готового и обкатанного решения (пусть и допиленного), всегда будет меньше, чем поддержка самописного
Насчет санкций — множество крупных компаний в России, вроде Домодедово или Лукойл, работают на нем и в ус не дуют. Как по мне, так решение Грефа — это желание показать, что Сбербанк впереди планеты всей, что, мягко говоря, не совсем так
Насчет тысяч, думаю вы погорячились, а даже если и нет — сап как-то используется очень большим числом крупных и очень крупных компаний по всему миру, и как-то внедрение ERP в каждой из них не вызвало рынка труда
Насчет кастомизации — на то она и кастомизация. Но проще, имхо, накрутить вокруг саповского FI модуля (который заведомо работает, и работает хорошо и стабильно) свои хотелки, чем строить систему с нуля, при этом ставя под угрозу основные процессы, ошибка в которых может произойти с той же вероятностью, что и в менее критичном месте.
Все-таки сап существует уже сорок лет, и пока не потерял актуальности, даже наоборот — активно внедряет модные фичи, вроде In-Memory Database и облачных технологий.
Стоит учитывать не только стоимость внедрения/разработки, но и стоимость дальнейшей поддержки. Если первая цифра, может, и сопоставима, то вторая, в случае использования готового и обкатанного решения (пусть и допиленного), всегда будет меньше, чем поддержка самописного
Насчет санкций — множество крупных компаний в России, вроде Домодедово или Лукойл, работают на нем и в ус не дуют. Как по мне, так решение Грефа — это желание показать, что Сбербанк впереди планеты всей, что, мягко говоря, не совсем так
Компании эти в основном буржуйские — или, в крайнем случае, с буржуйскими владельцами. При нашей скорости смены законодательства и других требований (тем более у банков) у саперов работы будет, мягко говоря, очень много. Возможно, под отчётность придётся дополнительно использовать какие-либо продукты; знаю компанию, где подобным образом используются совместно SAP и продукт 1С.
Потому что банковское приложение должно быть одобрено нашим ЦентроБанком, на данный момент у нас четыре крупных игрока (все отечественные) и наколенные приложения самих банков.
И так как конкуренции особо нет, то и проблемы те же, что и у обычных приложений были в середине 90-х, да что говорить, у самого крупного игрока нет поддержки Юникода :(
И так как конкуренции особо нет, то и проблемы те же, что и у обычных приложений были в середине 90-х, да что говорить, у самого крупного игрока нет поддержки Юникода :(
UFO just landed and posted this here
Amazon еще и крупный провайдер облачных сервисов.
Правда, у него сервисы разделены на регионы и обновления в них производятся независимо — новые фичи в одних появляются раньше, в других позже. Возможно обновления в каждом посчитаны независимо и просуммированы.
Правда, у него сервисы разделены на регионы и обновления в них производятся независимо — новые фичи в одних появляются раньше, в других позже. Возможно обновления в каждом посчитаны независимо и просуммированы.
Выступление Грефа действительно напоминает явление которое происходило в некоторых компаниях, когда начиналось повсеместное внедрение Agile (ранее RUP) с такими ожиданиями как будто это серебренная пуля. То что описаны выше (про три революции) выглядит еще более тревожным, много IT-компаний не смогли такое пережить (банку может быть проще), даже некоторый ретейл вроде Топ-книги насколько я понял затонул из-за проектов автоматизации бизнеса.
Я бы сказал что это могло иметь смысл с какой-нибудь другой позиции. В последнее время говорят что финансовые технологичные стартапы могут потеснить банки в каких-то местах. Если новая платформа развивается под какую-то такую идею о которой мы не знаем, то это могло иметь смысл. Может быть еще что-то из области развития Яндекс-денег, которые вроде бы принадлежат сбербанку.
Если же какой-то то хитрой идеи нет, то переписать все на новой БД и с помощью Agile выглядит как опасная затея.
Я бы сказал что это могло иметь смысл с какой-нибудь другой позиции. В последнее время говорят что финансовые технологичные стартапы могут потеснить банки в каких-то местах. Если новая платформа развивается под какую-то такую идею о которой мы не знаем, то это могло иметь смысл. Может быть еще что-то из области развития Яндекс-денег, которые вроде бы принадлежат сбербанку.
Если же какой-то то хитрой идеи нет, то переписать все на новой БД и с помощью Agile выглядит как опасная затея.
Как связаны количество изменений и Time to market?
Ответ: Совсем никак. Потому, что Time to market определяется архитектурой системы и производственной технологией. Чем больше размазана бизнес-логика, чем больше связанность между модулями, тем больше времени потребуется на анализ, проектирование, разработку и тестирование. И в первую очередь — регрессионное. Чем более критичен и ответственен бизнес, тем тяжеловеснее технологические процессы и жестче регламенты.
Так речь как раз о том, что в некоторых крупных компаниях удается создать такое тестирование (например на основе статистики поведения сотен миллионов пользователей), что стало возможно выкладывать изменения раз в минуту или раз в секунду. Такая скорость тестирования напрямую зависит от чувствительности поведенческих метрик, которая в свою очередь зависит от числа пользователей. Чем больше пользователей, тем более чувствительны метрики. Чем больше разрешающая способность метрик, тем большая скорость тестирования выкаток в бой. Тем больше скорость тестирования изменений, тем выше общее качество сервиса. Чем выше качество сервиса, тем больше пользователей. Чем больше пользователей у вас, тем меньше пользователей у других.
Система не работает, если у вас 10 тыс программистов и 10 пользователей.
Ответ: Совсем никак. Потому, что Time to market определяется архитектурой системы и производственной технологией. Чем больше размазана бизнес-логика, чем больше связанность между модулями, тем больше времени потребуется на анализ, проектирование, разработку и тестирование. И в первую очередь — регрессионное. Чем более критичен и ответственен бизнес, тем тяжеловеснее технологические процессы и жестче регламенты.
Так речь как раз о том, что в некоторых крупных компаниях удается создать такое тестирование (например на основе статистики поведения сотен миллионов пользователей), что стало возможно выкладывать изменения раз в минуту или раз в секунду. Такая скорость тестирования напрямую зависит от чувствительности поведенческих метрик, которая в свою очередь зависит от числа пользователей. Чем больше пользователей, тем более чувствительны метрики. Чем больше разрешающая способность метрик, тем большая скорость тестирования выкаток в бой. Тем больше скорость тестирования изменений, тем выше общее качество сервиса. Чем выше качество сервиса, тем больше пользователей. Чем больше пользователей у вас, тем меньше пользователей у других.
Система не работает, если у вас 10 тыс программистов и 10 пользователей.
Релизить можно и по 10 000 раз в день. Но если процесс таков, что от регистрации тикета до его попадания на продакшн через все согласования, проектирование и реализацию изменений уходит три месяца, то Time to market будет >= 3 месяца, даже при полностью автоматизированном тестировании. Имел честь руководить разработкой продукта (всего-то 2 500 KSLOC, включая автотесты). Так вот сборка и прогон всех автотетов продолжались больше суток.
если всё повестить на метрики и выкатывать сначала на небольшую аудиторию, потом, если всё хорошо, чуть больше, потом на половину, потом на 100 процентов, то ТТТ будет достаточно быстр, неделю например, можно попробовать разрешить делать правки в коде любому из 10 тыс программистов, плохая правка должна откатиться сама.
ну и 3 месяца — это еще мало. в больших компаниях могут по факту и год выкатывать.
Конечно Time to market важный параметр, но всё же не столь критичный, как максимальное число одновременно тестируемых изменений, которое обычно является самым узким местом.
ну и 3 месяца — это еще мало. в больших компаниях могут по факту и год выкатывать.
Конечно Time to market важный параметр, но всё же не столь критичный, как максимальное число одновременно тестируемых изменений, которое обычно является самым узким местом.
Вопрос: А что конкретно сравнивали по производительности In-Memory Data Fabric с Oracle RDBMS и IBM DB2 или, все-таки, с сопоставимыми решениями Oracle TimesTen и SolidDB, приобретенной IBM.
Вы немного перепутали класс «сопоставимых решений». В случае Oracle это Coherence (часть пакета Fusion Middleware), в случае IBM — WebSphere eXtreme Scale (часть пакета WebSphere). То, что вы назвали, это монолитные (т. е. работающие на одном сервере) СУБД, хоть и in-memory.
Гипотеза: Очень надеюсь, что второе, а также, что не забыли еще одного из лидеров среди продуктов этого класса SAP HANA.
Не забыли, но HANA — лидер главным образом по PR. Попробуйте назвать хотя бы один не SAP'овский продукт, использующий HANA. Ну, или назовите сходу компанию, где ERP установлен на кластере, а не на одноузловую БД. Продукт, безусловно, интересный, но нюансов слишком много.
Согласен в целом с позицией Сергея. Очень важно, чтобы для такой ответственной системы была хорошо проработана архитектура, как база, на которой можно было развивать ответственную систему Сбера долго и без подарков. Известны в нашей российской практике случаи, когда функциональное развитие банковских систем становилось невозможным из-за дефектов архитектуры. Какой уж тут Agile. Думаю, что важно и уметь оценивать нефункциональные характеристики системы. И очень важно, какова система не со стороны программистов и разработчиков, а со стороны эксплуатационников. Это ведь позиция, ограничивающая развертывание новых возможностей. Я говорю о том, что система ответственная должна быть отчуждаемой от разработчика.
`
`
Sign up to leave a comment.
ИМХО о выступлении Грефа на Гайдаровском форуме и об опасности революций