На первый взгляд, архитектура мейнфрейма кажется относительно простой: центральный компьютер обрабатывает данные через подсистему ввода-вывода и сохраняет свои вычисления в памяти. На другом конце мейнфрейма находятся принтеры и терминалы, взаимодействующие с мейнфреймом через протоколы.
Однако при всей кажущейся простоте архитектура мейнфрейма может быть чрезвычайно сложной. Мейнфреймы обрабатывают тысячи транзакций в секунду и требуют наличия обширной инфраструктуры для размещения и обслуживания. Сотням или, возможно, тысячам терминалов (например, банковская сеть банкоматов) нужна схема маршрутизации сообщений, которая быстро определяет приоритеты и направляет запросы о транзакциях, пишет InformationWeek.
Баланс между затратами и выгодой
Крупные корпорации по-прежнему используют мейнфреймы, поскольку они обеспечивают мощные интеллектуальные ресурсы предприятия и поддерживают многие приложения с высокой пропускной способностью, такие как мобильный банк, системы онлайн-бронирования и телекоммуникации. Мейнфреймы также более безопасны, надежны и масштабируемы, чем распределенные сети. К сожалению, стоимость обслуживания мейнфрейма бывает очень высокой. Для этого есть 3 основные причины:
Годовая оплата лицензии на ПО может стать реальным финансовым бременем, а отсутствие гибкого лицензирования создает проблемы совместимости для организаций, которым требуются непатентованные надстройки и обновления. Обходные пути часто вынуждают программировать дорогостоящие приложения, чтобы приспособиться к новым требованиям.
Обслуживание дорогое, потому что мейнфрейм часто является связующим звеном крупномасштабной инфраструктуры, которой необходимы специализированный уход и определенные внешние условия. Старые мейнфреймы часто размещаются в шкафах или комнатах, где строго поддерживаются требуемые температура и влажность.
Сложность аппаратного и программного обеспечений также вынуждает нанимать дорогостоящих технических специалистов и программистов на протяжении всей жизни системы, что усугубляется потенциальной нехваткой квалифицированного персонала для внедрения решений и поддержки этих мощных систем.
Учитывая задачу ИТ-отделов «делать больше с меньшими затратами» и стратегический долг стать более ориентированными на клиента и гибкими благодаря цифровым преобразованиям, ИТ-директоров заставляют переходить с устаревших приложений в открытые системы и облако. Превращение десятилетних привычек покупателей, их предпочтений, моделей приобретения и другой информации в доступные для маркетинга, продажи, производства, планирования и обслуживания клиентов может оказать глубокое влияние на лояльность потребителей. Однако попасть «в струю» — сложная задача.
Открытые системы и облачные платформы
Открытые системы соответствуют хорошо зарекомендовавшим себя стандартам и избегают проблем, присущих мейнфреймам. Компании могут быстро развивать свои возможности с помощью дополнительных технологий, оставляя продолжительность и стоимость разработки другой стороне. В большинстве случаев от организаций требуется только приобрести, установить и периодически обновлять дополнение. Помимо нескольких задач по конфигурации, программирования почти не требуется. Все эти факторы могут привести к значительной экономии средств и гибкой реакции на смену парадигмы.
Переход на открытые системы также упрощает перемещение в облако, что еще больше повышает ценность этих приложений и баз данных. Общий подход к модернизации прежних версий часто начинается с перехода на открытые системы, размещенные локально, и как только переход стабилизируется, осуществляется перемещение в облако.
Однако переход к открытой системе имеет свои особенности. Лицензии на приложения, например, дороже для мейнфреймов, но их часто проще администрировать. Исходя из этих условий, покупка и установка нескольких сторонних лицензий для каждого члена организации может показаться обескураживающей.
Переход от мэйнфреймов к открытым системам и облаку требует тщательного планирования. Хотя существует потенциал снижения издержек и обеспечения совместимости, его реализация зависит от принятия основанных на фактах, рациональных решений. Первый шаг — это всестороннее обнаружение и анализ каждого аспекта старого портфолио, включая среды, приложения, языки, базы данных, пакеты программ, утилиты, тестовые скрипты, пользователей. Затем нужно сосредоточиться на целях, ценности и требованиях каждого приложения, чтобы оценить его согласно важности для бизнеса и тому, насколько оно соответствует вашей стратегической технической архитектуре. После оценки вы легко сможете построить график для каждого приложения, обеспечив визуальное представление о его состоянии, чтобы помочь в разработке плана решения своей задачи.
С помощью этой информации вы сможете определить, какие приложения стоит модернизировать, какие — исключить, а также какие подходы к модернизации моделей помогут выбрать правильный путь для каждого приложения. Анализ должен включать оценку стоимости, рисков и влияния каждой альтернативы, пока не будет определен правильный план действий.