Унаследованная система

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

В сфере информационных технологий унаследованными системами называют устаревшие методы, технологии, вычислительные системы или приложения, которые используются до сих пор. Часто слово «унаследованный» подразумевает, что система задала стандарты для всех последующих. Также оно может означать, что система устарела и нуждается в замене[1].

Общие сведения[править | править код]

В сфере информационных технологий данный термин впервые возник в 1970-е годы. К 1980-м его начали использовать, чтобы разделить системы, которые только вводят в эксплуатацию, и системы, которые активно используются. Этот термин часто применяется, когда речь идёт о переходе со старой системы на новую. К примеру, при переносе данных.

Хотя термин и подразумевает, что некоторые инженеры считают систему устаревшей, её могут долго не выводить из эксплуатации. Решение не отказываться от старой системы может быть принято по разным причинам: если она полностью удовлетворяет потребности пользователя, из-за проблем с инвестициями, из-за зависимости от поставщиков, неизбежных проблем, с которыми столкнутся пользователи при изменениях и т. д. Обратная совместимость (возможность новых систем поддерживать устаревшие форматы файлов и кодировки символов) — одно из основных требований, которое предъявляют к разработчикам программного обеспечения.

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

Организации могут быть вынуждены использовать унаследованные системы по следующим причинам:

  • Система работает удовлетворительно, и пользователь не видит смысла в изменениях.
  • Цена редизайна или замены будет слишком высокой, так как система огромная, обладает монолитной архитектурой или слишком сложная.
  • Обучение тому, как пользоваться новым программным обеспечением, может стоить слишком дорого по сравнению с выгодой от перехода на него (выгоды может и вовсе не быть).
  • Система должна работать постоянно, поэтому её нельзя отключить, а стоимость создания новой системы с подобной доступностью слишком высока. В качестве примера можно привести системы управления воздушным движением, энергопотреблением, банковскими счетами, атомные, оборонные и используемые в здравоохранении.
  • Принципы работы системы не до конца понятны. Такая ситуация может сложиться потому, что разработчики программного обеспечения покинули организацию, а техническая документация была полностью или частично утрачена.
  • Пользователь считает, что систему можно легко заменить при необходимости.
  • У нового программного обеспечения есть нежелательные функции. Например, слежение за пользовательской активностью или автоматические обновления, из-за которых возникают уязвимости. Проблема становится особенно актуальной, если подобные функции невозможно отключить.

Проблемы, связанные с унаследованными системами[править | править код]

Разработчики программного обеспечения считают унаследованные системы потенциально проблемными по ряду причин[2].

  • Если унаследованная система работает на устаревшем оборудовании, то стоимость её поддержки может значительно превышать стоимость замены программного обеспечения и оборудования, если только не прибегнуть к использованию эмуляции или обратной совместимости, что позволит программному обеспечению работать на новом оборудовании[3].
  • Унаследованные системы бывает достаточно сложно поддерживать, улучшать и расширять из-за нехватки понимания системы. Эксперты, которые знали, как с ней работать, вышли на пенсию или позабыли всё, что знали, а те, кто пришёл им на смену, так и не сумели во всём разобраться. Ситуация может усложнить нехватка или полное отсутствие документации[4].
  • В унаследованных системах могут быть уязвимости, связанные со старыми операционными системами и программным обеспечением, которые не были устранены обновлениями безопасности. Кроме того, проблемы с безопасностью могут быть вызваны особенностями производства. Из-за этого унаследованные системы могут быть скомпрометированы злоумышленниками[5].
  • Интеграция с новыми системами может быть проблематична потому, что новое программное обеспечение использует совершенно другие технологии. Случаи интеграции технологий встречаются довольно часто, однако интеграция старых и новых технологий между собой — довольно сложный процесс. Спрос на разработку технологии для интеграции может оказаться недостаточно высок. «Склеивающий» код в этих случаях чаще всего пишется вендорами или энтузиастами определённых унаследованных технологий.
  • Бюджетные ограничения часто приводят к тому, что замены устаревшей системы не происходит. Однако компании часто не учитывают увеличение стоимости поддержки системы (людей, программного обеспечения, аппаратного обеспечения и т. д.) и не берут в расчёт огромные потери, которые могут возникнуть в случае неполадок унаследованной системы. Как только наступает понимание, что цена обновления системы меньше затрат на её поддержку, средства на её замену, как правило, сразу находятся[6].
  • Так как больша́я часть программистов, работавших с унаследованными системами, выходит на пенсию, а молодых специалистов, которые занимают их места, мало, то рынок страдает от нехватки рабочей силы. В свою очередь, это усложняет поддержку унаследованных систем и повышает стоимость подготовки опытных программистов.

