c) операционные системы и прикладное программное обеспечение неизбежно будут вытесняться более новыми и производительными продуктами, имеющими больше функциональных возможностей. Это означает, что хранителям информации придется периодически перемещать электронные документы из текущей программной среды в новую;
d) некоторые электронные документы, вероятно, будут доступны лишь в унаследованных информационных системах, не имеющих автоматических средств миграции.
Миграция электронных документов позволяет успешно решить все эти четыре проблемы. Хранителям информации нужно будет организовать миграцию аутентичных электронных документов из среды одного программного приложения в среду нового программного приложения таким образом, чтобы не было никаких потерь контента и контекста, а также чтобы отсутствовала или была минимальной потеря структуры.
6.4.2 Зависимость от программного обеспечения
Стратегия долговременной сохранности должна решать проблему зависимости от конкретного программного обеспечения. Если электронные документы могут быть использованы только при помощи определенного программного приложения, то обеспечение долговременного доступа к этим документам может оказаться проблематичным, особенно если поставщик прекратит техническую поддержку или не обеспечит преемственность в новых версиях программного обеспечения. Во многих случаях возможно избавиться от зависимости такого рода, частично пожертвовав структурой, например, текстовые документы из первоначальной среды программного приложения для обработки текстов могут быть мигрированы в простой текст (т.е. "чистый" ASCII-текст) путем автоматического удаления встроенных инструкций форматирования или кода, управляющего определенными аспектами физического представления, такими как жирный шрифт или примечания.
Хотя такие действия и уменьшают зависимость от программного обеспечения, хранители информации должны тщательно оценить их последствия для аутентичности мигрированных подобным образом документов. Такие документы уже нельзя будет рассматривать в качестве имитационных копий (imitative copies), поскольку они не будут в точности воспроизводить структуру оригинальных документов. Скорее, получившиеся документы следует рассматривать в качестве "новых" документов, аутентичность которых должна быть установлена заново благодаря документированию всех выполненных действий и путем проверки и подтверждения неизменности контента документов.
Альтернативой миграции текстовых электронных документов в простой текст является распечатывание их на бумаге или вывод на микропленку, что позволяет сохранить аутентичность за счет удобства обработки и использования. Такой подход особенно оправдан в отношении электронных документов, аналогичных постранично организованным бумажным документам (page analog electronic records), пригодность которых к обработке и использованию в принципе может быть восстановлена в будущем за счет использования средств распознавания текста (OCR).
Таблицы иерархических и реляционных баз данных также можно мигрировать в "плоские" табличные структуры, чтобы минимизировать зависимость от программного обеспечения конкретного поставщика. В этом случае идентификация первичного ключа (primary key) и внешних ключей (foreign keys) в каждой таблице должна быть сохранена, в то время как реляционные связи удаляются. В процессе такого преобразования должны быть созданы метаданные, показывающие, какого типа были эти связи - "один к одному", "один ко многим", "многие к одному" или "многие ко многим", чтобы в будущем эти связи можно было восстановить.
6.4.3 Обновление программного обеспечения и инсталляция нового программного обеспечения
Поскольку хранителям информации, обеспечивающим долговременный доступ к аутентичным документам, неизбежно придется обновлять существующее и инсталлировать новое программное обеспечение, то стратегия долговременной сохранности должна включать политику и процедуры на этот случай.
Когда происходит обновление программного обеспечения (например, от версии 1 к версии 2) и поставщик обеспечивает обратную совместимость (совместимость "сверху вниз") обновленного и старого программного обеспечения, документы следует автоматически перевести в новую среду, вместе с лежащей в их основе схемой физического представления (underlying physical representation scheme), существенным контентом и контекстом.
В тех случаях, когда новое программное обеспечение заменяет существующее, - как автономное программное приложение или как часть общего обновления информационной системы, - следует провести миграцию документов, используя функции экспорта старой системы и функции импорта новой системы. Кроме того, в некоторых средах может поддерживаться миграция через сопряжения (gateways) импорта/экспорта, разработанные для отдельных коммерческих (проприетарных) форматов (например, преобразование из формата одного текстового процессора в формат другого).
6.4.4 Миграция в стандартные форматы
После передачи электронных документов на хранение хранителям информации следует подумать об их миграции из широкого набора форматов, используемых создателями и получателями документов, в меньшее число "стандартизованных" форматов. Выбор "стандартизованных" форматов может быть результатом консенсуса относительно широко используемых форматов, которые покрывают большую часть электронных документов определенного класса. Следует избегать коммерческих (проприетарных) форматов. К числу заслуживающих внимания технологически нейтральных форматов относятся PDF/A-1, XML, TIFF и JPEG.
6.4.5 Миграция электронных документов из унаследованных информационных систем
6.4.5.1 Общие положения
Стратегия обеспечения долговременного доступа к аутентичным и пригодным к использованию электронным документам должна предусматривать миграцию в тех случаях, когда отсутствуют как обратная совместимость, так и сопряжения экспорта/импорта между старой (унаследованной) системой, в которой хранится документация, и новой информационной системой.
В будущем потребность в миграции электронных документов из унаследованных информационных систем может сократиться вследствие более широкого распространения систем, поддерживающих архитектуры и форматы, нейтральные по отношению к используемым поставщиками технологиям. Пока, однако, хранителям информации, чтобы выполнить свои обязательства, приходится проводить миграцию электронных документов, находящихся в устаревших информационных системах.
Некоторая потеря информации во время повторяющихся циклов миграции неизбежна из-за фундаментальной несовместимости, существующей между несколькими поколениями более старых и более новых систем. Соответственно, хранителям информации, вместо того чтобы пытаться полностью избежать потерь информации, рекомендуется разработать политики миграции и процедуры контроля качества, нацеленные на уменьшение деградации информации в процессе миграции. Одной из важных процедур является документирование потерь, имевших место в ходе миграции, и результатов деятельности по контролю качества. По возможности эта документация должна сохраняться вместе с носителями информации.
6.4.5.2 Этапы миграции
6.4.5.2.1 Общие положения
Хранителям информации следует внедрить 10-этапный подход к выполнению миграции. Поскольку обстоятельства каждого отдельного проекта миграции могут существенно отличаться, описанные ниже десять этапов не должны рассматриваться как конкретный план миграции, применимый при любых обстоятельствах.
6.4.5.2.2 Анализ унаследованной информационной системы (этап 1)
Хранители информации должны провести анализ унаследованной информационной системы с целью понять, какие функции она выполняет и какие документы в ней содержатся. В ходе анализа определяются:
- обоснование выполняемых системой функций;
- способ сбора (захвата) метаданных, их взаимосвязь с документами;
- взаимосвязи между документами.
На этом этапе должен быть создан информационный продукт - спецификации, которые будут использованы при "прямом" проектировании (forward engineering) функциональных возможностей, метаданных и документов для новой системы.
6.4.5.2.3 Декомпозиция структуры унаследованной информационной системы (этап 2)
Хранителям информации следует провести декомпозицию унаследованной информационной архитектуры, чтобы с ее интерфейсами, приложениями и сервисами базы данных можно было работать как с отдельными компонентами (это, однако, возможно сделать не для всех информационных систем):
- декомпозиция унаследованной системы возможна, если системные и пользовательские интерфейсы, модули программных приложений, сервисы базы данных и сама база данных являются отдельными и независимыми компонентами;
- унаследованная система частично поддается декомпозиции, если интерфейсы и база данных являются независимыми, а программное приложение и сервисы базы данных составляют единый модуль;
- унаследованная система не поддается декомпозиции, если интерфейсы, приложения и сервисы базы данных объединены в одном модуле.
В любом случае при подготовке к миграции должны быть устранены все внешние зависимости в архитектуре системы.
6.4.5.2.4 Проектирование интерфейсов новой системы (этап 3)
Должна быть обеспечена связь (преемственность) между новыми и старыми интерфейсами.
6.4.5.2.5 Проектирование новых программных приложений (этап 4)
Должна быть обеспечена связь (преемственность) между новыми и старыми программными приложениями.
6.4.5.2.6 Проектирование новых баз данных (этап 5)
Должна быть обеспечена связь (преемственность) между новыми и унаследованными базами данных.
6.4.5.2.7 Инсталляция и всестороннее тестирование новой среды (этап 6)
Необходимо идентифицировать, выбрать, инсталлировать и полностью протестировать открытую новую среду (имеющую соответствующие средства инсталляции).
6.4.5.2.8 Разработка и инсталляция необходимых модулей сопряжения (gateways) (этап 7)
Для обеспечения согласованности и точности в воспроизведении функциональных возможностей унаследованной системы в новой системе и для перемещения электронных документов следует спроектировать, разработать и инсталлировать модули сопряжения (gateways). Такие модули обычно выполняют две функции. Первая - изоляция определенных компонентов от влияния изменений, вносимых в другие компоненты, вторая - функционирование в качестве преобразователя запросов и данных, которыми обмениваются обслуживаемые сопряжением компоненты. Для обеспечения согласованности и точности модули сопряжения должны быть тщательно протестированы на образцах документов из унаследованной системы.
6.4.5.2.9 Миграция унаследованной базы данных (этап 8)
Должна быть проведена миграция унаследованной базы данных в новую базу данных.
6.4.5.2.10 Миграция унаследованных программных приложений (этап 9)
Должна быть проведена миграция унаследованных программных приложений в новые программные приложения.
6.4.5.2.11 Миграция унаследованных интерфейсов (этап 10)
Должна быть проведена миграция унаследованных интерфейсов в новые. Унаследованные интерфейсы (например, текстовые меню и экраны) будут, скорее всего, заменяться графическими интерфейсами.