Если требуется провести модернизацию построенной на базе мэйнфреймов инфраструктуры, на которой в вашей компании работают унаследованные (legacy) приложения, а руководство компании сомневается в необходимости такой модернизации, то следующие аргументы помогут убедить ваше начальство.

Многие крупные компании уже несколько десятилетий используют мэйнфреймы для обслуживания приложений в унаследованных системах. Большинство систем уровня предприятия сегодня по-прежнему работают на мэйнфреймах, а приложения, написанные на COBOL (основной язык программирования мэйнфреймов), продолжают обслуживать основной объем корпоративных транзакций. В некоторых вертикальных рынках 50 – 60 процентов главных приложений все еще работают на мэйнфреймах.

Однако эти большие компьютеры необходимо каким-то образом модернизировать чтобы компания могла выдержать конкурентную борьбу и/или быстро реагировала на угрозы и новые возможности рынка.

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

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

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

«Всё работает, поэтому не надо ничего менять»

Бездействие – это обычно самый легкий выход в любой ситуации, в том числе и при модернизации унаследованных систем. Ваш начальник может заявить, что «зачем что-то чинить если ничего не сломалось» и он будет прав в том случае, если сейчас от системы не требуется новый функционал.

Однако, в ответ на такие возражения важно подчеркнуть, что чем больше компания будет откладывать модернизацию унаследованных систем, тем больше будут риски из-за их постепенного устаревания, особенно если конкуренты уже провели модернизацию и уже применяют новейшие технологии.

Кроме того, на мэйнфреймах хранятся важные для бизнеса данные, доступ к которым будет трудно обеспечить для новых средств бизнес-аналитики с использованием Больших Данных, которые планирует внедрить ваша компания. В результате эти новые инструменты будут выдавать некорректные или вводящие в заблуждение результаты, а это означает, что инвестиции на их приобретение не принесут никакой пользы для бизнеса.

Другой риск связан с тем, что для многих пользователей нужно обеспечить поддержку доступа с мобильных устройств, а на устаревших системах, как правило, трудно внедрить новые пользовательские интерфейсы или более гибкое форматирование отображаемой информации.

Наконец, можно в качестве примера напомнить руководителю о других игроках рынка, которые уже перешли на использование архитектуры облаков. Относительно дешевые технологии серверов x86 и виртуализация кардинально изменили архитектуру и структуру цен корпоративных дата-центров. Стоит ли изолировать приложения и их данные, по-прежнему размещая их на мэйнфреймах? Зачем платить огромные деньги за устаревшее оборудование с закрытой архитектурой, если можно использовать намного более дешевые серверы стандартной архитектуры? Зачем поддерживать нестандартные хранилища данных, ориентированные на работу с файлами, когда есть альтернативы на базе SQL?

Чтобы убедить руководство, что сохранение статус-кво – это тупиковый путь, попытайтесь обратить его внимание на следующие важные моменты:

• Компания расходует большие деньги на поддержание работы устаревших мэйнфреймов, которые можно было бы с большей пользой потратить на внедрение инноваций и получение конкурентного преимущества
• Многие приложения, которые сейчас работают на мэйнфреймах, написаны еще в прошлом столетии, и разработавшие их компании давно ушли с рынка
• Совокупная стоимость владения (TCO) мэйнфреймов, используемых в вашей компании, включая расходы на закупки, инсталляцию, охлаждение, питание и поддержку
• Существующая инфраструктура не может обеспечить работу новых динамичных платформ, например, мобильных устройств
• Данные, хранящиеся на мэйнфреймах, недоступны для новых современных приложений бизнес-аналитики
• Огромный объем документации, необходимой для работы с мэйнфреймами
• В ИТ-отделе скоро не останется специалистов, которые хорошо знают технологии мэйнфреймов и могут обслуживать текущую инфраструктуру в случае сбоя

«А что если просто добавить мощности нашему мэйнфрейму?»

Если унаследованной системе не хватает мощности, то можно расширить конфигурацию ее оборудования либо заменить на новый более мощный мэйнфрейм. Такой подход увеличит производительность и емкость системы, но вместе с тем приведет к росту расходов на обслуживание и лицензирование.

В результате ваша компания не сможет устранить главные проблемы мейнфреймов, а именно отсутствие гибкости, рост расходов на обслуживание, дефицит специалистов по обслуживанию мэйнфреймов и т.д.

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

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

Помимо перечисленных ключевых моментов нужно быть готовым назвать цифры, которые дают представление:

• О числе патчей, модификаций и обновлений, которые нужно установить на мэйнфрейм после расширения его конфигурации
• О влиянии этих патчей на работу системы (усложнение системы, отсутствие прозрачности)
• О дополнительных расходах из-за патчей и продолжения обслуживания унаследованных систем

«А разве нельзя просто переписать исходники?»

Разумеется, можно и это будет самый агрессивный вариант модернизации. Можно просто переписать исходный код приложений и перестроить архитектуру базы данных и уровней приложений.

Однако на практике полное переписывание исходников связано с большим риском. Этот вариант модернизации приводит к полной переработки логики бизнес-процессов, что увеличивает вероятность ошибки, поэтому необходимо провести тщательное тестирование.

Кроме того, потребуется создать таблицу преобразования для переноса хранилищ данных в среду SQL и изоляции функционала работы с данными от уровня хранения этих данных.

Будьте готовы обсудить следующие моменты:

• С чем по-вашему связаны основные расходы на мэйнфреймы — с языком программирования, на котором написан исходный код, или с архитектурой системы. Что обеспечит самую большую и быструю окупаемость инвестиций?
• Риски изменения логики бизнес-процессов
• Другие приложения и хранилища данных, на которых может отразиться переписывание исходников
• Сколько времени займет проект, включая тестирование функциональности, тестирование пользователями и параллельные операции
• Ресурсы (включая персонал), необходимый для проекта полного переписывания исходного кода

Эти три сценария обсуждения помогут вам парировать поверхностные представления о возможности модернизации мэйнфрейма. Но что же предложить взамен?

Для ИТ-специалистов, которые готовы к модернизации IT архитектуры своей компании, но хотят тщательно контролировать риски, затраты времени и денег, есть другая опция, более привлекательная, чем полное переписывание исходников, а именно миграция приложений на новую платформу (rehosting).

Преимущества миграции

При миграции старые приложения мэйнфреймов без изменений кода переносятся в современную открытую среду, например, в многоуровневую среду x86 на базе SQL или в облако. При этом сами приложения могут быть написаны на COBOL, PL/I или других языках, а мэйнфреймы могут быть от IBM, Fujitsu или других вендоров.

Для многих компаний миграция будет очень эффективным по затратам вариантом обновления архитектуры мэйнфреймов. Если миграция выполняется грамотно, то риски и затраты будут намного меньше, чем при переписывании исходников.

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

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

Плавный переход на новую платформу

Грамотно выполненная миграция уменьшает риски за счет использования стандартных ОС, серверов x86, баз данных SQL и облачных инфраструктур. Она улучшает интеграцию и безопасность, сокращая при этом расходы.

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