Что делать с унаследованными системами, в первую очередь приложениями? Этот вопрос становится все более актуальным, по мере того как предприятия отсчитывают год за годом своей истории — а таких в России становится все больше. Со временем затраты на поддержку и развитие множества унаследованных систем растут. По данным исследования Accenture, две трети опрошенных британских ИТ-руководителей ожидают, что на поддержку унаследованных систем в ближайшие годы будет уходить до 30% ИТ-бюджета. Несмотря на внушительные расходы, ИТ-руководители демонстрируют относительно лояльное, терпеливое отношение к унаследованным приложениям: лишь 45% опрошенных ИТ-руководителей уверены, что имеющиеся унаследованные системы нужно модернизировать или заменять, и только каждый пятый заявил, что в его организации разработан детальный план, предусматривающий вывод унаследованных решений из эксплуатации.

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

Гораздо реже встречаются унаследованные приложения, содержащие уникальные наработки компании или организации — ноу-хау как из сферы технологий, так и из области ведения бизнеса в данном сегменте рынка. Такие приложения нередко обеспечивают предприятию конкурентное преимущество и потому, конечно же, должны сохраняться, оберегаться, поддерживаться и развиваться. По мнению Евгения Чаркина, CIO ОАО «Северсталь», унаследованные приложения стоит сохранять только в этом случае — если они поддерживают уникальные бизнес-процессы и помогают компании удерживать лидерство. «Северсталь», по словам Чаркина, взяла курс на вывод унаследованных приложений из эксплуатации.

Дает ли использование устаревших приложений какие-либо преимущества? К ответу на этот вопрос Алексей Широких, вице-президент и главный исполнительный директор по ИТ финансовой корпорации «Уралсиб», рекомендует подходить взвешенно и аккуратно: прежде всего надо понять, насколько данное приложение интегрировано в бизнес-процесс, затем оценить общую стоимость владения данным приложением (включая трудозатраты на поддержку), после чего, опираясь на результаты этого анализа, можно принимать решение о продолжении эксплуатации данного приложения либо об изменении бизнес-процесса и замене приложения на более современное и обеспечиваемое хорошей поддержкой. «Системный анализ здесь имеет первостепенное значение, — отмечает Широких. — Вполне возможно, что после изучения результатов такого анализа данное приложение займет достойное место в новой архитектуре предприятия».

Можно ли создать гибкую ИТ-инфраструктуру, не избавляясь от устаревших, унаследованных приложений? Да, вполне возможно, считает Широких. Основной принцип, которому надо при этом следовать, — «не навреди», именно поэтому столь важны анализ и определение ценности приложения для бизнеса: «Существуют различные методики и шаблоны (например, шаблон проектирования «Фасад», позволяющий инкапсулировать унаследованный программный модуль), которые позволяют «обернуть» приложения и представить их через интерфейсы, к которым могут обращаться современные приложения». Чаркин также считает, что создать гибкую инфраструктуру можно, но это потребует очень серьезных усилий, поэтому прежде чем браться за такой проект, нужно все тщательно проанализировать и оценить.

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

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