Восемь способов облегчить переход от устаревших систем к открытым

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

Бобу Дилану приписывают знаменитые слова: «Если всю жизнь не рождаешься, значит, всю свою жизнь умираешь». То же самое можно сказать о компаниях, которые рождаются и умирают в быстром темпе, в том числе и в ИТ-отрасли. Покупается новое оборудование, работает в течение какого-то времени (порой чуть меньше или чуть дольше, чем ожидалось), рано или поздно оно изнашивается и заменяется на другое. Программное обеспечение, конечно, не изнашивается так же, как аппаратное, но и оно устаревает по мере того, как появляются более скоростные и сложные системы. ИТ-руководители вынуждены всегда планировать свои будущие потребности на два-три года вперед. Ниже мы предлагаем советы по модернизации устаревших систем, составленные на базе отраслевой информации, которую предоставил Крейг Марбл, старший директор отдела модернизации устаревшего ПО в компании Astadia.

Несовместимость мейнфреймов с современными приложениями заставляет принимать нелегкие решения

Мейнфреймам требуется особое внимание

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

Приготовьтесь к тому, что при замене мейнфрейма вас будут подстерегать большие трудности

Замена мейнфрейма — масштабный проект

Любое решение по замене мейнфрейма может натолкнуться на несколько препятствий:

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

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

3. Соображения экономии: стоимость написания новых приложений или покупки лицензий часто превышает непосредственные затраты на поддержание существующей системной архитектуры.

На переменах настаивают и внутри, и снаружи компании

Группы лиц, у которых особый интерес к проекту, всегда являются источником проблем

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

Переход на новую систему затронет сотрудников на всех уровнях организации

Поиск консенсуса — важный фактор при любой перестройке

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

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

Открытые системы работают быстрее и их проще развивать

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

Составьте список правил для трансформации и автоматизируйте как можно больше операций

Важно, чтобы трансформация была автоматической и основанной на правилах

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

Обеспечить целостность данных при переходе на новую систему будет сложно, но это крайне важно сделать

Первостепенная задача — поддержать целостность данных во время замены системы

Перенести одно или несколько приложений с мейнфрейма на открытые системы — это только полдела. Нужно еще преобразовать старые данные и перенести на новую платформу, проследив при этом, чтобы они остались в целости и сохранности. Это вдвойне сложнее, если база данных, установленная на мейнфрейме, не имеет аналогов на платформе назначения или если миграция данных подразумевает смену одного типа СУБД на другой, например, переход от иерархической к реляционной архитектуре. Опять-таки, нужно подходить к этому процессу с набором правил и, по возможности, автоматизировать его — таким образом удастся добиться хорошей скорости и точности.

Не нужно недооценивать время и усилия, затрачиваемые на тщательное тестирование

Выработайте обстоятельные процессы тестирования и управления

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

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

Резюме

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