Улучшения унаследованных систем[править | править код]

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

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

Биометрические меры безопасности сложно внедрить в унаследованные системы. Рабочим решением может стать использование telnet или http прокси-сервера между пользователями и системой, который обеспечит защищенный доступ к унаследованным приложениям.

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

Управляемую моделями разработку (реверсивную и прямую) также можно использовать для улучшения унаследованного программного обеспечения[7].

Другие примеры использования термина «унаследованный» в IT[править | править код]

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

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

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

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

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

Альтернативная точка зрения[править | править код]

Существует альтернативное мнение, бытующее с момента, когда лопнул «пузырь доткомов» в 1999 году. Унаследованные системы — это просто компьютерные системы, которые продолжают использоваться для работы.[8] Согласно утверждениям IT-аналитиков, цена полной замены бизнес-логики в пять раз превышает стоимость её дальнейшего использования, даже если учитывать риски системных сбоев и нарушения безопасности. В идеале переписывать ядро бизнес-логики вообще не нужно.

IT-индустрия предлагает «модернизацию унаследованных систем» и «трансформацию унаследованных систем». Они включают в себя обновление существующей бизнес-логики с помощью новых пользовательских интерфейсов, иногда использует «извлечение данных» и доступ через веб-службы. Эти технологии позволяют организациям понять существующий код (используя инструменты обнаружения), обеспечить этот код новым пользовательским интерфейсом, улучшить рабочие процессы, сократить расходы, минимизировать риски и при этом пользоваться классическим качеством сервиса (близкая к 100 % доступность, безопасность, масштабируемость и т. д.).|[9] Этот тренд также заставляет задуматься о том, что делает унаследованные системы такими долговечными? Технологи заново осознали всю важность выбора правильной архитектуры системы в самом начале, чтобы впоследствии избежать дорогостоящего и рискованного переписывания кода. Самые распространённые унаследованные системы используют общеизвестные принципы IT-архитектуры, тщательное планирование и строгое соблюдение методологий в процессе внедрения. Плохо спроектированные системы долго не живут, потому как быстро изнашиваются и из-за ошибок, допущенных при их создании, требуют замены. Таким образом многие организации заново открывают для себя значимость унаследованных систем и принципы, на которых эти системы были созданы.[10]

Примечания[править | править код]

  1. Что такое унаследованные системы? Дата обращения: 4 июня 2019. Архивировано 4 июня 2019 года.
  2. Работа с легаси-системами: стабилизация, мониторинг, управление. Дата обращения: 4 июня 2019. Архивировано 4 июня 2019 года.
  3. Унаследованные системы. Большая энциклопедия Нефти и Газа. Дата обращения: 4 июня 2019. Архивировано 4 июня 2019 года.
  4. Legacy systems continue to have a place in the enterprise. Дата обращения: 4 июня 2019. Архивировано 4 июня 2019 года.
  5. The Danger of Legacy Systems. Дата обращения: 4 июня 2019. Архивировано 23 марта 2012 года.
  6. Унаследованная система в качестве стартовой площадки. Дата обращения: 4 июня 2019. Архивировано 4 сентября 2017 года.
  7. Обзор методов реструктуризации и интеграции информационных систем. Дата обращения: 4 июня 2019. Архивировано 17 июля 2019 года.
  8. Унаследованные системы: опора или препятствие на пути внедрения ERP-систем?
  9. Legacy Systems: Why History Matters. Дата обращения: 4 июня 2019. Архивировано 4 июня 2019 года.
  10. Интеграция унаследованных систем в SOA-проекты. Дата обращения: 4 июня 2019. Архивировано 4 июня 2019 года.