Цена обновлений: всегда ли оно того стоит?

В конце 50-х годов прошлого века мир переживал технологический и экономический подъём. Именно тогда появились реактивные пассажирские авиалайнеры, в космос полетели первые спутники и началось массовое использование транзисторов. Что, в свою очередь, привело к удешевлению компьютеров и уменьшению их габаритов. Как следствие, даже предприятия средних размеров могли позволить себе установить компьютерную систему, что ещё совсем недавно было доступно лишь военным или богатейшим госучереждениям.

Не смотря на то, что компьютерное железо дешевело, процесс внедрения новых технологий осложнялся увеличивающейся стоимостью программного обеспечения. И дело было не только в возрастающей сложности программ. Компьютеры тех лет были очень разными по своему устройству. Они использовали различные системы команд и были практически несовместимы между собой. Исследование 1959 года показало, что перенос программы на новую платформу обходится примерно в 75% от стоимости первоначальной разработки.

Чтобы упростить написание и переносимость программ между компьютерами, были придуманы языки программирования третьего поколения. Они должны были не зависеть от конкретной платформы и по возможности быть похожими на человеческий язык, а не на машинный код. Так появились Фортран, Алгол, Кобол и некоторые другие языки. Программы написанные на этих языках используются до сих пор. И не только в музеях, как могут подумать некоторые.

На прошлой неделе губернатор штата Нью Джерси объявил о том, что ИТ-департамент штата ищет программистов знающих Кобол, чтобы доработать систему обработки заявок на пособие по безработице. Изменения потребовались в связи с обработкой сотен тысяч анкет, поданных за очень короткий отрезок времени.

Использование системы, которой, по словам руководства штата, больше сорока лет, подверглось немалой критике и даже насмешкам. Мол, вот, доэкономились, позор, распильщики и так далее. В общем, началось бурление. Хотя вполне возможно, что те же самые люди в другой вкладке браузера пишут гневные комментарии в адрес хипстеров, которые понаписали тормозящих и жадных до памяти приложений. Но речь не об этом.

Вопрос действительно интересный: стоит ли обновлять систему, если, судя по всему, она работала без сбоев более сорока лет? То, что случилось — это в чистом виде форс-мажорная ситуация. Можно ли было представить во времена Рейгана, что в 2020 году нужно будет за неделю обработать свыше трехсот тысяч заявок поданных через ещё несуществующий тогда интернет?

У программного обеспечения есть свои жизненные циклы, но определяются они не только тем, какие новинки появились на рынке, но и экономическими параметрами. И так ли будет плохо, если после некоторой доработки эта система отработает ещё десяток-другой лет?

Умение правильно рассчитывать TCO (Total Cost of Ownership — общую стоимость владения) является важнейшим для ИТ-отделов, и анализ всех факторов не так прост, как может показаться на первый взгляд. Ведь переписывание системы это не только дополнительные прямые расходы. Это ещё и многочисленные риски. Простои, потеря и утечки данных не редкость для подобных миграций. К примеру, один из крупнейших банков Австралии решил заменить ПО написанное на Коболе, на современную систему SAP. Миграция заняла не один год и обошлась примерно в 750 миллионов долларов. Но это не уберегло его от серии сбоев, некоторые из которых полностью останавливали работу банка, лишая клиентов возможности совершать платежи. Что, в свою очередь, привело к оттоку клиентов.

Понятно, что современный банкинг не оставляет выбора и обновление платформы является необходимым условием сохранения конкурентоспособности. Но этот пример хорошо иллюстрирует то, насколько тщательно нужно рассчитывать риски при планировании таких переходов. Клиенту будет все равно почему не работает ваш сервис — потому ли что у вас слишком старое ПО, или наоборот, слишком новое.