حفظ نسخه‌ها صرفاً برای بازگشت به فایل قبلی نیست. بسیاری از سازمان‌ها باید بتوانند نشان دهند یک محتوا در چه تاریخی، به چه دلیل و با چه مجوزی مورد استفاده قرار گرفته است.
سناریوی واقعی کار
در یک پروژه، فایل طراحی اصلی بارها اصلاح می‌شود. خروجی وب و نسخه چاپی از همان منبع تولید شده‌اند. یک سال بعد باید دوباره کمپین را اجرا کرد، اما مشخص نیست فایل اصلی کدام بوده و کدام خروجی در تاریخ قبلی تأیید شده است.
چهار مفهوم را جدا نگه دارید
فایل اصلی، نسخه‌های اصلاح‌شده، خروجی‌های مشتق‌شده و وضعیت انتشار با یکدیگر برابر نیستند. طراحی ساختار دارایی باید رابطه آن‌ها را حفظ کند تا تیم بعدی مجبور به حدس‌زدن نباشد.
| مفهوم | مثال | قاعده |
|---|---|---|
| فایل منبع | فایل لایه‌باز طراحی | حفظ ارتباط با خروجی |
| نسخه | ویرایش ۱، ۲ و ۳ | تاریخ و تغییر معلوم |
| خروجی | نسخه وب یا چاپ | کاربرد و قالب مشخص |
| وضعیت | مصوب یا آرشیو | مسئول تصمیم مشخص |
آرشیو و حذف به یک معنی نیستند
ممکن است دارایی دیگر قابل انتشار نباشد اما برای اثبات تصمیم، استفاده تاریخی یا بازتولید آینده باید حفظ شود. سیاست نگهداری باید مدت، مسئول، دلیل و روش بازیابی را دربرگیرد.
نگهداری بلندمدت و شواهد
در بحث نگهداری دیجیتال، مدل‌هایی مانند PREMIS بر ثبت اشیا، رویدادها، عامل‌ها و حقوق تأکید می‌کنند. استفاده از این مفاهیم برای طراحی اطلاعات مفید است، هرچند انطباق نرم‌افزار با یک استاندارد باید مستقل آزموده شود.
تست بازیابی را فراموش نکنید
نسخه پشتیبان صرفاً زمانی قابل اتکاست که بازیابی آن آزموده شود. در طرح استقرار، سناریوی خرابی، هدف زمانی بازیابی، داده لازم و روش کنترل صحت بعد از بازیابی باید مستند شود.
مسیر اجرای پیشنهادی
در طراحی MedaDAM، سیاست نسخه مرجع، ارتباط منبع با خروجی و سناریوی بازیابی باید در مرحله پایلوت با چند فایل نمونه آزمایش و برای تیم‌های محتوا و زیرساخت مستند شود.
