View source for Definitive Media Library (DML)

A '''Definitive Media Library''', or '''DML''', is a set of secure storage areas in which an [[organization]]'s definitive, authorized versions of [[application]] configuration items (CIs) ([[Software|software]] and [[software]] packages) are stored and protected, together with their path. The aims are as follows:
*To monitor and [[control]] software installed in the organization.
*To ensure that the same version of software will be installed on every workstation.<ref>Definition - What is Definitive Media Library (DML)? [https://wiki.easyvista.com/xwiki/bin/view/Documentation/CMDB+-+Definitive+Media+Library EasyVista]</ref>

[[ITIL (Information Technology Infrastructure Library)|ITIL]] defines a Definitive Media Library (DML) as the place to store "official" versions of all media, including software, documentation and licenses. In order to begin a Definitive Media Library (DML) you will need to first set a definition for what you want in the DML. Once you have your definition, you need to identify all specific instances of “definitive media” that fits your organization’s definition. Once identified, place them under your control by adding information and attributes about the media into your DML tool. For physical copies of boxed or purchased software, gather those together for storage in a locked physical location (cabinet, etc.) Once you identify and control then apply your regular Change, Configuration and Release processes to the media. The DML was previously called the Definitive Software Library (DSL) in ITIL versions earlier than Version 3.


'''The Definitive Media Library & CMDB in the context of the Release [[Management]] [[Process]]'''<br />
[[File:DML.jpg|500px|The Definitive Media Library & CMDB in the context of the Release Management Process]]<br />
source: Wikipedia


== Scope of Definitive Media Library (DML)<ref>Scope of Definitive Media Library (DML) [https://en.wikipedia.org/wiki/Definitive_Media_Library Wikipedia]</ref> ==
The DML plays a critical role in supporting the transition from development to production phases and DML solutions should be distinguished from other software and source code repositories e.g. Software Configuration Management or SCM (sometimes referred to as Software Change and Configuration Management) that supports the development or software evolution phase. This is an important distinction and often causes some confusion. In essence, whereas SCM tools or repositories store and manage all development versions and revisions of code (or work products) up to but not including the final authorised [[product]], the DML stores only the final authorised versions of the code or product. This is analogous to a high-street product lifecycle where the product moves from [[design]] house to factory, through to warehouse and then shop, i.e.
*records ([[metadata]]) are kept about how a product is designed developed and built. This enables the tracking down of which process is to blame where faulty products are discovered either during [[quality]] control or even in later [[service]].
*records (metadata) are kept in a CMDB about where the software is installed and deployed from the DML and into the production environment. Each installation or deployment should be authorised by a corresponding production change request and the resulting change recorded in the CMDB as a relationship between the DML artefact and the platform where it has been deployed.
In a more mature or evolved state there is no distinction drawn between the two forms of configuration management and the process is continuous supporting the whole service delivery and service operation lifecycle. This has been referred to as Enterprise Configuration Management. Even here though the development-based artefacts should still be distinguished from and kept separate from the management of quality assured, definitive master versions available for deployment. In an outsourced or multi-[[vendor]] arrangement the existence or otherwise of a consistent and secure form of [[supplier]] access will dictate whether or not the software configuration management is performed passively (externally by suppliers adopting their own SCM tools and then delivering the finished product) or actively (overseen internally with suppliers utilising the centrally hosted SCM tool). All finished products, however, (application software) in their authorised deployable form should be stored within the central DML. Typical CIs that a DML will store include:
*Packaged in-house application software
*[[Commercial off-the-shelf (COTS)]] raw media
*Customised COTS software (containing enhancements, tailored configuration etc)
*Release packages
*Patches (see patch (computing))
*Gold builds (clients, servers, [[network]] and storage devices etc)
*[[System]] images
*Across multiple technology stacks and [[distribution]] technologies (e.g. Wintel, UNIX, ORACLE, [[mainframe]], network, storage etc)


== Benefits of a Definitive Media Library<ref>Benefits of a Definitive Media Library [https://blog.masterofproject.com/definitive-media-library/ Master of Project]</ref> ==
There are several benefits to having a DML. A well-designed DML supports:
*Release & Deployment Management from a centralized storage area
*Availability and Service Continuity by providing the source of all packaged applications and raw media for use in service restoration and [[disaster recovery]] procedures
*Automated [[server]] provisioning and rationalization
*[[Asset]] Management by providing metadata records and license keys relating to software license provision.
*Cataloged request fulfillment, whether it’s a one-off request or a repeated request for updates to the same service.
Having a DML in place may at first seem like a lot of work for little reward, but it really streamlines processes in the Service Transition stage and acts like a security blanket during change management, configuration management, and release management. A DML is a useful ITIL tool that will help an IT service provider to keep records of all their definitive media items in one centralized place where there is complete control over the items in the library. When checking the items into the library, they can be checked for [[compliance]] with the company standards. This adds a security checkpoint which ensures that only tried and tested configuration items are used to act on change requests. This helps avoid situations where releases go into the DML and subsequently implementation that are insecure, unlicensed, not supportable by the operations team.


== References ==
<references/>