How to Set Up and Manage a Definitive Media Library
Organizations struggling with version control, virtual machine images, approved build, licensing, and so on can benefit from the DML, writes ITSMWatch columnist George Spafford.
PRINT
COMMENTThe logical DML is comprised of one or more logical and physical locations that are integrated with the configuration management system (CMS). To safeguard production, authorized releases are only to be assembled from CIs in the DML. The DML performs a number of control activities to mitigate organizational risks associated with releases being built with unauthorized/unlicensed applications, lost documentation, lost licenses and so on.
Release management policy - Perhaps the most critical first step is that management must tell staff responsible for planning and building releases that they are only to use what is contained in the DML. No more downloading software from the Internet, using media at their desks and building in an ad hoc manner in general. Some groups go as far as only allowing masters to be created in a clean room with no Internet access and measures that require that the release engineers can only draw from the DML. In turn, engineers building devices can only access builds stored in the DML. What control measures are best for your organization depends on the level of risks involved.
DML policy - As a first step, a policy needs to be defined regarding the DML. This policy should take into account process requirements that are codified in the Service Transition processes and address issues including:
Environment scope - What areas of the service development lifecycle will use the DML? This may include development, test, and production.
CI scope - What will be storied in the DML? Examples include source files, virtual machine images, server images, applications, documentation, videos, and licenses
DML roles and responsibilities should be defined in process documentation. Some organizations will find it necessary to also include guidance on roles and responsibilities in their DML policy.
Access controls need to be defined in accordance with the aforementioned roles.
Backup procedures - There must be defined mean to backup the DML in accordance with management's directives. [Note: The ability to restore from the backup methods must be tested at least annually and after any major changes.]
IT service continuity management (ITSCM) - The DML must be factored into ITSCM planning. Imagine being at a recovery site during a disaster only to find there is no access to the DML or a recovery version of it.
Naming conventions - To avoid chaos, there must be standards for the naming of physical and logical files.
File location(s) - To promote storage and retrieval of files, the physical and logical location standards need to be defined.
Retention - How long files will be retained should be defined along with what happens for long-term archival storage, if appropriate.
Versioning - How object versioning will be managed should be identified.
Groups may determine they need some or all of the examples, perhaps more. The intent of the DML Policy is to remove ambiguity and promote planning. The point is that the policy must reflect the needs of your organization and it will evolve over time.
The following are some brief suggestions for your consideration:
Change management - To maintain the integrity of the DML, there must be effective change management coverage. A file should only be allowed into the DML after an approved request for change (RFC). This risk management activity helps ensure that files are properly reviewed and duly authorized prior to one of the following actions:
- Insertion of a new CI into the DML with the appropriate descriptions, access levels, scope, key words, etc.
- Updating of a CI in the DML. [Note, versioning with defined retention is recommended over replacing of files/objects with a revision.] Leverage a database and/or other controls to ensure that versions are managed and reduce the chances of human error in terms of retrieving an obsolete build unintentionally.
- Retirement of a CI is often overlooked but also important. There must be a means to disable CIs or otherwise flag them as obsolete and no longer for production use. There are many reasons why retired CIs may need to be accessed in the future vs. simply being deleted. Plan your approach carefully.
Access controls - The ability to access the DML must be controlled. The ability to create and update must be restricted to a very select few individuals who will only insert a new CI once an RFC has been approved. In addition, access must be limited based on roles tied to business need. Assuming images are in the DML, you would not want, for example, just anyone to be able to retrieve a critical financial system and gain access both to the logic and data contained therein. Instead, access must be controlled. It is also a good idea to review the accounts and access levels on a routine basis, perhaps annually, to ensure that only authorized persons have access and then only with the correct permissions.
Integrity management controls & DML audits - Automation is needed to detect and report on all differences between CIs and approved states. This allows for assurances that a CI matches an approved state prior to insertion in the DML. It also allows for comparisons of CIs in production to approved states to identify if any unauthorized changes have occurred. Audits of the DML should happen on a scheduled basis as well as in accordance with release policies, plans and so forth.
Capacity planning - The DML can grow dramatically over time. It needs to be part of formal capacity planning to ensure that storage and such is available in a manner that makes business sense when needed. Historical growth trending is one dimension and forecasting must also incorporate talking to departments about their plans for the forecasting horizon in question. [Note: The use of a hierarchical storage method (HSM) that allows for on-line, near-line and off-line storage may help with the balancing of costs and retention.]
Scheduled reviews and pruning - There must be scheduled reviews of the DML to formally review what is contained, if some CIs should be retired, etc. It may be that some files should be moved to off-line archival storage, near-line storage, etc. in accordance with retention and disposal policies. Without "pruning" of the DML, it can rapidly grow to an unmanageable size.
The DML can help organizations manage their approved application, system builds, licenses, documentation and so on. As with any repository of data, care must be taken to manage it correctly to maintain the appropriate levels of confidentiality, integrity and availability for the benefit of the business.
George Spafford is an experienced consultant in business and IT operations. He is a prolific author and speaker, and has consulted and conducted training on strategy, IT management, information security and overall process improvement in the U.S., Canada, Australia, New Zealand and China. His publications include hundreds of articles plus the following books: "The Governance of Green IT", "Greening the Data Center", "Optimizing the Cooling in Your Existing Data Center" and co-authorship of "The Visible Ops Handbook" and "Visible Ops Security". His current area of research is the use of information technology for competitive advantage. George holds an MBA from Notre Dame, a BA in Materials and Logistics Management from Michigan State University and an honorary degree from Konan Daigaku in Japan. He is a certified ITIL Expert, TOCICO Jonah and a Certified Information Systems Auditor (CISA). George is a current member of the IIA, ISACA, ITPI, ITSMF, and the TOCICO.